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

Question

I bought a new Sony Vaio S series laptop. It uses Insyde H2O BIOS EFI, and trying to install Linux on it is driving me crazy.

root@kubuntu:~# parted /dev/sda print
Model: ATA Hitachi HTS72756 (scsi)
Disk /dev/sda: 640GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End    Size    File system  Name                          Flags
 1      1049kB  274MB  273MB  fat32        EFI system partition          hidden
 2      274MB  20.8GB  20.6GB  ntfs        Basic data partition          hidden, diag
 3      20.8GB  21.1GB  273MB  fat32        EFI system partition          boot
 4      21.1GB  21.3GB  134MB                Microsoft reserved partition  msftres
 5      21.3GB  342GB  320GB  ntfs        Basic data partition
 6      342GB  358GB  16.1GB  ext4        Basic data partition
 7      358GB  374GB  16.1GB  ntfs        Basic data partition
 8      374GB  640GB  266GB  ntfs        Basic data partition

What is surprising is that there are 2 EFI system partitions on the disk. The sda2 partition is a 20gb recovery partition which loads windows with a basic recovery interface. This is accessible by pressing the "ASSIST" button as opposed to the normal power button. I presume that the sda1 EFI System Partition (ESP) loads into this recovery.

The sda3 ESP has more fleshed out entries for Microsoft Windows, which actually goes into Windows 7 (as confirmed by bcdedit.exe on Windows). Ubuntu is installed on sda6, and while installation I chose sda3 as my boot partition. The installer correctly created a sda3/EFI/ubuntu/grubx64.efi application.

The real problem: for the life of me, I can't set it to be the default! I tried creating a sda3/startup.nsh which called grubx64.efi, but it didn't help -- on rebooting, the system still boots into windows. I tried using efibootmgr, and that shows as it it worked:

root@kubuntu:~# efibootmgr 
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
root@kubuntu:~# efibootmgr --create --gpt --disk /dev/sda --part 3 --write-signature --label "GRUB2" --loader "\\EFI\\ubuntu\\grubx64.efi" 
BootCurrent: 0000
BootOrder: 0002,0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Boot0002* GRUB2
root@kubuntu:~# efibootmgr
BootCurrent: 0000
BootOrder: 0002,0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Boot0002* GRUB2

However, on rebooting, as you guessed, the machine rebooted directly back into Windows.

The only things I can think of are:

1. The sda1 partition is somehow being used
2. Overwrite /EFI/Boot/bootx64.efi and /EFI/Microsoft/Boot/bootmgfw.efi with grubx64.efi [but this seems really radical].

Can anyone please help me out? Thanks -- any help is greatly appreciated, as this issue is driving me crazy!

Answer 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.)

Answer 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.

Answer 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

Answer 4

I suggest two different alternatives:

1. Don't overwrite windows mbr but use it to launch grub

2. change bios settings (f2 or f3 at startup) in boot options from UEFI to LEGACY, then it will normally launch the last system installed as ever

Answer 5

1. Run Boot-Repair from a liveCD/liveUSB
2. Click the Recommended Repair button. (this will automatically install correct parameters for grub-efi, including SecureBoot parameters if needed, and renaming the EFI files in case the UEFI firmware is locked to Windows files). Indicate the URL that will appear if any problem.