efibootmgr can't change boot order

fernando_costa · 2014-09-14 04:30:02

So, I had my Arch already working, dual booting with Windows through rEFInd... I have a Lenovo Yoga 2 Pro, and I heard there was a new BIOS version... As my laptop has some hardware issues (which are subject for another thread) I decided to install the new BIOS version. Ever since, I can not boot rEFInd, which is still installed on EFI.

When I boot an Arch installation ISO and run:

# efibootmgr -v -o 0002,0001,2001,2002 && echo "OK"

It doesn't return anything.

First, is there a log somewhere I could use to troubleshoot efibootmgr?

Is there a way to work around that issue by substituting Windows Boot Manager by rEFInd?

I wasn't sure which forum I should post this issue, I decided not to put it on Laptop Issues because this could happen to other laptops and the solution might be of wider interest.

Thanks

bstaletic · 2014-09-14 09:35:30

Are you unable to boot at all, or just can't get to rEFInd and get thrown to Windows' bootloader?

If you get to windows' bootloader reinstalling rEFInd will probably fix everything.
If you're not booting at all reinstalling rEFInd may fix this problem too, if it doesn't it may be easiest to reinstall both systems.

fernando_costa · 2014-09-14 18:17:01

I'm thrown to Windows' bootloader.

Reinstalling rEFInd doesn't solve anything, it fails with a message such as:

ALERT: There were problems running the efibootmgr program! You may need to
rename the refind_x64.efi binary to the default name (EFI/boot/bootx64.efi
on x86-64 systems or EFI/boot/bootia32.efi on x86 systems) to have it run!

That error does not surprise me because when I manually try to change the boot order efibootmgr fails without saying anything (as I've shown in my first post).

Reinstalling both systems would be too sad, to say the least. And there's a chance it won't solve the problem, cause my BIOS might be sabotaging other EFI entries, or simply not allowing efibootmgr changing the order of boot.

Regards,

bstaletic · 2014-09-14 18:35:59

Check secure boot option in BIOS. If it is enabled it myght be the causeof the problem. You can try installing some other EFI bootmanager,but I dought it will solve anything.
Other than that I have no ideas left.

fernando_costa · 2014-09-14 20:12:56

Thanks, bstaletic, I already have secure boot disable, so think I have no choice but keep looking for a solution.

teateawhy · 2014-09-14 20:53:30

Copy refind to the default location, as the ALERT told you to do, (you can do this from windows), then select the harddrive where arch is installed from the UEFI menu. Do not select the refind boot entry, but the entry for the harddrive, and see what happens.

fernando_costa · 2014-09-16 06:25:07

@teateawhy, I have no such directory that the alert presented. The one similar to it has no practical function, as I had already changed the bootx64.efi on it much longer.

What I did was findind and substituting Windows' efi and, it worked... sort of... A lot of entries are shown in my rEFInd menu, entries that I was not expecting and that made me realize that I'm not completelly sure of how rEFInd create the entries (I'll read more about it).

Afterwards, I finally was able to change the boot order through efibootmgr... And I have absolutely no idea why! Beacause I did the same thing I was trying to make before and now I still can't change it! At least now the boot order is correct.

boxofrox · 2014-10-19 12:25:08

I have the same problem. Something appears to have changed with efibootmgr because

sudo efibootmgr -o 0000

is a no-op on my system. This command neither creates a boot order entry nor alters an existing boot order entry. This used to work for me in the past, but now I'm forced to use the bios boot menu to select my linux os over my efi utils.

I have an Asus Zenbook UX32-VD with UEFI. There is no secure boot option afaik. I think my laptop predates secure boot.

\hbar · 2014-10-19 13:02:40

I had the same problem (on a macbook pro and macmini) ever since the update to efivar 0.11 and efibootmgr 0.8 . Since then, newer versions of efivar (0.15) and efibootmgr (0.9) have been released, and in fact, if I replace both efivar and efibootmgr by the development versions efivar-git and efibootmgr-git from the aur, the problem gets solved. It would be interesting to check whether installing the newer releases also solves the problem.

Last edited by \hbar (2014-10-19 13:03:04)

Painless · 2014-10-20 10:08:48

I had a similar problem:

efibootmgr -o XXXX YYYY (etc)

would not change an existing boot order on a Dell Inspiron 3531. I had to use:

efibootmgr -O

to delete the existing boot order before I could set a new boot order. YMMV.

Last edited by Painless (2014-10-20 10:10:09)

Blasphemist · 2014-10-22 20:43:42

efibootmgr has some defaults that can cause this since it doesn't report issues to you when they happen. Try using some switches added to what you used to overcome this. I use -p to tell efibootmgr my ESP is on partition 2, not sda1 as is the default but sda2. Other switches I've used to overcome defaults include -l to specify the loader name since elilo is the default, -L to set the label for the entry since Linux is the default. I'd verify that your desired entry does exist and that all you need to do is change the order first. Ensure you do use efibootmgr as root, su or sudo. Include the partition switch if your ESP is not sda1 and use the -d option if sda is not the right disk. Make the change and verify it using efibootmgr, you shouldn't need to reboot to check it. If somehow it doesn't work, try making some other change like deleting any un-needed entry.

atrigent · 2014-10-24 02:07:12

This issue is rather problematic, since it also affects the copy of efibootmgr that ships with the install ISO. A few days ago I was having loads of fun figuring out why I couldn't configure my laptop to boot Arch. I had tried setting the boot order with efibootmgr and noticed that it wasn't working, but it wasn't immediately obvious to me that this was as much of a show-stopper as it turned out to be. It looks like my laptop's firmware (Thinkpad T440p) as well as the EFI shell are completely unable to see boot entries unless they are referenced somewhere in BootOrder, so being able to set BootOrder with some other tool was essential. The workaround that I used is similar to the one suggested by Painless, except that it can be shortened to one command like so:

efibootmgr -O -o XXXX,YYYY,ZZZZ

It looks to me like the bug is actually in efivar. The code for setting a variable in efivar is supposed to delete the variable if it already exists and then create it anew. This bug was introduced in this: https://github.com/vathpela/efivar/comm … 043880fdfa commit, because it added the explicit requirement that the attempt to create the variable anew actually does so (the O_EXCL flag). Unfortunately the code which deleted already existing variables was broken, so the creation attempt did not actually result in a creation attempt, causing the set to fail. This is why first deleting the existing BootOrder is an effective workaround. The deletion was fixed with this: https://github.com/vathpela/efivar/comm … 3f7ce29d9d commit, which is included with the 0.12 release of efivar. A further issue, this time in efibootmgr itself, is that errors were not being reported correctly. This appears to have been fixed in https://github.com/vathpela/efibootmgr/ … 8425f27f79, which is included with the 0.10 release of efibootmgr. All of this was also preventing efibootmgr from correctly appending new boot entries to BootOrder, which it is supposed to do automatically when they are created.

As \hbar mentioned, and I mentioned above, there are new releases of efivar and efibootmgr which fix these issues. These packages have been marked out of date in the package database, but have not been updated yet. I think it is very important that they be updated before next month's install ISO is rolled, so that people in the future can avoid the confusion that I had to go through.

Last edited by atrigent (2014-10-24 15:08:05)

Blasphemist · 2014-10-24 19:13:20

atrigent wrote:

This issue is rather problematic, since it also affects the copy of efibootmgr that ships with the install ISO. A few days ago I was having loads of fun figuring out why I couldn't configure my laptop to boot Arch. I had tried setting the boot order with efibootmgr and noticed that it wasn't working, but it wasn't immediately obvious to me that this was as much of a show-stopper as it turned out to be. It looks like my laptop's firmware (Thinkpad T440p) as well as the EFI shell are completely unable to see boot entries unless they are referenced somewhere in BootOrder, so being able to set BootOrder with some other tool was essential. The workaround that I used is similar to the one suggested by Painless, except that it can be shortened to one command like so:
efibootmgr -O -o XXXX,YYYY,ZZZZ
It looks to me like the bug is actually in efivar. The code for setting a variable in efivar is supposed to delete the variable if it already exists and then create it anew. This bug was introduced in this: https://github.com/vathpela/efivar/comm … 043880fdfa commit, because it added the explicit requirement that the attempt to create the variable anew actually does so (the O_EXCL flag). Unfortunately the code which deleted already existing variables was broken, so the creation attempt did not actually result in a creation attempt, causing the set to fail. This is why first deleting the existing BootOrder is an effective workaround. The deletion was fixed with this: https://github.com/vathpela/efivar/comm … 3f7ce29d9d commit, which is included with the 0.12 release of efivar. A further issue, this time in efibootmgr itself, is that errors were not being reported correctly. This appears to have been fixed in https://github.com/vathpela/efibootmgr/ … 8425f27f79, which is included with the 0.10 release of efibootmgr. All of this was also preventing efibootmgr from correctly appending new boot entries to BootOrder, which it is supposed to do automatically when they are created.
As \hbar mentioned, and I mentioned above, there are new releases of efivar and efibootmgr which fix these issues. These packages have been marked out of date in the package database, but have not been updated yet. I think it is very important that they be updated before next month's install ISO is rolled, so that people in the future can avoid the confusion that I had to go through.

Thanks for helping me understand this. I do see that efivar and efibootmgr have both been updated in github but not in the Arch repos. I too hope that is changed.

boxofrox · 2014-10-31 03:06:23

Thanks Painless and atrigent. Adding the -O flag got me working again.

Arch Linux

#1 2014-09-14 04:30:02

efibootmgr can't change boot order

#2 2014-09-14 09:35:30

Re: efibootmgr can't change boot order

#3 2014-09-14 18:17:01

Re: efibootmgr can't change boot order

#4 2014-09-14 18:35:59

Re: efibootmgr can't change boot order

#5 2014-09-14 20:12:56

Re: efibootmgr can't change boot order

#6 2014-09-14 20:53:30

Re: efibootmgr can't change boot order

#7 2014-09-16 06:25:07

Re: efibootmgr can't change boot order

#8 2014-10-19 12:25:08

Re: efibootmgr can't change boot order

#9 2014-10-19 13:02:40

Re: efibootmgr can't change boot order

#10 2014-10-20 10:08:48

Re: efibootmgr can't change boot order

#11 2014-10-22 20:43:42

Re: efibootmgr can't change boot order

#12 2014-10-24 02:07:12

Re: efibootmgr can't change boot order

#13 2014-10-24 19:13:20

Re: efibootmgr can't change boot order

#14 2014-10-31 03:06:23

Re: efibootmgr can't change boot order

Board footer