Also seeing this on aarch64 uefi installs. Ignoring the error and finishing the install the system boots successfully.

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.

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.

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

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

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.

Fedora-Everything-netinst-x86_64-25-20160809.n.0.iso
installs to efi usb hd and boots on yoga pro 2

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

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

I guess bug 1364823 is related.

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.

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.

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.

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.

The updated packages *do* fix the bug, in my testing. One of my test repos:

https://www.happyassassin.net/temp/repo/x86_64/

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.

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).

Adam, that makes perfect sense. Also explains why efibootmgr still dumps core in my booted system. I'll keep an eye out for updates.

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.

CCing.

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

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.

Also, I think the update is missing fwupdate and fwupd.

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).

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

https://bodhi.fedoraproject.org/updates/FEDORA-2016-5ff724b2e5 now has fwupdate and fwupd. I tested using my side repo:

https://www.happyassassin.net/temp/repo/x86_64/

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.

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.