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.
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.
Best Answer
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:
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 (typicallyEFI/BOOT/bootx64.efi
on the ESP, althoughEFI/Microsoft/Boot/bootmgfw.efi
will sometimes work, too). That said, I have heard of cases where theBootOrder
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 theBootOrder
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: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 thanshimx64.efi
, tobootx64.efi
.