After updating grub2 in Debian stable to 2.02~beta3-5+deb9u1 the UEFI boot option was removed on my Dell Latitude 5480. After rebooting I was greeted with "No bootable devices found". In the setup utility (reached by pressing F2) the UEFI boot sequence was empty. I could fix the problem by adding a new boot option, selecting the file EFI/debian/grubx64.efi.

I could reproduce this by downgrading the installed grub2 packages (grub2-common, grub-common, grub-efi-amd64, grub-efi-amd64-bin) to 2.02~beta3-5, making sure the boot option is there, and updating the packages to 2.02~beta3-5+deb9u1 again. After the update the boot option is gone. Just rebooting with either of the versions does not remove the boot option.

There is no indication during the update that something went wrong:

Setting up grub-efi-amd64 (2.02~beta3-5+deb9u1) ...

Installing for x86_64-efi platform.

Installation finished. No error reported.

Generating grub configuration file ...

Found background image: .background_cache.png

Found linux image: /boot/vmlinuz-4.9.0-8-amd64

Found initrd image: /boot/initrd.img-4.9.0-8-amd64

Found linux image: /boot/vmlinuz-4.9.0-7-amd64

Found initrd image: /boot/initrd.img-4.9.0-7-amd64

Adding boot menu entry for EFI firmware configuration

done

Best,
Tobias

I have this bug pinned via /etc/apt/preferences.d/apt-listbugs ever
since. So I cannot upgrade this package.

The bug description reads as if I better do not dare to update, no? Any
news? was this a single occurrence only?

Thanks a million, I much much appreciate Debian, and everyone who helps!

Hi,

I can confirm the bug still exists, running grub-install makes my laptop
(Dell Latitude E7470) unbootable by removing all (well, the only) boot
options, and I have to enter the firmware menu to set up the boot
options again.

It took more than a year to figure out it was due to grub-install,
because the bug usually manifested itself after installing a large
number of packages, and I was lazy to figure out which exactly was the
trigger. But yesterday, the only relevant packages which I have updated
were shim-helpers-amd64-signed and grub-efi-amd64-signed, and only
shim-helpers-amd64-signed had a postinst script, and the only thing that
postinst script did was running grub-install.

Here's the output of "efibootmgr -v", if it helps:

# efibootmgr -v
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0001,0004,0002,0007,0008,0006
Boot0000  Windows Boot Manager	HD(1,GPT,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.x.x.x.x.x.x.x.x.-.x.x.x.x.-.x.x.x.x.-.x.x.x.x.-.x.x.x.x.x.x.x.x.x.x.x.x.}...3................
Boot0001  Diskette Drive	BBS(Floppy,Diskette Drive,0x0)..BO
Boot0002* Internal HDD	BBS(HD,P2: TOSHIBA XXXXXXXXXXXXX M.2 ,0x0)..BO
Boot0003* debian	HD(1,GPT,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
Boot0004  CD/DVD/CD-RW Drive	BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot0005* Linux Firmware Updater	HD(1,GPT,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,0x800,0x100000)/File(\EFI\debian\fwupdx64.efi)
Boot0006* Debian	PciRoot(0x0)/Pci(0x17,0x0)/Sata(2,65535,0)/HD(1,GPT,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
Boot0007* Onboard NIC	BBS(Network,Onboard NIC,0x0)..BO
Boot0008* USB Storage Device	BBS(USB,USB Storage Device,0x0)..BO

The "Debian" entry (with capital 'D') is the one I've set up through the
firware menu. The "debian" entry with lower case "d" is I guess the one
which was originally created by Debian Installer, and it is suspiciously
missing from BootOrder.

Regards,
Gabor

Hi,

As this report claims the bug exists for more than a year it's not new
in 2.04-20. I add the version 2.04-19 to the list of found versions to
unblock 2.04-20 from migrating.

Paul

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