Persisting UEFI entries

darkbasic commented 1 year ago

Every time I decrypt a drive the UEFI entries created with grub-install get lost and I have to boot the default entry (Boot/bootx64.efi). Some BIOS don't follow the UEFI standard and default to the Windows Boot Manager path instead, making the whole thing pretty annoying if you have a dual boot system (otherwise you can simply install grub in the Windows Boot Manager path instead). Some distros like Fedora found a way to make grub UEFI entries persistent across SED decryptions, making the grub entry survive the process and allowing you to boot Linux afterward (the uefi order gets lost anyway, but that's minor in comparison). Do you know how to create persistent UEFI entries with grub-install? How does Fedora achieve it? My workaround so far has been to install Fedora in order to let it create a uefi entry and then wipe the drive, install my favorite distro and grub-install into its path (fedora/grubx64.efi) to take advantage of the existing persistent uefi entry. Any idea how to achieve persistent uefi entries with grub-install instead?

gohrner commented 1 year ago

Did you try to select the boot options with efibootmgr and adjust the boot order with it?

hlein commented 1 year ago

I've been fighting what seems like this exact problem, Gigabyte X670E Aorus Master motherboard, Samsung 990 PRO NVMes. Update I think it's solved now; see below.

Installing sedutils' pbaimage, unlocking the drive, booting to an install USB, installing on the drive, installing grub and pointing to it with grub-install or manually running efibootmgr, all looks good. I end up with a boot entry like:

Boot0000* gentoo HD(2,GPT,48e38676-718c-4fee-81c2-bce560dac3a2,0x64800,0x64000)/File(\EFI\gentoo\grubx64.efi)

Rebooting w/o power cycle, fine.

Upon power cycle, get prompted for the passphrase to unlock the drives; they are successfully unlocked, and then the box reboots...

...to the UEFI BIOS. Because the Boot0000 entry has vanished and there's no bootable device.

Again I can boot off alternate/installer media and poke an entry back in with efibootmgr and it persists & works fine to boot the box until the next power cycle, when it'll disappear again.

To @gohrner 's question, before the cold-boot I could adjust the order, sure. But after power cycle, the entries are gone, there's no order to adjust.

@darkbasic did you ever get to the bottom of how Fedora's entries persist? Can you share the output of efibootmgr or maybe efibootmgr -v?

I wonder if we can figure out what's different about their entries. I notice besides BootXXXX there's also SysprepXXXX, which I found hard to Google because of Microsoft's Sysprep, but apparently for new enough EFI it should be possible to use those for boot entries too?

Another thing that has occurred to me is modifying pbaimage to run the necessary efibootmgr command to re-add the needed entry after unlocking the disks. That sounds like a horrible hack, and I wonder what exactly it's writing to, does that have the necessary wear resilience to be written to on every power up? Etc.

Edit: It isn't science if you don't write it down, so:

-y (Sysprep) - no apparent effect (might be motherboard/BIOS specific?)
--full-dev-path - successful soft reboot, but does not persist across power cycles
--file-dev-path - can't boot at all
setting pmbr_boot on disk label (the opposite of [https://askubuntu.com/a/1302710]) - no help
Contact the motherboard vendor - no response no matter how many times I reload the ticket, tho I only created it 1.5 hours ago...

Update: I think I've got it. Arch wiki to the rescue, specifically https://wiki.archlinux.org/title/GRUB#Default/fallback_boot_path

grub-install ... --removable will create a stub .EFI file and efiboot entry at a default search-path for UEFI firmware. (I think in this context, "hey when you power up, the partitions under /dev/nvme0n1* do not exist" counts as "removable"). Even though the custom entry can't survive, that stub persists:

# efibootmgr 
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002,0003
Boot0001* UEFI OS       HD(2,GPT,48e38676-718c-4fee-81c2-bce560dac3a2,0x64800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0002* UEFI OS       HD(2,GPT,931561f7-8e33-4494-8193-b2d703ff2c5c,0x64800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0003* UEFI OS       HD(2,GPT,8f39b8ec-9398-4ebf-9249-c3c455ff0417,0x64800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f

# find /boot/efi -ls
        1      1 drwxr-xr-x   3 root     root          512 Dec 31  1969 /boot/efi
        4      1 drwxr-xr-x   4 root     root          512 May 23 23:01 /boot/efi/EFI
        7      1 drwxr-xr-x   2 root     root          512 May 15 20:28 /boot/efi/EFI/gentoo
        9    156 -rwxr-xr-x   1 root     root       159744 May 23 23:02 /boot/efi/EFI/gentoo/grubx64.efi
       10      1 drwxr-xr-x   2 root     root          512 May 23 23:01 /boot/efi/EFI/BOOT
       12    156 -rwxr-xr-x   1 root     root       159744 May 23 23:03 /boot/efi/EFI/BOOT/BOOTX64.EFI

@darkbasic I'd still like to see/confirm if your working setup is similar to the above; I bet it is.

darkbasic commented 1 year ago

did you ever get to the bottom of how Fedora's entries persist?

Nope, just kept using the Fedora boot entry.

Can you share the output of efibootmgr or maybe efibootmgr -v?

Boot0002* Fedora        HD(2,GPT,36e21d27-838c-4c6f-81e0-716189a98b8c,0xfa000,0x31800)/File(\EFI\FEDORA\SHIM.EFI)0000424f
      dp: 04 01 2a 00 02 00 00 00 00 a0 0f 00 00 00 00 00 00 18 03 00 00 00 00 00 27 1d e2 36 8c 83 6f 4c 81 e0 71 61 89 a9 8b 8c 02 02 / 04 04 2e 00 5c 00 45 00 46 00 49 00 5c 00 46 00 45 00 44 00 4f 00 52 00 41 00 5c 00 53 00 48 00 49 00 4d 00 2e 00 45 00 46 00 49 00 00 00 / 7f f>
    data: 00 00 42 4f

I'd still like to see/confirm if your working setup is similar to the above; I bet it is.

I'll give it a try.

hlein commented 1 year ago

Boot0002* Fedora HD(2,GPT,36e21d27-838c-4c6f-81e0-716189a98b8c,0xfa000,0x31800)/File(\EFI\FEDORA\SHIM.EFI)

Interesting, I was sort of expecting to see some generic-looking path entries like I ended up with, but it doesn't look like that happened.

Maybe someone who knows what they are looking at can decode the dp: and data: blocks; perhaps one of those is a flag that says "this is removable, don't discard the entry if the device goes away".

I still sort of wonder if it put down a default BOOTX64.EFI or similar and your EFI BIOS is autodiscovering that, which is what I thought was happening for me. What does your EFI directory heirarchy, like find /boot/efi -ls, look like?

Drive-Trust-Alliance / sedutil

Persisting UEFI entries #409