I wrote F18 Alpha RC3 DVD to a USB stick with livecd-iso-to-disk --format --reset-mbr --efi. From this stick, I can boot the installer and complete a native UEFI install (unlike from an actual DVD - see 856922). However, the installed system doesn't boot. It doesn't make it to grub; just boots to a flashing cursor, nothing else.
It's possible this is just weirdness on my system, it'd be good if someone else could test. I've seen this occasionally during EFI testing before, but usually a reinstall shifted it. I tried twice, hit this problem both times.
I can see from efibootmgr that the Fedora entry points at EFI\fedora\shim.efi , and that file does exist on the EFI system partition created by anaconda. The EFI system partition and /boot partition look pretty much in order, to my eye. Can't really see how to debug further.
Same happens with an install from live image written to USB stick with litd.
I wrote F18 Alpha RC3 Live Desktop to a USB stick with dd.
I can see the same problem. I can boot the installer and finish the installation. But the installed system doesn't boot then. I have Fedora entry point in efibootmgr. When I choose it, the system doesn't boot, it only skips to next boot device (PXE).
Here is smolt profile of pc, where I tested it: www.smolts.org/client/show/pub_e0775e72-9150-4dad-a11d-63552306941a
For the record, RC2 live written to USB with livecd-iso-to-disk --efi doesn't even boot successfully native EFI (it gets to the boot menu, then when you hit enter, it dumps you back to the firmware). So RC3 is at least better in that case, we didn't regress. I'll try RC2 netinst next.
RC2 netinst written with litd behaves the same as RC3 - install completes, doesn't boot. So we didn't regress this in RC3, we just didn't catch the breakage in RC2 :(
RC3 written with litd works fine for me on 2 different UEFI machines. One with SB and one without. Booting on the SB machine was odd, it prompted me to press a key before it would continue, but it did boot the installed system.
Proposing Alpha blocker so we can kick it around at the meeting.
So far, the data we have is:
FAIL - adamw x1, pschindl x1
PASS - jskladan x1, bcl x2
so that's a 3:2 pass:fail ratio. That's the kind of ratio we've shipped Alpha with before. I'd like for our EFI support to be getting more solid over time, but there's definitely a case for -1 blocker.
Further data would be very valuable. Note that in order to avoid https://bugzilla.redhat.com/show_bug.cgi?id=855849 , don't use the DVD or netinst images written to an actual disc or to USB with dd. Any image written with livecd-iso-to-disk --efi should boot okay, and the live images written with dd or to optical media should also boot okay.
For the record, this was discussed at the go/no-go meeting and rejected as an Alpha blocker. It has now been re-proposed as a Beta blocker.
So we figured out what's causing at least my failure: there should be a trailing / in the EFI boot manager entry for the Fedora installation, there wasn't. pjones has submitted a patch for this. There's an updates.img here for others to see if it solves the problem for them:
add the 'updates=http://pjones.fedorapeople.org/updates-rhbz856938.img' parameter to the 'linuxefi' line of the bootloader config when booting the installer.
Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . We agreed we don't really have the data to know how many systems are affected, so we can't determine blocker status. We agreed to punt on this one, and we expect to be able to close it soon so it won't matter any more.
The fix is in anaconda 18.9, so setting MODIFIED - please mark the 18.9 update as fixing this.
Adam, please re-test this with an 18.9 build. Yours, Adam
Tested with 18.10 (smoke3); installed system boots fine. This is fixed as of 18.10.
Fixed and in stable, closing.