Boot Linux Mint via EFI with an Insyde H2O BIOS

[empyrien]

I got one of the new Sony VAIO S Series (with 3rd gen i7s) and I wanted to install Linux Mint 13 (Maya) on it. By default of course it comes with Windows 7 installed, and the BIOS is set to boot via UEFI. I didn't want Windows, so after making some recovery disks (just in case), I blew away the partition table, made a new one and installed Mint 13.

Of course, this failed to boot, producing the ominous error "Operating system not found."

Now, of course, I could have simply changed the BIOS setting to boot in Legacy mode rather than UEFI mode and then installed Mint. (I actually did this at one point, just to make sure it worked).

However, I had been presented with a challenge, and wasn't going to be defeated by some silly proprietary BIOS. So I continued in my attempts to get Mint booting via EFI. After much investigation and research and no success (and many reinstalls -- thank goodness for live USBs), I came across this thread where I learned that the Insyde H2O BIOS is hardcoded in EFI mode to boot Windows, my first clue on how to proceed.

Simply doing what the thread suggests (that is, renaming grubx64.efi to Microsoft/Boot/bootmgfw.efi) didn't work. It took me a while to figure out why.

The key problem is that, unlike Ubuntu, Linux Mint doesn't have an alternate ISO to install from, and hence there isn't an easy way to prevent the Mint installer from overwriting the Windows bootloader. As it turns out, using the Windows bootloader rather than the GRUB2 bootloader is the critical step to success.

So I booted into the Windows 7 install CD and chose the Repair Windows option, proceeding forward until I got to the Command Prompt. At that point, I executed

Code: Select all

bootrec /FixBoot

which reinstalls the Windows bootloader.

Exit, reboot, and it worked!

In summary, to get your Mint booting via UEFI when faced with an Insyde H2O BIOS, you need to do the following (you will need access to a Windows 7 CD):

0. Boot into the Mint Live CD/USB (preferably in UEFI mode).

1. Make sure your disk is partitioned with a GPT table rather than an MSDOS table. Next, you need to add an ESP partition (if it doesn't have one already). GParted is the easiest way to do this. It is recommended to make this the first partition, and it needs to be formatted to FAT32 and flagged as boot. Make it a decent size, just in case ( I made mine 256 MiB). I also added separate partitions for /boot, / and /home.

2. Start the Mint Installer. Be sure to select the "Something Else" option so you can make use of your custom partition table. Be sure to tell Mint to use the ESP as "EFI System Partition", and tell it to install the bootloader in the base device (e.g. /dev/sda or whatever). Assign the other partitions as appropriate.

3. Install Mint, making sure you are connected to the internet because it will try to download and install the grub-efi package, which installs GRUB2 via EFI.

4. After the installer finishes, select "Continue Testing". Mount the ESP using e.g.

Code: Select all

sudo mkdir /mnt/efisys
sudo mount -t vfat /dev/sda1 /mnt/efisys

The contents of your ESP should be something like

Code: Select all

EFI/linuxmint/grubx64.efi

You need to rename this file to

Code: Select all

EFI/Microsoft/Boot/bootmgfw.efi

Be sure to unmount the ESP, e.g.

Code: Select all

sudo umount /mnt/efisys

5. Exit the Mint live CD/USB.

6. Boot into the Windows 7 install CD, select the Repair option, proceed until you get to the Command Prompt, then execute

Code: Select all

bootrec /FixBoot

to replace the GRUB2 boot loader with the Windows 7 bootloader.

7. Exit, and reboot and hopefully you should be booting into Linux Mint via UEFI.

Hopefully this helps someone else!

Footnote: If you want to dual-boot Windows and Mint you will need to do something more complicated. Possibly the best way to proceed here is to get the Windows BCD (Boot Configuration Data) to recognise GRUB as a second boot option.

[AlbertP]

I came across this thread where I learned that the Insyde H2O BIOS is hardcoded in EFI mode to boot Windows, my first clue on how to proceed.

Most likely, Sony chose to hardcode it instead of it being a requirement from Insyde. BIOS vendors offer a lot of freedom to the computer manufacturer. And apart from these Sony issues I've never heard of troubles with Insyde H2O and Linux. It's too bad that Sony is doing this (or that Insyde allows manufacturers to lock computers this way).

[srs5694]

I guarantee you that you're not using the Windows boot loader to boot Linux; that boot loader can do nothing but boot a Windows kernel, AFAIK, and it certainly can't load a Linux kernel. I'm not an expert on Windows tools, but a little Googling reveals that the "bootrec /FixBoot" command you described rewrites the boot sector of the Windows boot partition; however, that description almost certainly applies only to BIOS computers. I didn't see anything definitive about what it does on EFI systems, but my hunch is that it adjusts the computer's NVRAM settings, perhaps updating the entry that points to /EFI/Microsoft/Boot/bootmgfw.efi.

My suspicion is that the Ubuntu installation somehow damaged the firmware's settings, preventing the system from booting. You then copied GRUB to the location normally used by the Windows boot loader, and using Windows' bootrec fixed the NVRAM settings to point to the file that normally holds the Windows boot loader but that now contains GRUB 2. In principle, you could have fixed this with Linux's efibootmgr utility rather than bootrec; however, recent posts from you and others, and my own experiences, make me think that Linux's efibootmgr may contains some serious bugs and be ineffective on many systems. the "bcfg" command built into some EFI shells may do a better job on some systems. I need to study this issue some more, though.

[empyrien]

I guarantee you that you're not using the Windows boot loader to boot Linux; that boot loader can do nothing but boot a Windows kernel, AFAIK, and it certainly can't load a Linux kernel.

Absolutely agreed. I guess it's an issue of terminology. I was using the same term that the Mint installer uses (which is perhaps the wrong term to use).

Certainly once GRUB's EFI file is successfully loaded GRUB then takes care of loading the kernel. Perhaps "Windows pre-loader" or "Windows boot record" might have been a better term to use. In any case, what I am referring to is the code that gets written at the start of the drive that points to where the actual boot loader resides in the ESP.

My suspicion is that the Ubuntu installation somehow damaged the firmware's settings, preventing the system from booting. You then copied GRUB to the location normally used by the Windows boot loader, and using Windows' bootrec fixed the NVRAM settings to point to the file that normally holds the Windows boot loader but that now contains GRUB 2. In principle, you could have fixed this with Linux's efibootmgr utility rather than bootrec; however, recent posts from you and others, and my own experiences, make me think that Linux's efibootmgr may contains some serious bugs and be ineffective on many systems. the "bcfg" command built into some EFI shells may do a better job on some systems. I need to study this issue some more, though.

I tried using efibootmgr many times, even with some alternative bootloaders/bootmanagers such as ELILO and rEFInd. None of this worked. What is clear is that, for these VAIOs in any case, the EFI BIOS firmware is only compatible with a Windows boot-record/pre-loader or whatever you want to call it. Whatever code GRUB2 (or the other Linux bootloaders I tried) writes there causes boot failure.

[AlbertP]

The laptop doesn't have a BIOS update to correct this?

[empyrien]

The laptop doesn't have a BIOS update to correct this?

It's a new model -- only came out this month (having said that, an update was released today, but it doesn't mention anything about this problem).

However, I don't think Sony officially supports putting anything but Windows on their laptops.

[srs5694]

What is clear is that, for these VAIOs in any case, the EFI BIOS firmware is only compatible with a Windows boot-record/pre-loader or whatever you want to call it. Whatever code GRUB2 (or the other Linux bootloaders I tried) writes there causes boot failure.

EFI does not use code written to the Master Boot Record (MBR), at least not when booting in EFI mode. An EFI boot loader could theoretically use code written to the MBR, or to a partition's boot record, but AFAIK none do. The EFI boot process works like this:

1. You power on the computer, the firmware takes control and performs its pre-boot setup.
2. The firmware looks for and mounts the EFI System Partition (ESP)
3. The firmware looks for NVRAM settings related to what file(s) in the ESP to use to boot the system.
4. If a suitable ESP boot loader is found, it's executed.
5. If no NVRAM-specified boot loader is found, the firmware may try to execute EFI/Boot/bootx64.efi (and some implementations also try EFI/Microsoft/Boot/bootmgfw.efi).
6. If either of the preceding two steps executed a boot loader, it does whatever it does to transfer control to another boot loader or to an OS kernel.

There are some possible variants on this procedure (involving removable media, for instance), but the key to note is that at no point is there a step that reads "the firmware reads boot loader code from the disk's MBR." Such a step does exist for a BIOS (or even for an EFI-enabled firmware configured to boot in BIOS mode).

What's more, Microsoft's online documentation for bootrec specifies that the /FixBoot parameter writes a new boot sector to the Windows system partition. Since you don't have such a partition, that command could not have any effect on your system; however, the bootrec documentation clearly assumes a BIOS-based computer. As I said in my original post, it's likely that bootrec does something different on EFI systems, but I didn't find anything in the first few hits in a Google search, so I'm not sure what it does in that case. The logical thing for it to do, and the thing that would explain your results, is to adjust the NVRAM settings for booting.

Linux's efibootmgr utility has flaws. For instance, if you try it on a VirtualBox installation, its settings don't "take" -- when you reboot, it's as if you never used it. Issuing the equivalent commands using bcfg in an EFI shell does work. On two real EFI-based computers I've got, efibootmgr mostly works on one and doesn't work on the other. I haven't yet done serious tests with bcfg on either system, so I don't know if it's any better on these computers. Still, there's the possibility that efibootmgr is simply broken on your system, hence the results you got. I'm the person who's forked rEFInd from rEFIt, so I've been getting "up close and personal" with EFI programming of late, and the amount of system-to-system variability in what specific system calls do is appalling. The result is system-specific bugs, hence my growing distrust of efibootmgr -- it was written years ago for EFI 1.x systems, most of which used Itanium CPUs. In theory, it works on x86-64 systems, but I have strong doubts about its reliability on these systems.

[empyrien]

There are some possible variants on this procedure (involving removable media, for instance), but the key to note is that at no point is there a step that reads "the firmware reads boot loader code from the disk's MBR."

If I understand what you are saying correctly, then the location parameter that the MInt Installer asks for when specifying where to install the bootloader (or for that matter, the same parameter to grub-install when using grub-efi) is ignored when installing in UEFI mode? Because I have had the Mint install fail if I chose the wrong value for this parameter.

MintInstaller.png

Note that the location of the ESP is specified separately in the Mint installer.

[srs5694]

If I understand what you are saying correctly, then the location parameter that the MInt Installer asks for when specifying where to install the bootloader (or for that matter, the same parameter to grub-install when using grub-efi) is ignored when installing in UEFI mode? Because I have had the Mint install fail if I chose the wrong value for this parameter.

Note that the location of the ESP is specified separately in the Mint installer.

I don't know precisely what the Mint installer's user interface is doing. My recollection is that the grub-install script ignores the destination option when installing in EFI mode, although a quick check of the documentation couldn't confirm that. (Documentation often lags program features, though, so this isn't proof of much.) There is, though, an installation location for EFI boot loaders: They reside on the EFI System Partition (ESP), and in particular in a subdirectory called EFI/{name}, where {name} is normally based on the OS's name. The ESP is conventionally mounted at /boot/efi in Linux, so a Linux Mint boot loader normally resides in /boot/efi/EFI/linuxmint, as seen in Linux when everything is installed and mounted correctly. Most Linux distributions' installation user interfaces were built around BIOS and MBR assumptions, and those sometimes don't map well to EFI and GPT. Something like the setting for where to install the boot loader might not have an effect in EFI mode, or it might set the disk on which the installer tries to find the ESP, or it might set the partition that the installer tries to use as an ESP.

What's important in EFI booting is files and NVRAM settings, not code written to MBRs or partition boot sectors. In fact, an EFI-based computer can boot with no code in the MBR whatsoever. (It does need a protective MBR entry in the partition table portion of the MBR, though.) For instance, here's what's in one of my EFI-booting machines' MBRs, as revealed by hexdump:

Code: Select all

0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
00001c0 0001 feee ffff 0001 0000 87ff 06af 0000
00001d0 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200

If you're not familiar with hexdump outputs, this means that the sector contains nothing but binary 0 values up to address 0x01c0, which is the start of the protective MBR entry. (In fact, the protective MBR entry begins a couple of bytes before that, but those values happen to be 0 in this case.) On a disk that was BIOS-bootable, you'd have to have at least some code in the first few bytes of the sector.

Note that the presence of code in the MBR doesn't necessarily mean that the code is being used; you can find code in the MBR of an EFI-bootable disk if you installed a BIOS boot loader on the disk, whether by accident, for a previous OS installation, because you originally installed in BIOS mode and then switched to EFI booting, or for some other reason. EFI simply ignores such code if it's present.

One other point deserves mention: It's not always obvious in what mode you're booting. Linux is perfectly capable of booting in BIOS mode from GPT disks. The procedure you posted in your first message strongly suggests that you're booting in EFI mode, but I've seen numerous posts from people who are mistaken about their boot mode. In Linux, you can check the /sys/firmware/efi directory. If it's present, you've booted in EFI mode. If it's absent, you've probably booted in BIOS mode, although there are ways to boot in EFI mode that cause /sys/firmware/efi to not be created, so that's not an absolute certainty. See this page (part of my rEFInd documentation) for more on this topic. Most (maybe all) modern UEFI-based PCs include a BIOS compatibility mode, so it's possible to boot them in either way, but the rules for which boot mode they use differ from one computer to another. This makes it very hard to provide instructions on forcing a particular boot mode.

[empyrien]

So based on what you have said, I decided to to a bit more investigation. I reinstalled grub-efi and got the following output:

Code: Select all

$ sudo grub-install /dev/mapper/isw_dfjbicjbee_Volume0 
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001
Boot0001* Windows Boot Manager
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:0x1dcf5fff != 0x1dcf61ff
GPT:Alternate GPT header not at the end of the disk.
GPT:0x1dcf5fff != 0x1dcf61ff
GPT: Use GNU Parted to correct GPT errors.
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0000,0001
Boot0001* Windows Boot Manager
Boot0000* linuxmint
Installation finished. No error reported.

After installation I rebooted successfully. This, combined with the complaint about the GPT structure, leads me to believe that it is not in fact grub-efi that caused the system to be unbootable -- it is GParted. My explanation for this is that I think Windows must write something to the GPT that indicates where the ESP is. I think Sony has hardcoded the BIOS to look for this entry in the GPT when booting in UEFI mode, then try to find bootmgfw.efi. So I think perhaps what bootrec /FixBoot does is put this Windows-specific entry in the GPT. I think Sony's BIOS either ignores efibootmgr (or efibootmgr is buggy).

If GParted wrote a GPT that was missing this custom entry, then that would explain what I have observed, and why the combination of running bootrec /FixBoot and replacing bootmgfw.efi with GRUB's EFI file succeeded.

As an aside, the Sony BIOS has a setting that specifically states whether one boots in UEFI mode or Legacy (BIOS) mode, so there is no possibility for confusion there.

[srs5694]

So based on what you have said, I decided to to a bit more investigation. I reinstalled grub-efi and got the following output:

Code: Select all

$ sudo grub-install /dev/mapper/isw_dfjbicjbee_Volume0 

At best, installing GRUB to a RAID or LVM (/dev/mapper/{anything}) is useless. At worst, it will cause problems. You should just do "sudo grub-install", install GRUB to a disk ("sudo grub-install /dev/sda"), or install GRUB to a partition ("sudo grub-install /dev/sda1"). My recollection is that these are all equivalent for the EFI version of GRUB, but if my memory is faulty on this point, installing to a RAID or LVM is definitely the wrong thing to do.

Code: Select all

BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001
Boot0001* Windows Boot Manager
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:0x1dcf5fff != 0x1dcf61ff
GPT:Alternate GPT header not at the end of the disk.
GPT:0x1dcf5fff != 0x1dcf61ff
GPT: Use GNU Parted to correct GPT errors.

This output is clearly from efibootmgr, so it seems that grub-install is calling efibootmgr and displaying its output. (This is neither surprising nor troubling.) I've never seen this specific message from efibootmgr, but I understand what it means. The GUID Partition Table (GPT) includes two copies of all its critical data structures. The "primary" structures are at the start of the disk and the "alternate" (or "secondary" or "backup") structures are stored at the end of the disk. Each set of structures includes a pointer to the other set. Thus, the complaint is that the primary structures are pointing to a location that's not at the end of the disk, and it sounds as if they were found at the wrong location, too, although I'm not 100% positive of that.

This type of problem is common in misconfigured RAID setups. Typically, a motherboard-mediated RAID driver "steals" part of one or all of the disks so that it can store its RAID information. The OS should then "see" the disk as being a bit smaller than it really is. The problem is that if the OS doesn't load the appropriate RAID driver, it'll access the disk directly, and if the disk was prepared with the RAID software enabled, the OS with RAID software disabled will see the disk as being bigger than the GPT data structures claim it is. The solution to this problem is to synhronize the RAID settings between the firmware and all the OSes installed on the computer. That is, either install and enable motherboard RAID drivers in Linux or disable the RAID feature on the motherboard (and perhaps in Windows, too). Failure to do this can result in strange problems and even data loss, so I strongly recommend you look into this matter in more detail. Note that this has nothing to do with EFI, except for the fact that your firmware is EFI, so you'll need to use EFI interfaces to check the firmware side of the equation.

After installation I rebooted successfully. This, combined with the complaint about the GPT structure, leads me to believe that it is not in fact grub-efi that caused the system to be unbootable -- it is GParted.

Yes and no. It's most likely not GParted per se, but mismatched RAID settings. If I'm right and RAID was enabled in your firmware but not in Linux, then when GParted (or the Mint partitioner) wrote a new partition table, it would have pointed to backup GPT data structures "beyond the end of the disk," as far as the firmware (with RAID enabled) was concerned. This could cause any number of other problems. When you subsequently booted with Windows and repaired matters, it could have "corrected" the "problem" on the disk. This would work, but would also likely lead to a repeat of the problem in the future, whenever you next partitioned the disk in Linux. It's conceivable there could be other problems that would turn up because of this mis-match, if it were left as it is. For instance, a low-level data-recovery utility might become confused.

My explanation for this is that I think Windows must write something to the GPT that indicates where the ESP is. I think Sony has hardcoded the BIOS to look for this entry in the GPT when booting in UEFI mode, then try to find bootmgfw.efi.

The GPT data structures identify the ESP via its partition type code, which libparted-based tools identify as a "boot flag" being set. There are other data structures that Windows sets in particular ways for the ESP, but they're ancillary. I can't rule out the possibility that Sony's firmware is looking at such features, but I doubt it. Certainly the "incorrect" placement of the backup data structures offers a more compelling explanation.

So I think perhaps what bootrec /FixBoot does is put this Windows-specific entry in the GPT. I think Sony's BIOS either ignores efibootmgr (or efibootmgr is buggy).

It's entirely possible that efibootmgr is buggy. I have my own doubts about it, for various reasons; but at this point, it's looking to me like your specific problem is caused by mismatched RAID settings. Note that this could be the case even if you have just one hard disk; with RAID enabled in the firmware, it could be that the firmware's RAID drivers are taking over part of the disk, even though doing so provides no benefits.

As an aside, the Sony BIOS has a setting that specifically states whether one boots in UEFI mode or Legacy (BIOS) mode, so there is no possibility for confusion there.

In that case, Sony's EFI is far better than many others. Many of them try to figure it out based on partition table type, boot code in the MBR, the existence of an ESP, or other features that aren't 100% reliable.

[empyrien]

This type of problem is common in misconfigured RAID setups. Typically, a motherboard-mediated RAID driver "steals" part of one or all of the disks so that it can store its RAID information. The OS should then "see" the disk as being a bit smaller than it really is. The problem is that if the OS doesn't load the appropriate RAID driver, it'll access the disk directly, and if the disk was prepared with the RAID software enabled, the OS with RAID software disabled will see the disk as being bigger than the GPT data structures claim it is. The solution to this problem is to synhronize the RAID settings between the firmware and all the OSes installed on the computer. That is, either install and enable motherboard RAID drivers in Linux or disable the RAID feature on the motherboard (and perhaps in Windows, too). Failure to do this can result in strange problems and even data loss, so I strongly recommend you look into this matter in more detail. Note that this has nothing to do with EFI, except for the fact that your firmware is EFI, so you'll need to use EFI interfaces to check the firmware side of the equation.

Yes and no. It's most likely not GParted per se, but mismatched RAID settings. If I'm right and RAID was enabled in your firmware but not in Linux, then when GParted (or the Mint partitioner) wrote a new partition table, it would have pointed to backup GPT data structures "beyond the end of the disk," as far as the firmware (with RAID enabled) was concerned. This could cause any number of other problems. When you subsequently booted with Windows and repaired matters, it could have "corrected" the "problem" on the disk. This would work, but would also likely lead to a repeat of the problem in the future, whenever you next partitioned the disk in Linux. It's conceivable there could be other problems that would turn up because of this mis-match, if it were left as it is. For instance, a low-level data-recovery utility might become confused.

I'm not really sure what you mean by "RAID was enabled in your firmware but not in Linux." It seems to me that Linux is picking up the RAID successfully:

Code: Select all

$ lspci  -vvv | grep -A14 RAID
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04)
	Subsystem: Sony Corporation Device 9099
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 41
	Region 0: I/O ports at 7088 [size=8]
	Region 1: I/O ports at 7094 [size=4]
	Region 2: I/O ports at 7080 [size=8]
	Region 3: I/O ports at 7090 [size=4]
	Region 4: I/O ports at 7060 [size=32]
	Region 5: Memory at b9417000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci

$ lsmod | grep raid
dm_raid45              78155  0 
xor                    12894  1 dm_raid45
dm_log                 18564  3 dm_raid45,dm_mirror,dm_region_hash

The actual hardware setup is 2x128 GB SSDs in RAID-0 formation over a hardware controller. If you have any suggestions about how to further test whether or not there is a problem with my RAID configuration I'd be happy to hear it.

I know some people have said not to use Gparted with RAID, but I assumed that this was either outdated advice or applied to software RAID configurations. I'm assuming that if Linux is detecting the RAID controller correctly that Gparted is safe to use.

[AlbertP]

There are some problems with motherboard RAID in grub-install and/or the Mint installer (not sure which of both causes the problem). If you have a /boot partition or disk outside the RAID array, installing on RAID may work better. Though I don't know if EFI machines have these problems as well.

[srs5694]

I'm not extremely familiar with dmraid, so I can't really say how you should be using it from Linux. It is, however, an added layer of complexity. You say you're using a laptop, but you haven't explicitly said how many disks you've got. If you've got just one disk, then RAID is an unnecessary added layer of complexity. In that situation, it can cause nothing but problems, so removing it from the equation makes sense. If, OTOH, you actually have two hard disks and are using RAID, then it's worth your while to figure out how to use it in Linux, but I'm not the best person to be giving advice on this topic.

[shadownai]

Hi, so I've recently purchased a new Sony Vaio as well (mine is a 3rd gen E Series) and I've been running into the exact same issue. First off- thank you for posting your solution. It answered a lot of questions I had as to why I couldn't get the dual boot with Mint 13 working properly.

My situation varies from yours in that I am one of the people who would like to keep my installation of Windows 7 alongside the Mint partition. Instead of going the route that you took and trying to boot through the UEFI I decided it would just be easier if I went back to legacy and chose to boot without the UEFI. Note- I'm still working with the original partition table that came with the laptop (an EFI partition, a Recovery Partition, a Windows 7 partition and one other of which I don't know the contents- it's 134mb). During the installation, Linux Mint required that I create a "Reserved BIOS boot area" and warned that if I didn't I would most likely be unable to boot. The Bios boot area can not have anything mounted to it. So I added this partition (512mb) along with a swap partition and a partition containing the main file system (my root folder and everything else).

My understanding was that the BIOS would completely ignore the EFI partition that was there and would recognize the boot loader that was put in /dev/sda; however, this was not the case. I now get an error saying that no OS could be detected during boot. I haven't lost anything critical and can still access Windows 7 by switching back to UEFI if needed. I guess I'm not entirely sure what the Reserved BIOS boot area is for and would like clarification/insight as to where my logic is failing me.

I can use a Windows 7 CD to repair the the bootrec if needed and am willing to play around a bit. As a final option I could destroy the partition table and start fresh, but I wouldn't think that would be necessary.

I appreciate the help.

[empyrien]

My understanding was that the BIOS would completely ignore the EFI partition that was there and would recognize the boot loader that was put in /dev/sda; however, this was not the case. I now get an error saying that no OS could be detected during boot. I haven't lost anything critical and can still access Windows 7 by switching back to UEFI if needed. I guess I'm not entirely sure what the Reserved BIOS boot area is for and would like clarification/insight as to where my logic is failing me.

I can use a Windows 7 CD to repair the the bootrec if needed and am willing to play around a bit. As a final option I could destroy the partition table and start fresh, but I wouldn't think that would be necessary.

I appreciate the help.

Hi.

Unfortunately switching the BIOS to boot in legacy mode isn't sufficient. The reason is that the original partition table is in GPT format and as far as I know, Windows 7 64-bit can only boot from a GPT partitioned disk in UEFI mode. If you want Windows to boot in legacy mode then the disk has to be partitioned using an MBR type partition table.

So you have two options as far as I can tell:

1. The first option is to boot both Windows and Linux in UEFI mode. I think the best way to do this is to rename Windows "bootmgfw.efi" in the ESP to something else and replace it with GRUB's efi file. Then you will need to use GRUB to have the option of either booting into Linux or chain-loading into Windows. It may be possible to use the Windows utility "bcdedit" to get Windows to chain-load into grub but I haven't tried to do this myself.

In this case you won't need the "bios_grub" partition but you should make sure you are in UEFI mode when installing Mint.

2. The second option is to boot both Windows and Linux in Legacy mode. This is more hassle. You need to repartition the entire disk using an msdos (MBR) type partition table. You will need to reinstall Windows and then reinstall Linux. In this case, both Windows and Linux will need separate boot partitions. Windows will automatically create a 100 MB system partition that contains it's boot files if you use it to create the windows partition that you install on. You will need to create a separate Reserved BIOS partition for Linux (in addition to the other partitions that Linux needs) and mark it with the "bios_grub" flag, This partition is used by GRUB to store files needed for booting in BIOS mode. 128 MB should be plenty for this one.

The trouble with this option is that you need a proper WIndows 7 CD -- I don't think you can use the Sony Recovery Media as this will write a GPT partition table to your disk.

If you have more questions let me know.

[empyrien]

There are some problems with motherboard RAID in grub-install and/or the Mint installer (not sure which of both causes the problem). If you have a /boot partition or disk outside the RAID array, installing on RAID may work better. Though I don't know if EFI machines have these problems as well.

As an experiment to test whether or not it was Gparted that was causing the problems I wiped the partition table and used gdisk instead to create a GPT partition table, then attempted to install Linux. I came across the same problems. I also discovered that it may in fact be necessary to have first installed Windows to the partition that you intend Linux to boot from, and then reformat and install Linux to that partition, The reason appears to be that the bootrec /FixBoot trick only seems to work if it "finds" a "Windows installation" -- this will be apparent once you select the repair option.

Testing shows that it is only after using the Windows utility bootrec /FixBoot that Linux reports errors in the location of the backup GPT, I can use gdisk to repair the error and the system will still boot, If I use gparted to fix the error the system becomes unbootable.

From this I can reasonably conclude that it is highly likely that Windows does something special to the GPT that Sony's EFI BIOS is hardcoded to look for.

It is also possible that Windows and Linux disagree about the location of the end of the disk, but if this was the only issue then it doesn't explain all the other problems getting Linux to boot.

[shadownai]

Thanks for the response. I did a little more playing around and got some (I'm trying to stay optimistic) interesting results. I understand what you were saying about the GPT vs MSDOS (did some reading of my own as well) and it makes sense that just kicking it back to legacy mode doesn't help.

I decided to go with the first option as basing things around GRUB definitely seems easier and GRUB is much more easily customizable imo. I changed my BIOS back to UEFI boot mode and reinstalled Mint 13 using /dev/sda as the location for the bootloader and /dev/sda6 as root. Also, I set /dev/sda1 (the EFI partition created by Sony) to be recognized as the EFI Boot Device by the linux installer and used gparted to flag it as boot. After installation I mounted the ESP (sda1) and copied the /EFI/linuxmint/boot/grub64x.efi file to /EFI/Windows/Boot/bootmgfw.efi (and kept the old file) as per the suggestion. After reboot it still goes to Windows.

For clarification, my partition table looks something like this-

/dev/sda-
sda1 - fat32, 260MB - boot (recognized by the installer as EFI)
sda2 - ntfs, 16GB - hidden and diag
sda3 - fat32, 260MB - no flags
sda4 - unknown, 128mb - msftres
sda5 - ntfs, 372gb - no flags (windows 7 partition)
sda6 - ext 200gb - no flags (root folder for Linux Mint 13)
sda7 - 16gb - swap space - no flags

After some digging I found that sda3 is almost identical to sda1. It contains the 3 folders- boot, linuxmint and microsoft. sda1 has these three folder except that Boot and Microsoft are capitalized. Also the Microsoft folder within the sda1 partition contains what appear to be language packs with their own bootmgfw.efi.mui and bootmgr.efi.mui files- it's about 5MB larger. I rewrote the bootmgfw.efi within the sda3 partition as well just in case the BIOS was reading that as the boot partition instead. I highly doubt it was but I figured I would try. That understandably made no difference. I'm not sure how relevant that partition is to my boot problems.

What I don't understand is why rewriting the file in sda1 made no difference at all to the boot process as it did when you did it. I even tried using a Windows 7 install disk to fix the boot rec- that made no apparent difference. The obvious difference between our scenarios is that I used the original Sony partition table and you started with a fresh one; however, I can't see how that would make any difference.

Any suggestions?