Bug 856938 - Native UEFI install from F18 Alpha RC3 DVD written to USB with livecd-iso-to-disk fails to boot
Summary: Native UEFI install from F18 Alpha RC3 DVD written to USB with livecd-iso-to-...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks: F18Beta, F18BetaBlocker
TreeView+ depends on / blocked
Reported: 2012-09-13 07:48 UTC by Adam Williamson
Modified: 2012-10-08 16:27 UTC (History)
7 users (show)

Fixed In Version: anaconda-18.9-1.fc18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-10-08 16:27:40 UTC
Type: Bug

Attachments (Terms of Use)

Description Adam Williamson 2012-09-13 07:48:58 UTC
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.

Comment 1 Adam Williamson 2012-09-13 08:10:08 UTC
Same happens with an install from live image written to USB stick with litd.

Comment 2 Petr Schindler 2012-09-13 09:39:41 UTC
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

Comment 3 Adam Williamson 2012-09-13 10:40:08 UTC
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.

Comment 4 Adam Williamson 2012-09-13 10:49:44 UTC
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 :(

Comment 5 Brian Lane 2012-09-13 18:11:51 UTC
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.

Comment 6 Adam Williamson 2012-09-13 18:53:48 UTC
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.

Comment 7 Adam Williamson 2012-09-18 19:10:02 UTC
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.

Comment 8 Adam Williamson 2012-09-19 21:40:08 UTC
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.

Comment 9 Adam Williamson 2012-09-26 19:20:18 UTC
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.

Comment 10 Adam Williamson 2012-09-26 19:21:29 UTC
Adam, please re-test this with an 18.9 build. Yours, Adam

Comment 11 Adam Williamson 2012-09-29 00:00:51 UTC
Tested with 18.10 (smoke3); installed system boots fine. This is fixed as of 18.10.

Comment 12 Kamil Páral 2012-10-08 16:27:40 UTC
Fixed and in stable, closing.

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