It seems that non-existing boot entries are automatically deleted. When using a self encrypting drive and BIOS password to unlock it, this means that if you ever hit escape instead of entering your driver password, all your boot entries that point to that drive get deleted. I have tried both on BIOS 3.05 and 3.07, and with secure boot enabled and disabled.
This is interesting to me and would like to help you dig further. I wonder how the firmware is handling things differently in my scenario than yours.
I have one of the 1TB expansion cards that I test other operating systems on, and the firmware seems to have no problem picking up that drive and remembering my preference for it being the first boot device when it is inserted, and it remembers that even after booting to my NVMe without the expansion card drive inserted. Reinserting the expansion card and rebooting always brings up it’s grub menu again. I can even hibernate to disk the NVMe Ubuntu install, insert the card, and boot right up into the card’s OS.
I suppose my first question is, do you also have your EFI partition encrypted? Because it was my understanding that EFI partitions were supposed to be unencrypted FAT partitions, and those are read dynamically during POST. Even if your EFI partition is encrypted, because they should be dynamically loaded at POST, when it’s unencrypted, the entries should be loaded. When it’s encrypted and left that way, it simply doesn’t see them. The same as it does with my USB-based expansion card. When it’s not inserted, there are no EFI entries to read from it. When it is inserted, they get read.
In my case, the firmware is remembering that I prefer it boot from the expansion card’s EFI if it’s inserted. I simply manually selected my preferred boot order in BIOS with the card inserted and it remembers that. I do have to reselect correct order in BIOS if I let my EFI UUID change on the expansion card (by formating it, etc), because that is how the firmware stores the preferred boot order.
That all being said, I am not using Secure Boot at all, mostly because I’m booting and messing around between multiple distros. I am also not encrypting any drives or using BIOS password, but I don’t see how those factors would at all defeat the very essence of UEFI booting, outside of a yet-undescribed firmware bug or some other factor not yet known (something else special about your setup that negates something above).
Reinserting the expansion card and rebooting always brings up it’s grub menu again.
I am not using a bootloader. I’m registering the kernel directly with efibootmgr. With a suggestion from a friend and this hint I have figured out that the BIOS will see and boot an EFI executable in the default location EFI\BOOT\BOOTX64.EFI. I’ve managed to compile a kernel that doesn’t need an initramfs and has the cmdline built in, placed it in that location, and now even if all other entries are removed I can boot this kernel as the BIOS finds it. That at least gives me a backup/workaround to boot when all the other entries disappear.
I suppose my first question is, do you also have your EFI partition encrypted?
I’m using the self encrypting disk feature, so the disk itself handles all encryption in hardware. Once the BIOS supplies the password, it’s visible as a normal disk. So it does seem similar to your situation. I guess it could be different in that perhaps the disk controller still shows up, but I’m not certain. I can take a deeper look by booting to USB when the NVMe drive is still locked and see if /dev/nvme0 shows up.
Ah, that makes more sense, then. Perhaps Framework can adjust the behavior in future firmware to better retain those direct entries (keep entries cached unless actually overwritten by another efibootmgr command). In the meantime, keeping a copy in BOOTX64.EFI is your best workaround and should be totally harmless.
Reach out to Framework directly via the Support system and link them to this thread for reference. With the amount of traffic on here these days, they aren’t likely to find this topic on their own.