Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1
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
Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1
Control: found -1 2.04-19 Hi, On Wed, 21 Jul 2021 10:41:57 +0200 =?utf-8?b?R8OhYm9yIEdvbWLDoXM=?= wrote: > 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. 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 OpenPGP_signature Description: OpenPGP digital signature
Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1
Package: grub2-common
Version: 2.04-20
Followup-For: Bug #913916
X-Debbugs-Cc: gomb...@digikabel.hu
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
Boot Windows Boot Manager
HD(1,GPT,----,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 DriveBBS(Floppy,Diskette Drive,0x0)..BO
Boot0002* Internal HDD BBS(HD,P2: TOSHIBA X M.2 ,0x0)..BO
Boot0003* debian
HD(1,GPT,----,0x800,0x10)/File(\EFI\debian\shimx64.efi)
Boot0004 CD/DVD/CD-RW DriveBBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot0005* Linux Firmware Updater
HD(1,GPT,----,0x800,0x10)/File(\EFI\debian\fwupdx64.efi)
Boot0006* Debian
PciRoot(0x0)/Pci(0x17,0x0)/Sata(2,65535,0)/HD(1,GPT,----,0x800,0x10)/File(\EFI\debian\shimx64.efi)
Boot0007* Onboard NIC BBS(Network,Onboard NIC,0x0)..BO
Boot0008* USB Storage DeviceBBS(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
-- Package-specific info:
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod lvm
insmod btrfs
set root='lvmid/REDACTED'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='lvmid/REDACTED' REDACTED
else
search --no-floppy --fs-uuid --set=root REDACTED
fi
font="/@/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=1920x1080x32,auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod lvm
insmod btrfs
set root='lvmid/REDACTED'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='lvmid/REDACTED' REDACTED
else
search --no-floppy --fs-uuid --set=root REDACTED
fi
insmod png
if background_image
/@/usr/share/desktop-base/homeworld-theme/grub/grub-16x9.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=keep
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1
Package: grub-efi-amd64 Version: 2.02~beta3-5+deb9u1 Severity: critical 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
