Pretty much. EFI-mode booting involves two things:
- Boot loader files written to the EFI System Partition (ESP) on the hard disk.
- Pointers to the ESP-based files stored in NVRAM on the motherboard.
The intent is that you can install as many boot loaders as you like and provide an order in which the computer should try them. Users should also be able to override that order using their computers' built-in boot manager. In principle, this should greatly simplify multi-boot configurations.
Unfortunately, many computers delete NVRAM entries that point to devices that aren't available when the computer boots. Thus, when you swap disks, you can lose the ability to boot from them. IMHO, this is a design flaw in EFI.
Fortunately, there is a relatively easy workaround, but it requires some foresight to implement: In addition to the stored boot loader locations, a special one exists: EFI\BOOT\boot{arch}.efi
, where {arch}
is an architecture code -- normally x64
for x86-64 (AMD64) systems. This location is tried if no other boot entry works. It's normally used on removable media, but most EFIs will use it as a fallback for hard disks, too. Thus, if you copy GRUB or some other valid boot loader to EFI\BOOT\bootx64.efi
on the ESP (normally /boot/efi/EFI/BOOT/bootx64.efi
in Ubuntu), the disk will remain bootable even if the EFI boot entries are deleted. Note that you may need to copy boot loader configuration and support files, too.
FWIW, Fedora's got a boot loader called fallback.efi
that's designed to restore deleted NVRAM entries. I've not looked into it in depth, but putting it in the EFI\BOOT\bootx64.efi
location should fix this problem, too. The last I heard, though, some (broken) EFIs cause this file to run on every boot, and the result is an ever-increasing number of boot entries. This bug may well have been fixed by now, but I've not checked up on it recently.