How does EFI find bootloaders?
First the firmware looks for EFI variables Boot#### (e.g. Boot0000, Boot0001, and so on). They describe the EFI boot menu entries, and contain the complete location of the corresponding executable. For example:
$ sudo efibootmgr -v BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000,0001,0006,0007 Boot0000* Linux Boot Manager HD(1,800,32000,785c8ca2-bb16-48fd-917b-19d69543338f)File(\EFI\gummiboot\gummibootx64.efi) Boot0001* EFI Shell HD(1,800,32000,785c8ca2-bb16-48fd-917b-19d69543338f)File(\shellx64.efi) Boot0006 Hard Drive BIOS(2,0,00)P0: ST9640320AS . Boot0007 CD/DVD Drive BIOS(3,0,00)P1: SlimtypeDVD A DS8A5SH .
This describes location of a SATA hard disk; a GPT partition UUID; and a path within that partition.
(Usually, all boot entries will point to the EFI system partition (type code EF for MBR, and C12A7328-F81F-11D2-BA4B-00A0C93EC93B for GPT – shown as EF00 in gdisk), but this is not required.)
If the firmware does not have any boot entries stored, or if you're booting from removable media, it uses the fallback location – it will look for all EFI system partitions (with the matching partition type and FAT32 filesystem), and within those partitions it will expect to find an EFI executable at \EFI\BOOT\BOOTX64.EFI. (This path is for Intel x86_64 systems; other architectures use different filenames in the same directory).
EFI will not automatically try to boot any random *.EFI file even if it's on the EFI system partition.
See also:
- UEFI boot: how does that actually work, then? by AdamW
- FGA: The EFI boot process by Jonathan de Boyne Pollard
-
Managing EFI Boot Loaders for Linux by Rod Smith (author of
gdisk)
As best as I can tell, it appears that you're supposed to boot EFI by creating an ESP (an MBR partition with type-code 0xEF, formatted as some variant of FAT) and copy a *.efi file into it.
In my testing, any and all such files are completely ignored, unless the name of the file is exactly
/EFI/BOOT/bootx64.efi
So it appears that this is the magic name you have to use.
At this point, I have no idea whether this is part of the official EFI specification, or merely a quirk of my particular motherboard. I am posting this information here in case it helps somebody else...
Using this knowledge, I was able to copy the rEFInd files onto a USB disk, rename the main executable, and observe the laptop whine that the binary isn't signed. (Which it isn't.) So now it sees that there's something potentially bootable there. It appears that if I could turn off Secure Boot, the laptop would boot at this point.
(Sadly I can't currently get Shim to work - but that's a different question...)