Bug 1352680 - efibootmgr calls in anaconda crashing since efivar-0.24-1.fc25 landed
Summary: efibootmgr calls in anaconda crashing since efivar-0.24-1.fc25 landed
Alias: None
Product: Fedora
Classification: Fedora
Component: efibootmgr
Version: 25
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F25AlphaBlocker
TreeView+ depends on / blocked
Reported: 2016-07-04 17:20 UTC by Adam Williamson
Modified: 2016-08-19 02:25 UTC (History)
12 users (show)

Fixed In Version: efibootmgr-13-2.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-08-19 02:25:15 UTC
Type: Bug

Attachments (Terms of Use)

Description Adam Williamson 2016-07-04 17:20:51 UTC
All openQA UEFI tests since efivar-0.24-1.fc25 landed in Rawhide have failed, e.g. https://openqa.fedoraproject.org/tests/24608 . program.log shows:

06:34:59,186 INFO program: Running... efibootmgr
06:34:59,610 DEBUG program: Return code: -11
06:34:59,611 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/vda -p 1 -l \EFI\fedora\shim.efi
06:34:59,789 DEBUG program: Return code: -11

per davidshea, a negative 'return code' like that means 'exited with signal', so this means efibootmgr is exiting with signal 11.

Proposing as an Alpha blocker, this violates all 'install must complete' criteria - e.g. "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." - on UEFI, which is a "supported firmware type" per https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria#Release-blocking_images_must_boot .

Comment 1 Paul Whalen 2016-07-12 14:35:55 UTC
Also seeing this on aarch64 uefi installs. Ignoring the error and finishing the install the system boots successfully.

Comment 2 Mario Limonciello 2016-07-12 21:38:42 UTC
efibootmgr in rawhide currently is missing https://github.com/rhinstaller/efibootmgr/commit/d44b6bba411587c77ed25775bc1f9d962550604c

It would be best to get @pjones to issue a new efibootmgr release and update to that to resolve this issue.

Comment 3 Adam Williamson 2016-07-12 21:45:07 UTC
pjones has been on vacation lately, which is why this isn't resolved yet, but he knows about it and will be fixing it when he's back.

Comment 4 Petr Schindler 2016-07-21 09:36:01 UTC
Discussed at 2016-07-20 blocker review meeting: [1]. 

This bug was accepted as Alpha blocker: Failing efibootmgr clearly violates the alpha criterion: "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."  

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-07-20/f25-blocker-review.2016-07-20-16.00.html

Comment 5 Jan Kurik 2016-07-26 04:55:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 6 Adam Williamson 2016-08-03 18:25:03 UTC
Update as of today:

<pjones> gah, that's still a thing
<pjones> I will try to fix it this afternoon or tomorrow.  I *think* it shouldn't be much more work.

Comment 7 satellitgo 2016-08-10 21:50:54 UTC
installs to efi usb hd and boots on yoga pro 2

used  usb written with f24 gnome-disk restore as installer.

first install attempt failed
2nd install attempt (used restore disk function in booted netinstall usb) - install worked.

Comment 8 Aaron Sowry 2016-08-12 02:07:06 UTC
I guess bug 1364823 is related.

Comment 9 Adam Williamson 2016-08-12 02:20:23 UTC
yeah, not sure if it's exactly the same...looking at the backtrace that one looks like it might occur when installing over an existing Fedora UEFI install, since it runs through a function called warn_duplicate_name. But that's just a guess.

Anyhow, there are new efivar and efibootmgr builds for F25 and F26 now, so if you can re-test with those it'd be great - should be possible to test by manually updating them in the live environment prior to running the install.

Comment 10 Adam Williamson 2016-08-12 03:31:18 UTC
So I'm testing the fix for this, but there is a problem: one dependent package - fwupdate - was not ported to the new efivar API and rebuilt. This package is included in the Workstation live, so until it's fixed the Workstation live will not compose (as the current fwupdate package's deps are now broken).

fwupdate does need changes to work with the new efivar, it's not just a case of a straight rebuild, and we're not yet close enough to the go/no-go that it'd be a good idea for me to try and hack this up as a patch tonight...I'll just leave it to pjones for tomorrow.

Comment 11 Adam Williamson 2016-08-12 03:32:12 UTC
sorry, I should say, the *Rawhide* workstation live will not compose, as the new efivar has gone to Rawhide; F25 will just continue as is (with images building but UEFI installs failing) until an update is submitted and pushed.

Comment 12 Aaron Sowry 2016-08-12 04:32:08 UTC
Forcing the update (--nodeps) of efivar, efivar-libs and efibootmgr from koji in the F25 Workstation Live environment at least stopped efibootmgr from dumping core when I run it. That enabled me to see that I did indeed have duplicate boot entries (3 named "Fedora").

Before deleting the dupes though I tried running Anaconda again, which still failed during bootloader installation. I then deleted all boot entries and ran Anaconda again - still failed at the same place. Without closing Anaconda I opened a terminal and ran the failed command manually, which succeeded:

# efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi

After this I told Anaconda to continue with the installation anyway, and I now seem to have a working system.

Not sure if this is relevant but the logs where I copied the failed command from didn't have double-escaping on the shim path, I added that myself.

Comment 13 Adam Williamson 2016-08-12 04:35:29 UTC
The updated packages *do* fix the bug, in my testing. One of my test repos:


currently contains the relevant packages for Rawhide, if anyone else wants to test. When I run a Rawhide install with that repo added, it completes successfully with no efibootmgr errors.

Comment 14 Adam Williamson 2016-08-12 04:37:13 UTC
Aaron: sorry, my bad, I gave you bad information. The efibootmgr run during the installation process uses the efibootmgr from the installed system, not the one from the live environment - so even if you update the version in the live environment it won't fix the installation (the installed system will still have the older efibootmgr, as the installation process basically just dumps the live system image onto the hard disk, it doesn't include post-boot changes to the live environment).

Comment 15 Aaron Sowry 2016-08-12 04:41:19 UTC
Adam, that makes perfect sense. Also explains why efibootmgr still dumps core in my booted system. I'll keep an eye out for updates.

Comment 16 Adam Williamson 2016-08-12 21:58:32 UTC
fwupd also needs rebuilding for the new efivar. fwupd builds against fwupdate, so fwupdate needs to be fixed and built first, then fwupd can be done.

Comment 17 Mairi Dulaney 2016-08-15 18:52:01 UTC

Comment 18 Fedora Update System 2016-08-17 17:33:04 UTC
pesign-0.112-4.fc25 mokutil-0.3.0-3.fc25 efibootmgr-13-2.fc25 efivar-28-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-650675f139

Comment 19 Adam Williamson 2016-08-17 17:47:23 UTC
Thanks! Not to sound too ungrateful, but I notice there's quite a lot of change in these builds, with some new feature work being mixed in with the changes to fix compilation, by the looks of it...ideally, during freeze (especially very late in freeze) we'd rather have the minimal amount of change necessary to fix the actual blocker bug, in future.

Shouldn't be a big problem as the openQA tests should catch any major breakage if there happens to be any, but just a note.

Comment 20 Adam Williamson 2016-08-17 18:06:54 UTC
Also, I think the update is missing fwupdate and fwupd.

Comment 21 Adam Williamson 2016-08-17 18:15:58 UTC
Ah, it looks like they were submitted separately (though fwupd still needs doing):

https://bodhi.fedoraproject.org/updates/FEDORA-2016-5ff724b2e5 has fwupdate
https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f013aee39 has dbxtool

by policy these should have been in the efivar update, not submitted separately, as updates are supposed to be internally consistent (an update that makes a backward-incompatible library change must include rebuilds of all packages depending on that library), so there is no risk of one update being pushed without the other(s) and causing dependency breakage.

Fixing this after the fact is a bit of a pain, though, and as this is a release blocker it's not really difficult to give it a bit of special handling, so I'll just make sure all three updates get pushed together (ideally, please add fwupd to the fwupdate update).

Comment 22 Fedora Update System 2016-08-17 19:52:22 UTC
efibootmgr-13-2.fc25, efivar-28-1.fc25, mokutil-0.3.0-3.fc25, pesign-0.112-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-650675f139

Comment 23 Adam Williamson 2016-08-17 21:23:17 UTC
https://bodhi.fedoraproject.org/updates/FEDORA-2016-5ff724b2e5 now has fwupdate and fwupd. I tested using my side repo:


which now has all three updates in it. A UEFI install with that included as an additional repo succeeds without errors and boots. There also don't seem to be any dependency issues - I can select the Workstation package set without trouble.

Comment 24 Fedora Update System 2016-08-19 02:24:38 UTC
efibootmgr-13-2.fc25, efivar-28-1.fc25, mokutil-0.3.0-3.fc25, pesign-0.112-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.