Bug 856938

Summary:	Native UEFI install from F18 Alpha RC3 DVD written to USB with livecd-iso-to-disk fails to boot
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	anaconda	Assignee:	Brian Lane <bcl>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	18	CC:	anaconda-maint-list, g.kaviyarasu, jonathan, kparal, pschindl, robatino, vanmeeuwen+fedora
Target Milestone:	---	Keywords:	CommonBugs
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:	https://fedoraproject.org/wiki/Common_F18_bugs#uefi-boot-fail
Fixed In Version:	anaconda-18.9-1.fc18	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-08 16:27:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	752660

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:

http://pjones.fedorapeople.org/updates-rhbz856938.img

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.