Hi,

I observe the very same issue on a Dell Latitude 3590, but it only started to 
affect the laptop running Bullseye all of a sudden after one of many 
reinstallations.
19 other laptops (same model, same date of purchase, same hardware) with 
exactly the same installation (preseed + configuration management via Puppet) 
are (as of yet) unaffected.

I believe the described issue matches this one observed on various Dell laptops:
 https://github.com/rhboot/efibootmgr/issues/86

To be more explicit, using:
 efibootmgr -c -e 3 -v -L debian -l "\EFI\debian\shimx64.efi"
creates a working boot entry, using an EDD 3.0 path similar to the one created if an 
entry is created via the UEFI firmware "by hand".

Using:
 efibootmgr -c -v -L debian -l "\EFI\debian\shimx64.efi"
creates a boot entry invisible in the UEFI firmware.

This matches the observation of Gábor Gombás ("Debian" in the "efibootmgr -v" output for 
an EDD 3.0 entry vs. "debian", an EDD 1.0 entry).

As of the fix for #891434 , grub-install does not leverage efibootmgr anymore, 
but implements part of its functionality to reduce writes (and always seems to 
use EDD 1.0).

From my observation and the one in the linked GitHub issue, I deduce the 
following:

- There's actually a firmware bug on these Dell laptops (and maybe more 
devices), causing the UEFI firmware to start ignoring EDD 1.0 entries after 
some event (a number of write cycles? some corruption?).
- EDD 3.0 entries still work.
- Since grub-install always uses EDD 1.0 entries, it overwrites the entry with 
an EDD 1.0 entry during each reinstall, causing such devices not to be bootable 
anymore.

Workarounds appear to be:
- Create an EDD 3.0 entry (either via firmware, or via efibootmgr), name it 
differently and inject it first in the boot order.
- Use --force-extra-removable to install to the fallback loader path (if this 
is the only bootloader on the system).

Notably, the workaround described by ArchLinux at:
 
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Boot_entries_created_with_efibootmgr_fail_to_show_up_in_UEFI
does not work on Debian, since efibootmgr is not called by grub-install.

While the GitHub issue describes a user who could make EDD 1.0 entries work 
again on an affected system by purging all entries, in my tests neither that 
nor an UEFI update nor loading of firmware defaults nor a full RTC reset could 
make the firmware accept EDD 1.0 entries again on the affected device.

A potential solution could be to probe whether the firmware accepts EDD 3.0 
entries and preferrably create those over EDD 1.0, or allow to configure this.

Cheers and hope this helps,
        Oliver

Reply via email to