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!


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.

| improve this answer | |
  • This worked! A friend of mine who helped me with this mentioned that he was unsure if this change would survive a Windows Update. If you know if this might be affected (or unaffected), I'd greatly appreciate it. Thanks so much! – tigerwins May 30 '17 at 3:41
  • It survives normal updates, but will not survive a reinstall of the boot manager... IE an upgrade to win10 or reinstall of win8.1 – ravery May 30 '17 at 3:45
  • Okay, that makes sense. I don't expect to upgrade Windows before I get a new laptop, so it shouldn't be a problem. Thanks again! – tigerwins May 30 '17 at 3:50

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:

| improve this answer | |
  • my fix is not a band-aid.... all of your documentation supports my fix. And actually all that documentation you keep posting is how I figured out my fix. with my own computer (which by the way didn't do OS booting) – ravery Jul 14 '17 at 23:25
  • @ravery, as described in my answer, the symptoms reported indicate a serious problem -- most likely filesystem damage -- that's not addressed by your solution. That solution has worked temporarily to work around the problem, but the underlying cause has not been addressed. Hence, it's a workaround, not a solution. – Rod Smith Jul 15 '17 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.