2

I have a fresh install of 14.04 on a new SSD. Everything was running fine until I ran boot-repair for some reason that I cannot remember. Now when I boot up I get the following errors:

Failed to open \EFI\Microsoft\Boot\grubx64.efi - 80000000000000E
Failed to load image
Failed to open \EFI\Microsoft\Boot\MokManager.efi - 80000000000000E
Failed to load image
Failed to open "\EFI\BOOT\fallback.efi": 14
Failed to open \EFI\BOOT\grubx64.efi - 80000000000000E
Failed to load image
Failed to open \EFI\BOOT\MokManager.efi -80000000000000E
Failed to load image

This new HDD has never had Windows installed, so is it possible that boot-repair added those files? Can I simply delete them?

Boot info shows the following:

Boot files: /EFI/Boot/bootx64.efi /EFI/ubuntu/MokManager.efi
/EFI/ubuntu/grubx64.efi /EFI/ubuntu/shimx64.efi
/EFI/Microsoft/Boot/bootmgfw.efi
/EFI/Microsoft/Boot/bootx64.efi

Here is a link to the full boot info- http://paste.ubuntu.com/10583113/

How should I proceed?

Fabby
  • 34,259
michaelbreen85
  • 23

2 Answers2

1

Boot Repair will sometimes copy GRUB to other filenames, including those that are normally used by Windows.

You didn't say whether you're able to boot normally after those errors appear, but your Boot Repair output makes it look like you can; specifically:

=================== efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 3003,3001,3004,2001,2002
Boot0000* Notebook Hard Drive   BIOS(2,500,00)................-.`.......`.A.`........................................
Boot0001* ubuntu    HD(1,800,100000,3c6d1212-54d5-4b03-8eb6-680c74425f10)File(EFIubuntushimx64.efi)
Boot0002* Internal CD/DVD ROM Drive BIOS(3,500,00)................-.g.......g.A.g........................................
Boot0003* Windows Boot Manager  HD(1,800,100000,3c6d1212-54d5-4b03-8eb6-680c74425f10)File(EFIMicrosoftBootbootmgfw.efi)RC
Boot0004* Ubuntu    HD(1,800,100000,3c6d1212-54d5-4b03-8eb6-680c74425f10)File(EFIubuntugrubx64.efi)RC
Boot2001* USB Drive (UEFI)  RC
Boot2002* Internal CD/DVD ROM Drive (UEFI)  RC
Boot3001* Internal Hard Disk or Solid State Disk    RC
Boot3003* Internal Hard Disk or Solid State Disk    RC
Boot3004* Internal Hard Disk or Solid State Disk    RC

This is the output of sudo efibootmgr -v. Don't freak out over it; you can ignore most of the long scary hexadecimal numbers. Pay particular attention to the BootCurrent and BootOrder lines. The BootCurrent line tells you how the OS booted -- in this case, by using the Boot0001 option, which you can see is for Ubuntu. The BootOrder line, however, indicates that the computer is configured to try several other options before that one. These are default boot loaders -- normally EFI/BOOT/bootx64.efi, but it's entirely possible that your computer uses EFI/Microsoft/Boot/bootmgfw.efi for some of these. My hunch is that Boot Repair copied GRUB to one or both of these locations, but with Secure Boot active, GRUB won't launch without the help of Shim (shimx64.efi). Hence your error messages, which I'm guessing come from your firmware.

The most puzzling thing about this is that you booted via the Boot0001 (Ubuntu) entry despite the fact that it's not on the BootOrder list. Maybe your firmware goes off-list when nothing else works, or maybe it's actually on the list but is not being reported by efibootmgr for some reason.

In theory, you should be able to overcome this problem by typing the following command in Linux:

sudo efibootmgr -o 1,3003,3001,3004,2001,2002

This changes the BootOrder line to be what it is now, except with the working Ubuntu entry first. I'd try this before deleting any files. If this doesn't work, though, go ahead and rename the EFI/BOOT/bootx64.efi and/or EFI/Microsoft/Boot/bootmgfw.efi files, or the directories in which they reside. If you can boot after renaming these files or directories, go ahead and delete them. If renaming them makes matters worse, you can use an emergency disk to rename them back to their original names.

Rod Smith
  • 44,284
  • 7
  • 63
  • 105
  • You are correct in assuming that I am able to boot into Ubuntu. The puzzling thing is that I have tried changing the boot order with efibootmgr -c. After a reboot, any changes are forgotten. However if I use -n for the next boot, the changes will work temporarily. I changed the order to 0001, 0002, 0003 and had a clean boot without any errors. – michaelbreen85 Mar 16 '15 at 23:13
  • 1
    You use the -o option to efibootmgr to change the boot order, not -c. If that was a typo in your response, then I recommend you rename or delete those extra files, or copy shimx64.efi to EFI/BOOT/bootx64.efi and copy grubx64.efi to the same directory under its original name. You may also need to copy the GRUB configuration file. – Rod Smith Mar 17 '15 at 00:06
  • Yes, that was a typo. So am I replacing bootx64.efi with shimx64.efi in the EFI/BOOT folder? You may need to walk me through step by step. I'm a relative newbie at this. – michaelbreen85 Mar 17 '15 at 17:55
  • The normal boot process is: EFI->EFI/ubuntu/shimx64.efi->grubx64.efi. (Shim launches GRUB in the same directory.) The fallback boot path, from the EFI's perspective, is EFI->EFI/BOOT/bootx64.efi, so you want to put Shim there and have GRUB in the same directory (as grubx64.efi). – Rod Smith Mar 19 '15 at 01:24
  • Thanks for the help Rod. I got rid of the EFI/Microsoft folder and got back to a nice clean, error free boot. I'm glad it was such a simple fix! – michaelbreen85 Mar 20 '15 at 05:07
0

So I was able to solve this problem by simply deleting the EFI/Microsoft folder. I'm guessing that boot repair created this folder, but it is not needed on my Ubuntu only setup.

NOTE: This is not a good fix for most cases, especially if you want to be able to use Windows in the future. Make sure you know what you're doing before deleting essential system files like this.

Michael Hoffmann
  • 3,595
michaelbreen85
  • 23