Failed to open \EFI\Microsoft\Boot\grubx64.efi - 80000000000000E
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.
Related videos on Youtube
michaelbreen85
Updated on September 18, 2022Comments
-
michaelbreen85 over 1 year
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?
-
Organic Marble about 9 yearsIs this boot info that you posted from the run of boot-repair that caused the problem, or a later one?
-
michaelbreen85 about 9 yearsThe boot info was from after the initial run of boot-repair.
-
-
michaelbreen85 about 9 yearsYou 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.
-
Rod Smith about 9 yearsYou use the
-o
option toefibootmgr
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 copyshimx64.efi
toEFI/BOOT/bootx64.efi
and copygrubx64.efi
to the same directory under its original name. You may also need to copy the GRUB configuration file. -
michaelbreen85 about 9 yearsYes, 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.
-
Rod Smith about 9 yearsThe 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 (asgrubx64.efi
). -
michaelbreen85 about 9 yearsThanks 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!