Dear Maintainer,

In an environment with Secure Boot enabled, running apt full-upgrade and rebooting may result in an inability to boot.
Debian registers both SHIMX64.EFI and GRUBX64.EFI in the EFI boot manager, but this priority may change on its own when apt full-upgrade is performed.
Therefore, even if SHIMX64.EFI is set as the first priority in advance, GRUBX64.EFI may change to the first priority by performing an update.

This problem can be avoided by starting UEFI Setup and manually correcting it when a reboot is performed.
This can be a major hindrance for headless machines that cannot access UEFI Setup remotely.

You filed this bug against the wrong package. grub-install updates EFI
boot variables on its own, it does not use efibootmgr any more.

grub-install registers either grubx64.efi (when installing without shim)
or shimx64.efi (when installing with shim), but not both. Also, it
deletes superfluous EFI boot variables with the same label as the one
being registered ("debian"), so there should not be more than one EFI
boot variable with that label.

Can you post the output of "efibootmgr -v" and "ls -lhR /boot/efi/EFI" ?

(Please reply to the bug mail address, not only mine)
In my experience, such EFI boot entries never have "..BO" appended.
However I have seen this "suffix" in EFI boot entries created by the
UEFI firmware. Example:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033686#10>

I have also seen an Asus laptop UEFI firmware automatically and wrongly
register an EFI boot entry for grubx64.efi.

Running apt (full-)upgrade updates EFI boot entries only on grub or shim
package installation or update, but it looks like this last happened on
october 2024. So if something changed BootOrder since then, it is not apt.

You can run grub-install -v (the last lines show what it does with EFI
boot variables) and efibootmgr -v. It should show only one "debian"
entry pointing to shimx64.efi and first in BootOrder. Then reboot and
run efibootmgr -v again to see if there is any change.

I ran grub-install manually and grubx64.efi disappeared from the boot
entry. I am not sure, but the problem seems to be solved for the time being.

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.

Is it possible to not install grubx64.efi in ESP when using shim?

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.

Is it possible to not install grubx64.efi in ESP when using shim?

No, it's part of the boot process by default:

<firmware> -> <shim> -> <grub> -> <linux>

This is the expected outcome. Does it reappear after a reboot ?

This is what I suspect.

No, because shim chains grubx64.efi from the same directory.
You could try to install GRUB only in the "removable media path"
/EFI/BOOT and not in /EFI/debian.

Hello,

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