Ubuntu: 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.


Solution: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.


Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »