Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1

[Oliver Freyermuth]

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