Trying Mulder2012's suggestion of running the Boot Repair tool is worthwhile. That said, I've examined both cbrace's and louisgv's Boot Info Script outputs, and they've got two very
different problems. Thus, the Boot Repair tool might not work for everybody.
In the case of cbrace, the disk is partitioned with the Master Boot Record (MBR) partitioning system, which is usually associated with a BIOS-mode boot; but it looks as if the Mint installer tried to install in EFI mode -- there's a file called /efi/BOOT/grubx64.efi, which is an EFI boot loader file. Of course, the message reported by cbrace (referring to the grub-efi package) also denotes an EFI-mode install. My hunch is that the installer booted in EFI mode by default, where previous ones didn't, and the installer didn't do any basic sanity checks to verify that it really should do an EFI-mode installation. You didn't say precisely what happens when you reboot, cbrace, so I'm not sure precisely what's happening. It looks like there's leftover BIOS GRUB code, so I'd expect you'd get something
-- perhaps a "grub>" prompt or even a menu with inoperative options.
In any event, the Boot Repair tool may well work on this system. If not, the simplest solution is likely to be to re-install a BIOS-mode GRUB. You might try removing all the files that end in .efi from the installation medium and rebooting it into its "try before installing" mode, then use that to re-install GRUB. (There are lots of online guides about doing this, but I don't happen to have any bookmarked.)
The Boot Info Script output that louisgv posted shows an entirely different problem: The disk is partitioned using the GUID Partition Table (GPT) and appears to be set up for an EFI-mode boot, but with problems. /dev/sda1, which is usually the EFI System Partition (ESP) on EFI-based systems, has a FAT filesystem and an /efi/Boot/bootx64.efi boot loader file; but the Boot Info Script didn't recognize its partition type code. The /dev/sda3 partition, OTOH, is
marked as an ESP, and has a FAT filesystem, but the script didn't identify any .efi boot loader files on it. The disk also has two Windows Recovery Environment partitions, which is odd. It looks almost as if Windows was installed twice and then one installation was incompletely erased to make room for Linux. The Linux installation then failed for reasons that aren't entirely clear but probably relate to the unusual set of pre-existing partitions at that point.
I'm less optimistic that the Boot Repair script will work on your system, louisgv, but it's worth a try. If it doesn't work, I'd do this:
- Download Parted Magic or System Rescue CD for use as an emergency system.
- Boot your emergency system.
- Open a Terminal window.
- Type "gdisk /dev/sda". This should launch gdisk on your main hard disk.
- Type "p" in gdisk. This will show you your partition table. Be sure it's the right one (with nine partitions; #3 should have a type code of "EF00"). If you see something else, type "q" to quit and try /dev/sdb instead.
- Out of curiosity, I'd be interested in knowing the type code for partition #1 -- what's reported under the "Code" column; and if that's "FFFF", the "Partition unique GUID" line when you type "i" followed by "1". Feel free to not report this to me if it's inconvenient, though.
- Type "t" to change a type code. In response to the prompts, enter "1" for the partition number and "EF00" for the type code.
- Type "t" to change another type code. Change the code for partition #3 to "8300". (This may not be strictly necessary, but I'm having you change it just in case.)
- Use "t" to change two more type codes: Change both 7 and 9 to "8300". This will keep them from showing up as unpartitioned disks in Windows.
- Type "w" to save your changes. Verify this operation when asked.
- Reboot. The computer should boot to something, probably Windows, but it might boot GRUB. If the latter, GRUB will probably be non-functional.
At this point, your task becomes one of getting both your OSes to boot. If you booted to Windows, you'll need to install a Linux EFI boot loader. Given your partition layout, I'd recommend booting an emergency Linux system, backing up /dev/sda9, creating a fresh FAT filesystem on it, restoring its files, and installing rEFInd
on your ESP (/dev/sda1). (Installing rEFInd is best done from Windows, given your situation.) Once you create a refind_linux.conf file on /dev/sda9 (as described in the rEFInd documentation
), you'll be able to boot Linux or Windows from the rEFInd menu, without dealing with GRUB. There are other options,
though, including the EFI-enabled version of GRUB that ships with Mint.
Good luck to you all! It looks like Mint 14's EFI installer support is seriously messed up!