Which UEFI executables get auto-detected?

Question

According to this phenomenal overview of UEFI, there are 3 types of UEFI entries:

• Compatibility-boot will boot whatever is at the beginning of the disk, like BIOS did
• Native-boot will boot an EFI executable from an explicit path
• Fallback-boot will boot an EFI executable from various default locations (based on architecture, /EFI/BOOT/BOOTx64.efi, /EFI/BOOT/BOOTaa64.efi, etc.)

All this makes sense, but when I look at an EFI System Partition from an OS (CentOS, in this case) there are many more .efi files.

+--EFI
|  +--boot
|  |  +--BOOTAA64.EFI
|  |  \--fallback.efi
|  +--centos
|  |  +--gcdaa64.efi
|  |  +--grubaa64.efi
|  |  +--MokManager.efi
|  |  +--shim-centos.efi
|  |  \--shim.efi

Additionally, the boot manager only lists an option to boot /EFI/centos/shim.efi. This CentOS disk came from another computer, so the firmware on this machine never had an explicit entry added for shim.efi.

Why are there so many .efi files?

How did the boot manager find shim.efi?

Why didn't the boot manager find all the other .efi files?

This question is similar, but is more about the distinction between fallback and native booting.

Answer 1

Why are there so many .efi files?

Most of these files are support files. For instance, MokManager is a tool for managing Machine Owner Keys (MOKs), which are used by Shim to expand the number of Secure Boot keys that the computer recognizes. MokManager is typically called if Shim can't launch its default follow-on boot loader (typically GRUB). It looks like you've got at least two copies of Shim in EFI/centos (shim.efi and shim-centos.efi), and EFI/boot/BOOTAA64.EFI is probably a third copy of Shim. Chances are one of those in EFI/centos is redundant -- perhaps left over from a previous installation that used a different name or created by accident.

Linux developers have also gotten into the habit of creating new EFI program files to work around problems or special-case issues. For instance, your installation shows two copies of GRUB in the EFI/centos directory -- grubaa64.efi and gcdaa64.efi are identical except for where they look for their configuration and support files. (See this Stack Exchange question and answer for slightly more on this issue.)

How did the boot manager find shim.efi?

You've already (partially) answered that question -- in what you called "native-boot," the computer stores a path to the boot loader in an NVRAM variable. Most Linux distributions these days use Shim by default, so the NVRAM variable will point to a Shim binary. When Shim launches, it will register itself with the firmware and then launch a follow-on boot loader (normally GRUB).

Why didn't the boot manager find all the other .efi files?

A standard EFI boot manager does not actively scan for .efi files, except for the fallback filename and, in some EFI's, Microsoft's boot loader. (There are others that might be added to the boot list in some cases, such as network boot entries and entries for a built-in EFI shell.)

Instead, most EFIs rely on the OS installer to register a boot loader as part of the boot loader installation process. Thus, CentOS will write Shim, GRUB, and related .efi binaries to the ESP, and then add one or more NVRAM entries to point to them. In theory, an OS could store ten, a hundred, a thousand, or more .efi files on the ESP and register just one of them. When you reboot and hit whatever keystroke is necessary to enter the EFI boot manager, you'll see just the one entry that the OS installer added. You can add, delete, or edit these entries with the efibootmgr tool in most Linux distributions.

AFAIK, the only tools that actively scan for EFI boot loaders are:

• rEFIt -- This old boot manager was used mainly on Macs, but it can be used on UEFI-based PCs. It actively scans for boot loaders in most subdirectories of EFI (that is, EFI/centos/, EFI/BOOT/, etc.), EFI/tools/ being a notable exception. Note that rEFIt is no longer being maintained.
• rEFInd -- This is my updated fork of rEFIt, and it inherits rEFIt's active-scanning algorithm, with some tweaks to make it work better with Linux and to explicitly trim redundant or otherwise unnecessary boot entries. Thus, rEFInd shows both .efi binaries and Linux kernels (which in most cases are EFI program files, thanks to the EFI stub loader).
• GRUB 2's configuration scripts -- Distributions that rely on GRUB 2 typically ship with scripts that scan for .efi files and add them to the GRUB menu. Unlike rEFIt and rEFInd, though, these scans occur when Linux (or some other host OS) is running, not at boot time.

Note that none of these tools affect what appears in the EFI's own boot manager menu; they all affect what appears in their own menus, nothing more. In theory, other tools might perform such scans. An EFI could do such scans, either at every boot or upon command from the user, but in practice I don't know of any that do; AFAIK, all EFIs rely on their own boot managers with associated NVRAM entries. (Some are buggy, which makes those NVRAM entries are unreliable, thus making use of the fallback filename a practical necessity.)