Created attachment 1042766 [details]
output of journalctl -a

Created attachment 1042767 [details]
anaconda's anaconda.log after the installation

The important part of program.log is this:

15:12:07,032 INFO program: Running... efibootmgr
15:12:07,057 INFO program: BootCurrent: 0012
15:12:07,058 INFO program: Timeout: 2 seconds
15:12:07,058 INFO program: BootOrder: 0011,0012,0004,0005,000E,0003,000D
15:12:07,058 INFO program: Boot0003* UEFI: Built-in EFI Shell
15:12:07,058 INFO program: Boot0004* Hard Drive
15:12:07,058 INFO program: Boot0005* CD/DVD Drive
15:12:07,058 INFO program: Boot000D* UEFI OS
15:12:07,058 INFO program: Boot000E* Unknown Device
15:12:07,059 INFO program: Boot0011* UEFI OS
15:12:07,059 INFO program: Boot0012* UEFI: SanDisk Extreme 0001
15:12:07,059 DEBUG program: Return code: 0
15:12:07,059 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/md/Volume0_0 -p 1 -l \EFI\fedora\shim.efi
15:12:07,091 INFO program: efibootmgr: Could not add entry to BootOrder: No such file or directory
15:12:07,092 DEBUG program: Return code: 6

I have seen exactly the same issue when installing Fedora 22 Workstation netinst on my fresh new ThinkPad T450s. Unfortunately, I lost the logs, but the error was exactly the same and the return code was 6 as well, I remember it. Afterwards, there was no 'Fedora' boot menu item in UEFI, but the system still booted, I assume it was some kind of fallback from the ESP. There was a short flash of some text before the grub menu was displayed. I was quite lucky to capture it with a camera (but really, it is a fraction of a second long, if that's something you control, please make it stay longer), and it read:

System BootOrder not found. Initializing defaults.
Creating boot entry "Boot0014" with label "Fedora" for file "\EFI\fedora\shim.efi"

After booting that system and running efibootmgr -v, I saw _two_ "Fedora" items (exactly the same), probably with IDs 0013 and 0014. I tried to run the efibootmgr command from anaconda logs to create my own "persistent" Fedora entry, and it passed without problems (id 0015). But after reboot, again there was no item in UEFI, and I saw the same fallback message before grub.

During the next boot, I first deleted those two existing Fedora items from UEFI, and only then created a new one. And finally it persisted and I can now boot the system without seeing that fallback message.

I tried to reinstall the system to test whether this is reproducible (and lost all the logs in the process, because I forgot to back them up), and this time I received a different error message during installation - Fedora item was already present, so it did not fail during creating the item, but during deleting the existing item. This is an excerpt from anaconda's program.log:

13:25:48,967 INFO program: Running... efibootmgr
13:25:48,980 INFO program: BootCurrent: 000C
13:25:48,980 INFO program: Timeout: 0 seconds
13:25:48,980 INFO program: BootOrder: 0013,0007,0008,0009,000A,000B,000C,000D,0012
13:25:48,981 INFO program: Boot0000  Setup
13:25:48,981 INFO program: Boot0001  Boot Menu
13:25:48,981 INFO program: Boot0002  Diagnostic Splash Screen
13:25:48,981 INFO program: Boot0003  Lenovo Diagnostics
13:25:48,981 INFO program: Boot0004  Startup Interrupt Menu
13:25:48,981 INFO program: Boot0005  Rescue and Recovery
13:25:48,981 INFO program: Boot0006  MEBx Hot Key
13:25:48,981 INFO program: Boot0007* USB CD
13:25:48,981 INFO program: Boot0008* USB FDD
13:25:48,981 INFO program: Boot0009* ATA HDD0
13:25:48,982 INFO program: Boot000A* ATA HDD1
13:25:48,982 INFO program: Boot000B* ATA HDD2
13:25:48,982 INFO program: Boot000C* USB HDD
13:25:48,982 INFO program: Boot000D* PCI LAN
13:25:48,982 INFO program: Boot000E* IDER BOOT CDROM
13:25:48,982 INFO program: Boot000F* IDER BOOT Floppy
13:25:48,982 INFO program: Boot0010* ATA HDD
13:25:48,982 INFO program: Boot0011* ATAPI CD
13:25:48,982 INFO program: Boot0012* PCI LAN
13:25:48,982 INFO program: Boot0013* Fedora
13:25:48,983 DEBUG program: Return code: 0
13:25:48,983 INFO program: Running... efibootmgr -b 0013 -B
13:25:48,996 INFO program: efibootmgr: Boot entry 0013 not found
13:25:48,996 INFO program: efibootmgr: Could not delete boot variable: Success
13:25:48,996 DEBUG program: Return code: 15

("error: Success" is a funny message, btw)

If needed, I can provide more logs or try some stuff. But until now, I haven't seen efibootmgr fail when I run it in my booted session - I've only experienced that the changes seemed to have been performed correctly, but did not persist after reboot. All the errors we've seen so far were from an installation environment (all netinst, maybe affects Live as well?). When we tried to execute the same efibootmgr command in the installation environment directly after it failed in anaconda, it succeeded. Maybe just the first attempt fails?

Created attachment 1043568 [details]
fallback message before grub is shown

Created attachment 1043569 [details]
anaconda error when efibootmgr fails

We have seen this again with T420s and F22 Workstation netinst. The efibootmgr command failed in anaconda during installation, but when I switched to VT and ran the same command again, it passed.

Does this get better with this build of efivar installed: https://koji.fedoraproject.org/koji/buildinfo?buildID=668518 ?

Thanks, we'll be able to test it next week.

I tried to use that update and it ... works fine :) New EFI entry is created and installed system boots.

I reproduced this with F23 boot.iso from 20150717. I propose this as an Alpha or Beta blocker using this criterion:
 A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. 
https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

The tricky part here is that although anaconda complains that uefi installation failed (you need to choose "yes" to continue), the system still might boot OK, due to uefi fallback paths. So this might not be considered strictly Alpha blocker. I don't know how often that will work, though. Also, the error seems to occur in 100% cases on our machines.

*** Bug 1236934 has been marked as a duplicate of this bug. ***

Discussed at 2015-07-27 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-07-27/f23-blocker-review.2015-07-27-16.00.log.txt . Accepted as a Beta blocker: it does violate an Alpha criterion (cited in #c10), but only sometimes, as sometimes the installed system will boot thanks to the fallback path implementation (whether this succeeds or fails will be down to details of system configuration and firmware implementation of the fallback mechanism). Additionally, there is a relatively simple workaround (switch to a console and re-run the efibootmgr commands that the installer attempted) which can be documented for Alpha testers.

Proposing as an Alpha freeze exception, it'd obviously be good to fix this for Alpha if possible.

I tried Server-DVD-TC3 with efivar-0.21-1.fc23. I tested this on two workstations where it usually fails. On both machines it works fine with updated efivars - both boot to installed system.

Discussed at today's blocker review meeting [1].

This bug was accepted as Alpha Freeze Exception - We would consider a fix for this during Alpha freeze.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-08-03/

The rebuilt efivar made it in before Bodhi activation, so the fix should actually be in stable. Marking ON_QA so we can test with RC1.

Since Alpha RCs, I have seen no issues. This seems to be fixed. Petr, can you please confirm? If you do, then close this bug, thanks.

It's been 2 weeks, I'm just gonna close this. Re-open if the bug is somehow still present.

This has been fixed in F23, but not in F22. The new F22 build was never posted to Bodhi. This is still affecting all F22 netinst installations. Please fix, thanks.

Dropping blocker metadata, since it's fixed for 23.

efivar-0.21-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16114

efivar-0.21-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update efivar'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16114

Please note that upgradepath is currently broken for this package.

efivar-0.21-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.