efibootmgr settings not surviving a reboot

rkelsen · 07-31-2015, 06:41 AM

Just got a new work laptop. Acer Aspire E15. I've turned off secure boot and have managed to add an elilo entry to the boot menu using the settings within the UEFI.

One very frustrating thing about this laptop is that it will not boot from USB or CD, no matter what boot order is set.

Another frustrating thing is that any changes made using efibootmgr do not survive a reboot.

Has anyone else seen this? Can it be fixed?

rkelsen · 07-31-2015, 08:36 AM

Well, I figured out a solution to problem #1... The drive you want to boot off has to have an EFI system partition. I made one on my usb stick and now it automatically appears in the boot menu.

malekmustaq · 07-31-2015, 09:12 AM

Quote:

Another frustrating thing is that any changes made using efibootmgr do not survive a reboot.

Try create from the first block of the booted disk an EFI Partition. Usually about 200Mb in size formatted to FAT16 or FAT32. Actually it only house some volume records needed when the bootloader points to the disk.

Hope that helps.

Didier Spaier · 07-31-2015, 10:46 AM

Compliant UEFI firmware should find and allow you to boot an EFI image on a removable media, but only if located in a an EFI System Partition on that media.

Such a partition including an EFI image is provided a Slackware64-14.1 ISO but not in a Slackware-14.1 ISO.

So, did you try to boot a 64-bit or a 32-bit ISO?

Head_on_a_Stick · 07-31-2015, 02:21 PM

The firmware (BIOS) scans for an EF00 GUID partition code and will create a new NVRAM entry for each device that contains such a partition.

Didier Spaier · 07-31-2015, 02:42 PM

Quote:

Originally Posted by Head_on_a_Stick

The firmware (BIOS) scans for an EF00 GUID partition code and will create a new NVRAM entry for each device that contains such a partition.

In this case the firmware is UEFI not BIOS. And the spec actually says about removable devices:

Quote:

If FilePathList[0] points to a device that supports the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, then the system firmware will attempt to boot from a removable media FilePathList[0] by adding a default file name in the form \EFI\BOOT\BOOT{machine type short-name}.EFI. Where machine type short-name defines a PE32+ image format architecture.

It is nowhere specified AFAIK that the firmware should create NVRAM entries, just where it should look for images in the PE32+ format that could be used to boot an OS, and the format of the NVRAM variables

It is up to the firmware designer to decide how the user can interact with it to create entries in its boot menu, that can also be done by software like efibotmgr.

Also, do not forget that not all firmwares (if any) are fully compliant with some version of the specification, and generally the target version is not even known of the user

rkelsen · 07-31-2015, 05:22 PM

Quote:

Originally Posted by malekmustaq

Quote:

Another frustrating thing is that any changes made using efibootmgr do not survive a reboot.

Try create from the first block of the booted disk an EFI Partition. Usually about 200Mb in size formatted to FAT16 or FAT32. Actually it only house some volume records needed when the bootloader points to the disk.

Hope that helps.

Thanks for your reply. As I mentioned in post #2, I figured out how to boot from USB.

Perhaps I should mention that this machine came pre-installed with W8, which I need for work (the industry-specific software I use for work only runs on Windows), so it already has an EFI system partition on the hard drive.

I've installed Slackware and been able to add it to the boot menu using some trickery in the UEFI. Basically, I had to re-enable secure boot, then add elilo as a "trusted" efi file. Then I disabled secure boot again, and elilo appeared in the boot menu.

The big problem I've found is that boot entries which are added with efibootmgr do not survive a reboot. Changes made to the boot order with efibootmgr do not survive a reboot either. How can I fix this?

rkelsen · 07-31-2015, 05:26 PM

Quote:

Originally Posted by Didier Spaier

Also, do not forget that not all firmwares (if any) are fully compliant with some version of the specification, and generally the target version is not even known of the user

That's the scary part. I read last night that as of W10, Microsoft is no longer requiring that users have the ability to turn off secure boot.

Didier Spaier · 08-01-2015, 01:11 AM

Quote:

Originally Posted by rkelsen

The big problem I've found is that boot entries which are added with efibootmgr do not survive a reboot. Changes made to the boot order with efibootmgr do not survive a reboot either. How can I fix this?

If you use the -n option in the efibootmgr command you specify that the boot entry given as argument be taken, but only on next boot. Is that what you mean by Changes made to the boot order with efibootmgr do not survive a reboot?

Anyhow posting the full command you used could help to investigate, and would allow to try to reproduce this behavior.

rkelsen · 08-01-2015, 02:53 AM

Quote:

Originally Posted by Didier Spaier

If you use the -n option in the efibootmgr command you specify that the boot entry given as argument be taken, but only on next boot. Is that what you mean by Changes made to the boot order with efibootmgr do not survive a reboot?

No. I mean that any settings changed with efibootmgr do not persist. I'm not using the -n switch.

Current settings:

# efibootmgr
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0000,0001,2001,2002,2003
Boot0000* Windows Boot Manager
Boot0001* slackware
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network

To change the boot order:

# efibootmgr -o 1,0
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,0000,2001,2002,2003
Boot0000* Windows Boot Manager
Boot0001* slackware
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network

So far, so good... until I reboot and find myself in Windows...

rkelsen · 08-01-2015, 02:59 AM

What is the concensus on replacing EFI/Boot/bootx64.efi with something like rEFInd?

http://www.rodsbooks.com/refind/

I used it on my old laptop to dual boot with W7, without needing to replace the existing EFI/Boot/bootx64.efi file.

The boot loader for W8 seems to be less tolerant of competition...

Didier Spaier · 08-01-2015, 04:06 AM

Having seen this I would try:

Code:

efibootmgr -O -o 0001,0000

could be a bug in efibootmgr itself or in efivars.

Or, you could try to upgrade.

efibootmgr is no more maintained by Dell, but see for instance the version provided in the rhinstaller:
https://github.com/rhinstaller/efibootmgr/releases
It seems that Arch packages this one:
https://github.com/vathpela/efibootmgr-devel
that seems to be roughly the same.

I would try to avoid using rEFInd. It probably works but adding a layer of complexity hurts my sense of aesthetic

rkelsen · 08-01-2015, 05:12 AM

Quote:

Originally Posted by Didier Spaier

Having seen this I would try:

Code:

efibootmgr -O -o 0001,0000

could be a bug in efibootmgr itself or in efivars.

I did a little experiment, changing the boot order within the UEFI, and it worked.

So, using the same trick I used to add elilo, I added rEFInd (in it's own subdir, not touching anything else) and then put it first in the boot order... and now that's the end of my booting troubles on this laptop. rEFInd can boot it from CD, USB or any ".efi" file on the EFI partition.

I'm not sure why efibootmgr doesn't work properly on this one, but thanks for all of your help.