Bug#1102182: efibootmgr: If Secure Boot is enabled, the system may not start after rebooting
Hello,
> > Perhaps this /File(\EFI\DEBIAN\GRUBX64.EFI). BO is not installed by
> > Debian, but the firmware of my computer found GRUBX64.EFI in the EFI
> > system partition and added it to the boot entry on its own.
>
> This is what I suspect.
I have an Asus motherboard (PRIME B450M-A) and have the same kind of behavior.
Actually I noticed that all boot entries that end with "..BO" are created by
the motherboard's UEFI. So the "debian" entry which references grubx64.efi is
unfortunately added by it and can lead to confusion because we end up with two
entries labeled "debian":
- the entry created by Debian, without the ..BO suffix, and loading
shimx64.efi
- the other entry created by the motherboard UEFI, having ..BO, and loading
grux64.efi.
If I remove the entry created by the motherboard, it reappears after reboot.
I also noticed some other weirdness on that motherboard. If I have multiple
entries pointing to the same shimx64.efi (same absolute path) but where the
argument differ (and the label as well) [I use the argument to use another 2nd
stage loader than grubx64.efi), the motherboard will just keep the latest and
drop all other pointing to \EFI\debian\shimx64.efi :/ Before reboot, all
entries pointing to \EFI\debian\shimx64.efi are there, after reboot, only one
is remaining.
I filed a but to Asus, but don't have much hope that this will really reach
the developers and go beyond the 1st level support. If you have that too, you
could file a bug as well.
Regards
Reply to: