Sony VAIO with Insyde H2O EFI bios will not boot into GRUB EFI

Solution 1:

I was eventually able to solve this. I replaced the EFI/Microsoft/boot/bootmgfw.efi with the grub64.efi. I renamed the former to bootmgfw.efi.old and used grub to add a menu option to chainload into it.

This implies that the firmware is hardcoded to look for the microsoft windows bootloader, and does not respect efibootmgr settings, or startup.nsh. That's really terrible.

I found out how the Sony EFI boot process works:

1. Look in /EFI/Microsoft/Boot/fwbootmgr.efi; if present, boot it.
2. Look in all sub-directories of /EFI/ for grubx64.efi. If present, boot it.
3. Boot /EFI/Boot/bootx64.efi
4. Display an error message, such as "Operating System not found".

Under Linux, the efibootmgr tool does work, but it displays a lot of auto-generated nonsense, including the last USB drive you've used.

Here's how I learned all this:

1. I opened up my new machine and collapsed the Windows partition in order to install Linux and Mac side by side.
2. I installed Ubuntu 12.10 and the installer overwrote fwbootmgr.efi, backing up the old Windows bootloader.
3. I restored the old Windows bootloader, but couldn't boot anything except Windows.
4. I renamed the Windows bootloader to something bogus, and then the Grub BL took over.
5. I renamed the ubuntu directory to something else, and Grub still loaded, even though I had install rEFInd.

6. The only way I could get rEFInd to do what I wanted was this:

7. Move fwbootmgr.efi to its parent directory; rEFInd will still find it, and Windows won't complain that you renamed it.

8. Rename grubx64.efi to rfgrubx64.efi or something else recognizable.
9. Copy rEFInd from /EFI/refind to /EFI/boot, rename /EFI/refind_x64.efi to *.bak, and lastly rename /Boot/refind_x64.efi to bootx64.efi. You should now be able to boot the Windows BL or GRUB from rEFInd. I plan to upgrade my MacOS install to Clover, and load Clover from rEFInd as well.

(Perhaps it is possible to use the Windows Boot Manager to do all this, but EeasyBCD's EFI support is still a mess in my experience. I refuse to touch it again for a while.)

Solution 2:

First, you don't have two ESPs. An ESP is a partition with a partition type code of C12A7328-F81F-11D2-BA4B-00A0C93EC93B, which parted identifies as a partition with its "boot flag" set. Your output indicates that only /dev/sda3 has its "boot flag" set, so you've got only one ESP -- /dev/sda3. Under GPT, partitions can have names, and you've got two partitions with the name "EFI system partition," but these names are used for human identification purposes only. Thus, my guess is that you (or some automatic utility) created a /dev/sda1 with the intent of making it an ESP, but either there was an error in setting its partition type code or some other utility improperly changed its type code from C12A7328-F81F-11D2-BA4B-00A0C93EC93B to something else.

There are a number of ways you can correct this. The simplest is to just change the name of /dev/sda1 to avoid confusion. If you think that /dev/sda1 serves no purpose, you could back it up and delete it. This will get it out of the way and avoid confusion, but of course you'll then have 273 MB of unused disk space. Alternatively, you could devote the space to some other purpose, if necessary changing the name and type code to avoid confusion. EFI explicitly allows multiple ESPs, so you could change the type code (by setting the "boot flag" using parted, for instance) and use both ESPs; but this could be confusing.

Chances are that this issue is unrelated to your inability to boot Linux, since it sounds like all the relevant files are on /dev/sda3. Several possible reasons for this problem occur to me:

• It could be you've mistyped something in your efibootmgr command. I don't see any obvious typos, but if the GRUB binary isn't located where you've specified, the command won't work. The "--gpt" and "--write-signature" options are almost certainly unnecessary, and could conceivably be causing problems, but most likely aren't.
• Your firmware could have a bug that's causing the efibootmgr command's effects to be temporary. Try rebooting and then type "sudo efibootmgr -v" to see if the entry you created has survived a reboot.
• Your firmware could have a bug that's causing the boot order variable to be ignored. I've got a motherboard like that; it boots in the order in which the boot entries are created, rather than the order in which they're specified by the BootOrder variable. To work around this bug, you would have to delete all the entries and re-create them in the boot order you want to use.
• Your grubx64.efi binary could be damaged in such a way that the firmware refuses to launch it, and so it goes on to the next item in the boot order.

You can try adjusting your efibootmgr command, locate a new binary, or whatnot to test these possibilities. If all else fails, I recommend you do the following:

1. Delete all the boot entries using efibootmgr or your firmware (if it provides an interface to do this).
2. Copy grubx64.efi to EFI/Boot/bootx64.efi on the ESP.
3. If when you reboot you still get Windows, rename EFI/Microsoft/Boot/bootmgfw.efi to EFI/Microsoft/bootmgfw.efi.

This should get GRUB booting using the default name for the boot loader (EFI/Boot/bootx64.efi). One problem with this is that GRUB might not have a working entry for Windows. You can probably create one manually; an entry like this should work:

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/bootmgfw.efi
}

Alternatively, you could install rEFIt or rEFInd as EFI/Boot/bootx64.efi. Note that the rEFIt binaries available from its site won't work on UEFI-based PCs; you'll need to use the version in the Ubuntu repositories. rEFInd is a fork of rEFIt with numerous bug fixes and updates, including better UEFI support. (rEFIt seems to have been abandoned about two years ago.) Thus, I recommend using rEFInd rather than rEFIt -- but I'm rEFInd's maintainer, so I'm not an independent observer on this score. Unfortunately, AFAIK rEFInd isn't (yet) included in the Ubuntu repositories, so you'll have to download and install it manually.

Solution 3:

Same starting position here on a new sony vaio e series. Thanks Rod for your answer.

Just in case someone needs a walkthrough, this is what worked for me:

Installed ubuntu 12.04 from USB alongside win7.

mounting /dev/sda3 from live-session

• copy EFI/ubuntu/grubx64.efi to EFI/Boot/
• rename EFI/Boot/bootx64.efi to bootx64.efi.old
• rename EFI/Boot/grubx64.efi to bootx64.efi

now it booted directly into grub2, but without win7 entry

after loading ubuntu I edited

/etc/grub.d/40_custom

adding

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

and after

sudo update-grub

everything works fine