16.04 Dual Boot Install on Lenovo Yoga 2 Pro - /EFI/ubuntu/grubx64.efi not found after booting back into Windows

Question

I've been reading some other threads, especially about dual-boot installations on the Lenovo Yoga 2 Pro running windows 8.1, but I didn't seem to find quite the exact same issue. I'm admittedly a newcomer to this (my first time trying to install Ubuntu), so I'd appreciate any opportunity I can to learn more about this!

I set aside roughly 60GB for the partition and another 8 GB for the swap. I also installed grub on the /dev/sda2 partition, which is the ESP where Windows Boot Manager is also located.

I have specified that ubuntu/grub should boot first in the BIOS Boot Menu. Secure Boot and Lenovo Fast Boot are both disabled.

Everything is going fine so far. I can boot, and grub shows up, allowing me to select between Ubuntu and Windows Boot Manager. If I choose Ubuntu, I am able to get into Ubuntu, log in, etc., perfectly fine. The trouble starts when I choose to boot into Windows instead. Once I do that, and try to shutdown/restart and boot up Ubuntu, the following message appears:

Failed to open /EFI/ubuntu/grubx64.efi - Not Found  
Failed to load image /EFI/ubuntu/grubx64.efi: Not Found  
start_image() returned Not Found

I have verified on the Windows side that the files claimed to not exist are in fact in the specified folders. They were detected using the bcdedit /enum firmware.

I have also tried using the command

bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi 

in the Administrator Command Prompt with no luck.

After this, I booted live from a USB and did a boot repair, which fixed GRUB... until I booted back into the Windows side again, at which point the same issue occurred.

Any help would be greatly appreciated, and I'll try to provide any other information that might be helpful. Thanks!

Answer 1

efi expects the default boot loader to be /efi/boot/bootx64.efi. windows is particular about making sure it boots.

fist off, from 8.1 on windows does not really shut down, it suspends to disk ( like a hibernate) so that it boots faster. second it changes EFI to make entry 0000 (windows) first in the boot order.

the work around: rename grubx64.efi to bootx64.efi then replace the file efi/boot/bootx64.efi.this makes grub the default boot loader.

second: when in ubuntu, use efibootmgr to delete all efi entries. and reboot your computer. Make sure the first system you boot into is ubuntu so that it is placed in entry 0000. then boot windows.

Answer 2

The Failed to open, Failed to load image, and start_image() returned Not Found messages are from Shim. (You can check the source code; they're there in the shim.c file.) Ordinarily, when booting Ubuntu on an EFI-based computer, the system launches Shim (shimx64.efi), which is Ubuntu's way of dealing with Secure Boot. The Shim program then launches GRUB (grubx64.efi). Those error messages indicate that Shim launched, but GRUB was not present -- or could not be read. You wrote:

I have verified on the Windows side that the files claimed to not exist are in fact in the specified folders.

This indicates that grubx64.efi exists, but is not readable to Shim. The most likely explanation for this discrepancy between what Windows sees and what the EFI sees is that you have the Windows Fast Startup and/or Hibernate features enabled. These features turn a Windows shutdown operation into a suspend-to-disk operation in order to speed up the next boot. The problem is that this feature can leave filesystems, including the filesystem on the ESP, in an inconsistent state. This in turn can wreak havoc with the EFI's ability to read files from the ESP -- some files may seem to disappear randomly. As a general rule, EFI FAT filesystem drivers don't seem to be as robust as the FAT drivers in Windows or Linux, so a file might seem OK in Windows but be unreadable to the EFI.

The solution is to disable the Windows Fast Startup and Hibernate features, as described here and here, respectively.

It's also possible that the filesystem damage came about in some other way, but that the Windows drivers happen to be able to work around the problem, whereas the EFI drivers can't. Running a disk-check tool (like dosfsck in Ubuntu or CHKDSK in Windows) on the ESP might fix the problem. In extreme cases, backing up, creating a fresh filesystem, and restoring it may be necessary.

Note that ravery's solution is just a band-aid -- and a risky one, at that. (I've seen at least one computer that started to flake out badly after I deleted all the firmware's boot entries.) Copying GRUB to the fallback filename of EFI/BOOT/bootx64.efi might work in some cases (as it apparently has in yours), but in the absence of proper EFI boot variables, some EFIs will favor the Windows boot loader over the fallback boot loader. Worse, because ravery's solution doesn't address the underlying cause of the problem, it might recur, or some other filesystem damage might occur, which could result in other problems. (Fortunately, the number of files on the ESP is relatively small, so you likely won't end up with a completely trashed system; Windows and Ubuntu recovery tools can restore damaged ESP files.)

For more information on how EFI systems boot, beyond the use of the fallback filename, see:

• Adam Williamson's blog entry on how EFI works -- This page describes the theory behind EFI-mode booting.
• A question and answers on the differences between BIOS and EFI booting on Superuser.com -- This provides the basics of the preceding, but is more concise.
• My page on installing Linux on EFI systems -- This page is a more practical introduction to EFI-mode booting than Adam Williamson's blog.
• The Ubuntu community wiki entry on UEFI -- This page is a bit disjointed, but is the most Ubuntu-specific introduction to EFI and its issues.