I have installed Ubuntu 19 64bit alongside Windows 10 64bit and I found that I have 3 different EFI files in different locations:

  • EFI\boot\bootx64.efi
  • EFI\ubuntu\grubx64.efi
  • /boot/grub/x86_64-efi/grub.efi

What are the differences between these three files?

  • 1
    Typically both Windows & grub2 install bootx64.efi as a fallback or hard drive UEFI boot entry. That also is the standard path & file for all external devices. You should have both /EFI/ubuntu/grubx64.efi and /EFI/ubuntu/shimx64.efi. Shim is for Secure boot but will boot with Secure boot off. not sure why we still have grub then? Not sure where you grub.efi came from. You must at some point installed another distribution that uses default grub entry.
    – oldfred
    Feb 4, 2020 at 14:46
  • 2
    I am researching to get a multi linux distro usb drive with EFI (I already created one for MBR but it doesn't work on recent computers with BIOS that only support EFI) and found this page that will answer your questions and explain EFI in a very detailed manner. Since it is large for an answer I'll just put the link in case you want to understand how it all works: rodsbooks.com/efi-bootloaders
    – YoMismo
    Mar 3, 2020 at 12:10

1 Answer 1


EFI\boot\bootx64.efi: Fallback bootloader path

This is the only bootloader pathname that the UEFI firmware on 64-bit X86 systems will look for without any pre-existing NVRAM boot settings, so this is what you want to use on removable media.

Windows will install a copy of its bootloader to this path automatically; when installing GRUB, the grub-install (or grub2-install depending on Linux distribution) command may also put a copy of the respective bootloader here if it does not already exist. If you want, you can use grub-install --removable to tell it to install to the fallback boot path, or grub-install --force-extra-removable to overwrite any existing bootloader in the fallback path and replace it with GRUB.

If you want to create a Secure Boot-compatible USB stick for UEFI, you should place a copy of the shim as EFI\boot\bootx64.efi and a copy of GRUB as EFI\boot\grubx64.efi, as the shim bootloader will look for grubx64.efi in the same directory the shim bootloader is in.

Bootloader path for a permanently installed OS

When an operating system is installed permanently to a UEFI system, there is one new step that absolutely did not exist on classic BIOS. When installing the bootloader, four things are written to the NVRAM memory that holds the firmware settings:

  • Bootloader pathname on the EFI System Partition (ESP) that holds the bootloader(s)
  • the GUID of the ESP partition
  • a descriptive (human-friendly) name for this particular bootloader instance
  • optionally, some data for the bootloader

For Windows, the standard UEFI pathname for the Windows boot process will be \EFI\Microsoft\Boot\bootmgfw.efi, and the descriptive name will be "Windows Boot Manager". The optional data seems to contain a GUID reference to something within the Windows bootloader's BCD configuration file.

For Ubuntu, the pathname should be \EFI\Ubuntu\grubx64.efi if you don't need Secure Boot support, or \EFI\Ubuntu\shimx64.efi if the Secure Boot shim is used. The descriptive name is simply "ubuntu" and the optional data is not used.

In Ubuntu, these UEFI NVRAM boot settings can be viewed using the sudo efibootmgr -v command; in Windows, you can start a Command Prompt as Administrator and then use the bcdedit /enum firmware command to view the settings.

The UEFI specification has a standard convention that each vendor should place the bootloader for a permanently installed OS within the path \EFI\<vendor name> on the ESP, so having multiple UEFI bootloaders co-exist on the same ESP is actually supported and should make things easier than with classic BIOS that had a single Master Boot Record per disk.

/boot/grub/x86_64-efi/grub.efi: a temporary file for grub-install

When grub-install is used, it will first use the grub-mkimage utility to create a GRUB core image: on a UEFI system, this file will be saved at /boot/grub/x86_64-efi/grub.efi and/or .../core.efi before it will be copied to the EFI System Partition and added to the UEFI NVRAM boot settings by grub-install. The copy in /boot/grub/x86_64-efi/*.efi will not be used at all in the boot process, but it might be useful if the ESP gets damaged for any reason.

Note: On Debian/Ubuntu, the generated GRUB core image will include a baked-in UUID reference to whichever filesystem contains the /boot directory, so you won't be able to just make a copy of either /boot/grub/x86_64-efi/grub.efi or grubx64.efi from the ESP and transplant it to a removable media: it will just attempt to find the unique UUID of your /boot filesystem and will drop to rescue mode if it won't find it. If I recall correctly, the GRUB of RedHat/CentOS/Fedora should be more suitable for transplantation to removable media.

Secure Boot: shimx64.efi and the reasons for it

Secure Boot requires that a bootloader must be signed by a certificate that is included in the system's Secure Boot NVRAM variable db, or the bootloader's SHA256 hash must be whitelisted in the same NVRAM variable. A SHA256 hash will only match a specific version of a particular bootloader, so updates won't be possible unless the firmware variable is also updated. So the certificates are the way to go.

Unfortunately, many system vendors will only include a few Secure Boot certificates to their products: often only the vendor's own certificate (for firmware updates and hardware debugging/OEM configuration tools) and Microsoft's Secure Boot certificates. Some systems will allow editing the list of Secure Boot certificates through firmware settings (="BIOS settings"), but others won't. So an independent solution was needed.

Microsoft offers an UEFI bootloader signing service for anyone, but at least initially the turnaround time for signing was quite long, so the requirement to sign every version of GRUB directly would have caused unacceptable delays in bootloader updates. To solve the problem, the shim bootloader was developed: it's basically the simplest reasonable UEFI program that will add one or more certificates to the Secure Boot accepted list. The simplicity will hopefully reduce the need to update the shim itself, so the open-source OS distributions (Linux and others) can just get their version of the shim signed by Microsoft just once and then sign any version of GRUB with their own certificates, whose public part is embedded in the shim and allows Secure Boot accept the distribution's version of GRUB.

  • Thanks for answer. BTW, AFAIK bootmgfw.efi is'nt Windows bootloader, it's Windows Boot Manager, which calls Windows bootloader \Windows\System32\winload.efi. Also what do you mean by NVRAM? CMOS? Mar 5, 2020 at 7:57
  • 3
    I tried to not be too verbose and looks like I oversimplified regarding the "Windows bootloader" issue. And yes, by NVRAM I mean the non-volatile storage that contains the firmware settings, which on classic PCs was also known as CMOS memory but on modern systems may actually use some technology other than CMOS (Complementary Metal Oxide Semiconductor).
    – telcoM
    Mar 5, 2020 at 8:02
  • 1
    So I can find this information in the future, note that if you don't have shimx64 in the EFI/ubuntu folder, and you want it, then do sudo apt-get install shim-signed, and it will magically appear in both the EFI/ubuntu folder, and in the output of sudo efibootmgr -v :) Jan 10, 2022 at 0:32
  • 1
    @HughPerkins I checked the postinstall script of the shim-signed package. Looks like it just runs grub-install --target=x86_64-efi, and grub-install will detect that shim-signed is installed and will do the actual job of installing the shimx64.efi into the proper directory on the ESP and updating the bootloader entry in the NVRAM.
    – telcoM
    Jan 10, 2022 at 14:49
  • Cool. Took me forever to discover the shim-signed package though. Tried running grub-install --target=x86_64-efi, and rebooting, and variations on that theme, and couldnt get shimx64.efi to appear. Installing shim-signed fixes this for me :) Jan 11, 2022 at 15:15

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.