Description of problem: efibootmgr cannot change anything Version-Release number of selected component (if applicable): 0.5.4 How reproducible: Here a simple example how it behaves. Let's say I simply want to change the boot order: efibootmgr -v [root@localhost ~]# efibootmgr -v BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0000,0001 Boot0000* Fedora HD(1,800,64000,6addb80a-cc80-4086-842b-9c915e3f9493)File(\EFI\fedora\shim.efi) Boot0001 UEFI OS HD(1,800,64000,6addb80a-cc80-4086-842b-9c915e3f9493)File(\EFI\BOOT\BOOTX64.EFI) efibootmgr -o 1,0 [root@localhost ~]# efibootmgr -v BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0000,0001 Boot0000* Fedora HD(1,800,64000,6addb80a-cc80-4086-842b-9c915e3f9493)File(\EFI\fedora\shim.efi) Boot0001 UEFI OS HD(1,800,64000,6addb80a-cc80-4086-842b-9c915e3f9493)File(\EFI\BOOT\BOOTX64.EFI) tail /var/log/messages Mar 15 23:12:26 localhost kernel: [ 266.611373] efivars: set_variable() failed: status=8000000000000009 Steps to Reproduce: 1. 2. 3. Actual results: Expected results: BootOrder: 0001,0000 Additional info: Motherboard: ASUS P8B75-MLE
set_variable() failed status means EFI_OUT_OF_RESOURCES. That is the UEFI implementation on that platform reporting it's out of space. I don't know what else you have taking up space in the variable store (look in /sys/firmware/efi/vars/) but as efibootmgr simply asks the kernel to write, and the kernel calls the set_variable(), which calls UEFI, and that's what UEFI returns, not much efibootmgr can do about it.
It is not really clear to me what you mean. What I can give you is a list of what I find in /sys/firmware/efi/vars.
Created attachment 713420 [details] /sys/firmwar/efi/vars directory listing
I am seeing the same problem with efibootmgr-0.5.4-14.fc18.x86_64 on Asus M5A97 R2.0. efibootmgr can display the status but it cannot change anything. This is a regression, it worked shortly after Fedora 18 release. Unfortunately I went a long time between updates and I cannot tell what broke it. Also, I cannot exclude the possibility that it was actually the BIOS update that broke it at some point. I will try to revert to older BIOS when the system is less busy. However, the original poster is using a different motherboard so this is a long shot (though it is the same brand...).
Upgrading BIOS on Asus M5A97 R2.0 to version 1602 fixed the problem.
Same with me. Update from 0904 to 1101 fixed it.
Apart from BIOS upgrades (and kernel downgrades) something needs to be fixed in efibootmgr related to error handling. Apparently efibootmgr runs into a ENOSPC, but no feedback is given to the user: [root@home01 ~]# efibootmgr -c -w -L Fedora3 -d /dev/sda -p 1 -l '\EFI\fedora\shim.efi' -b 3 [root@home01 ~]# Now let's see what strace tells us: [root@home01 ~]# strace efibootmgr -c -w -L Fedora3 -d /dev/sda -p 1 -l '\EFI\fedora\shim.efi' -b 3 execve("/sbin/efibootmgr", ["efibootmgr", "-c", "-w", "-L", "Fedora3", "-d", "/dev/sda", "-p", "1", "-l", "\\EFI\\fedora\\shim.efi", "-b", "3"], [/* 31 vars */]) = 0 brk(0) = 0x25c3000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fee07dc7000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) ... close(3) = 0 open("/sys/firmware/efi/vars/new_var", O_WRONLY) = 3 write(3, "B\0o\0o\0t\0000\0000\0000\0003\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2084) = -1 ENOSPC (No space left on device) close(3) = 0 exit_group(1) = ? +++ exited with 1 +++ The kernel clearly returns a ENOSPC. From the users perspecive it seams though that everything went fine.
The ENOSPC error may be related to bug 947142
Created attachment 732073 [details] 0001-handle-ENOSPC-as-EFI_OUT_OF_RESOURCES-when-writing This should catch the -ENOSPC return.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The issue is fixed in Fedora 20. I can change the boot order here using efibootmgr.
It looks like Matt's proposed patch from c#9 never got merged anywhere, so I've filed https://github.com/vathpela/efivar/issues/3 just so the idea doesn't get lost in the Fedora EOL process or anything.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.