efi boot order changes on package upgrade

Question

Every now and then after I upgrade my system the efi boot order is changed and the system won't boot. I have to go to the bios and reselect the ubuntu efi entry. I am guessing it is one of those packages (at least it always happens when I see one of those being upgraded):

grub-common grub-efi grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-
signed grub2-common shim shim-signed

When I run efibootmgr I get this:

efibootmgr
No BootOrder is set; firmware will attempt recovery

I ran:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

I am unable to find any answers to efibootgmr not running. Please help. Thanks!

Update:

I tried adding an EFI boot variable with:

efibootmgr --create --disk /dev/sda --part 1 --label "Ubuntu" --loader
\\EFI\\ubuntu\\grubx64.efi

Which returns:

BootOrder: 0000
Boot0000* Ubuntu

On restart the system won't boot.

Boot Menu

Now the working entry is labeled Ubuntu. When I select it Ubuntu boots. After running efibootmgr again I get the same result as before:

efibootmgr
No BootOrder is set; firmware will attempt recover

In case it is relevant shim and shim-signed were also updated when the boot order was changed by the update.

Update:

The computer is a Gigabyte Brix GB-BXBT-1900 with the newest bios revision.

I think my initial question was why efigootmgr is not working and that has been answered. Thank you for your input.

Answer 1

You're running into what I call a "boot coup." I've written a page on this subject; see here for details. That said, your problem sounds a bit unusual, but it is likely related to this:

efibootmgr
No BootOrder is set; firmware will attempt recovery

Ordinarily, an EFI-based computer does have a BootOrder variable set. The cases I personally have seen where it's not set have been because of a defective firmware that simply refuses to accept this variable. On such computers, the only chance of booting is via a fallback filename (typically EFI/BOOT/bootx64.efi on the ESP, although EFI/Microsoft/Boot/bootmgfw.efi will sometimes work, too). That said, I have heard of cases where the BootOrder variable is empty but can be set. In this case, adding an EFI boot variable, as described here, can fix the problem.

If your computer is just badly defective and needs to boot through a fallback filename, you must copy or move/rename the boot loader to the appropriate name, and possibly support files like configuration files.

Given that you referred to "the ubuntu efi entry" makes me think that you've got boot variables, but the BootOrder variable is getting lost. This is probably a firmware bug, although it could indicate defective NVRAM hardware. Upgrading the firmware might fix the problem, if it's a bug. Check with the manufacturer to see if such an upgrade exists. If that doesn't help, you might copy GRUB to the fallback filename, where it should be called if/when the BootOrder variable is lost again. The ESP is normally mounted at /boot/efi, and normal Linux filesystem commands work on it, so you can do this:

sudo cp -r /boot/efi/EFI/ubuntu /boot/efi/EFI/BOOT
sudo mv /boot/efi/EFI/BOOT/shimx64.efi /boot/efi/EFI/BOOT/bootx64.efi

This copies Shim to the fallback filename. If you're certain that your computer doesn't use Secure Boot, you could rename grubx64.efi, rather than shimx64.efi, to bootx64.efi.