I have installed Ubuntu 19 64bit alongside Windows 10 64bit and I found that I have 3 different EFI files in different locations:
What are the differences between these three files?
EFI\boot\bootx64.efi: Fallback bootloader pathThis 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.
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:
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-installWhen 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.
shimx64.efi and the reasons for itSecure 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.
