Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 953447 - EFI boot on Mac halts after GRUB
Summary: EFI boot on Mac halts after GRUB
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks: F19Beta, F19BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2013-04-18 08:44 UTC by Josef Skladanka
Modified: 2013-05-10 20:52 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-30 04:41:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Josef Skladanka 2013-04-18 08:44:21 UTC
Description of problem:

When booting F19 Alpha RC3/RC4 on Mac Mini (and IIUIC Satelit has the same problem on MacBook Pro i7 <https://bugzilla.redhat.com/show_bug.cgi?id=949761#c28>), the boot halts just after GRUB on black screen with just "Secureboot not enabled" message.

This happens for USB sticks created with both l-i-t-d and dd (which both worked with TC6).

This seems to be Mac specific, as our PC-UEFI machine boots OK with RC4 litd-ed USB stick.

How reproducible:
Always

Steps to Reproduce:
1. Create USB stick with RC3/4 using either litd or dd
2. Boot on Mac
  
Actual results:
Halts boot after GRUB

Comment 1 Josef Skladanka 2013-04-18 08:48:03 UTC
Proposing as Alpha Blocker

Comment 2 satellitgo 2013-04-18 16:13:25 UTC
I find that the l-i-t-d DVD and live USB's are somehow overwritten and will no longer boot bios boot in a normal PC after this error booting on the mac.

To use them bios boot need to re-write the USB:

# livecd-iso-to-disk --format --reset-mbr --efi Fedora-19-Alpha-x86_64-DVD.iso /dev/sdc

Comment 3 satellitgo 2013-04-18 16:24:51 UTC
(In reply to comment #2)
> I find that the l-i-t-d DVD and live USB's are somehow overwritten and will
> no longer boot bios boot in a normal PC after this error booting on the mac.
> 
> To use them bios boot need to re-write the USB:
> 
> # livecd-iso-to-disk --format --reset-mbr --efi
> Fedora-19-Alpha-x86_64-DVD.iso /dev/sdc

TC6:
https://bugzilla.redhat.com/show_bug.cgi?id=949761#c12
Also confirmed that putting "GRUB_TERMINAL_OUTPUT=console" in /etc/default/grub and re-running grub2-mkconfig allows the system to boot.

Comment 4 Adam Williamson 2013-04-18 18:00:45 UTC
Re-assigning to kernel. The new lorax wasn't actually used in RC3, which leaves the only currently plausible suspect as the kernel (it's the only possibly-related component which changed between TC6 and RC3).

spot and tflink confirm the bug on other Macs. It would be good if multiple testers could confirm that this works on TC6 but not RC3/RC4, and also if someone could try booting from an actual spinny silver disc. Also, from pjones:

 <pjones> so what somebody needs to do is to get F18 on one of the machines and try updating each of grub-efi and kernel individually and together on the installed machine.
 <pjones> If one of them fails, we have a culprit.  If they work fine together, then it really is the media, but since shim is validating kernel correctly, I doubt that.

TC6 had kernel-3.9.0-0.rc6.git2.1.fc19 , RC3/RC4 have kernel-3.9.0-0.rc6.git2.3.fc19 . Those aren't very different. If I'm reading the changelog right, these are all that changed:

* Mon Apr 15 2013 Josh Boyer <jwboyer> - Grab fixes for UEFI space issues (rhbz 947142) 
* Fri Apr 12 2013 Josh Boyer <jwboyer> - Enable CONFIG_LDM_PARTITION (rhbz 948636)

the UEFI space issues fix seems like the only one of those that could be in play here.

Discussed at 2013-04-18 go/no-go meeting, acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting-2/2013-04-18/f19_alpha_gono-go_meeting.2013-04-18-17.00.log.txt . Rejected as a blocker on the grounds that Mac hardware as a proportion of all systems isn't enough to block Alpha for. We might consider this a Beta blocker, and it's almost certainly a Final blocker. Re-proposing as Beta blocker.

Comment 5 Adam Williamson 2013-04-18 18:02:46 UTC
Actually, I guess it's barely possible that CONFIG_LDM_PARTITION is doing something wacky here.

Comment 6 Alex Murray 2013-04-22 12:06:54 UTC
Just confirming I see this also on my Macbook Pro 9,1 - kernel-3.9.0-0.rc6.git2.1.fc19 boots fine, but upgrading to kernel-3.9.0-0.rc7.git3.1.fc19 fails to boot

Comment 7 Alex Murray 2013-04-23 12:08:45 UTC
Rebuilding 3.9.0-0.rc7.git3.1.fc19 without CONFIG_LDM_PARTITION doesn't appear to help... am currently rebuilding it without the efi space fixes instead to see if that helps...

Comment 8 Josh Boyer 2013-04-23 12:36:03 UTC
Doing what pjones suggested as written in comment #4 is going to be much more helpful as a starting point than randomly rebuilding kernels.  Alternatively, you could do what Matthew has suggested:

< mjg59> Take an F19 live USB image. Mount the HFS+ filesystem on it. Copy over grub.efi from F18.

Comment 9 Alex Murray 2013-04-23 13:02:53 UTC
Actually Josh it seems dropping the efi space fix patch fixes the problem - so it seems 'randomly rebuilding kernels' is actually quite helpful - FYI it's not 'random' to try rebuilding the kernel, systematically eliminating each change between a working kernel and a non-working kernel (think git bisect)...

Would be good if someone else could confirm this fix - any idea how to proceed?

Comment 10 Josh Boyer 2013-04-23 21:00:35 UTC
So.  I acquired a Macbook Pro 10,2.  It boots the F19 Alpha live Desktop image just fine.

[liveuser@localhost ~]$ cat /etc/fedora-release 
Fedora release 19 (Schrödinger’s Cat)
[liveuser@localhost ~]$ uname -a
Linux localhost 3.9.0-0.rc6.git2.3.fc19.x86_64 #1 SMP Mon Apr 15 20:34:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[liveuser@localhost ~]$ 


For those of you that have seen this, have you all be trying the DVD image?  Have any of the live images worked?  I simply downloaded the iso and used dd to put it on a USB key.

So perhaps this is only on older Mac models.

Comment 11 Luke Macken 2013-04-23 23:36:20 UTC
I hit this issue with an old iMac8,1 and a new MacBookAir5,2 using the F19 Alpha live desktop image. I tried creating the liveusb with both dd and the liveusb-creator. TC6 works fine though.

Comment 12 Alex Murray 2013-04-24 11:08:17 UTC
I notice the efi-space-fixes.patch doesn't include the efi_no_storage_paranoia[1] variable patch which might be used to bypass this dynamically (ie. without having to rebuild the kernel without the current efi-space-fixes patch)... would it be possible to add the efi_no_storage_paranoia variable patch as well?

[1] https://patchwork.kernel.org/patch/2451441/

Comment 13 Alex Murray 2013-04-24 11:12:45 UTC
Whoops ignore my previous comment - just noticed it is already in 3.9-rc8 so I assume we'll get it for free soon enough

Comment 14 Josh Boyer 2013-04-24 13:11:48 UTC
(In reply to comment #13)
> Whoops ignore my previous comment - just noticed it is already in 3.9-rc8 so
> I assume we'll get it for free soon enough

Correct.

I'll hopefully have a live image for people to test in the next 45min or so.

Comment 15 Josh Boyer 2013-04-24 14:19:33 UTC
http://jwboyer.fedorapeople.org/pub/livecd-fedora-livecd-desktop-201304232101.iso

Please test the above image by dd'ing it to a USB key and booting from that.  When you boot, edit the kernel parameters and remove 'rhgb quiet' and add 'selinux=0'.  That should take you directly to the gnome desktop.  This boots on my macbook pro, and at least one other macbook pro that previously didn't boot.

The important thing is if it gets past the grub hang people are seeing.

Comment 16 Luke Macken 2013-04-24 16:33:53 UTC
(In reply to comment #15)
> http://jwboyer.fedorapeople.org/pub/livecd-fedora-livecd-desktop-
> 201304232101.iso
> 
> Please test the above image by dd'ing it to a USB key and booting from that.
> When you boot, edit the kernel parameters and remove 'rhgb quiet' and add
> 'selinux=0'.  That should take you directly to the gnome desktop.  This
> boots on my macbook pro, and at least one other macbook pro that previously
> didn't boot.
> 
> The important thing is if it gets past the grub hang people are seeing.

This image works on my iMac8,1 and MacBookAir5,2.

Comment 17 Adam Williamson 2013-04-24 16:49:00 UTC
Discussed at 2013-04-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-24/f19beta-blocker-review-1.2013-04-24-16.00.log.txt . We're delaying the decision on Beta blocker status for now - there were not many people present at the meeting to decide what's a fairly contentious judgement call, and testing appears to be ongoing. If this isn't fixed by the next review meeting, we'll discuss it again.

Comment 18 satellitgo 2013-04-24 17:42:18 UTC
remove 'rhgb quiet' and add
'selinux=0'

livecd-iso-to-disk --format --reset-mbr --efi livecd-fedora-livecd-desktop-201304232101.iso /dev/sdc

Boots to "secure boot not enabled": then  to Gnome Version 3.8.0

Macbook Pro 8,1

Comment 19 satellitgo 2013-04-24 17:46:51 UTC
dd USB also boots on MacBook 8,1 but shows a "windows(f)" and 2 EFI USB ICONS while LITD USB only shows 1 EFI USB ICON

Comment 20 Josh Boyer 2013-04-24 17:52:06 UTC
Great.  Thanks for testing.  The fix has been committed to the F19 and rawhide kernels.

Comment 21 satellitgo 2013-04-24 20:54:50 UTC
(In reply to comment #19)
> dd USB also boots on MacBook 8,1 but shows a "windows(f)" and 2 EFI USB
> ICONS while LITD USB only shows 1 EFI USB ICON
UPDATE: anaconda installed to an external USB hard disk correctly from the dd USB

Comment 22 Fedora Update System 2013-04-24 22:28:42 UTC
kernel-3.9.0-0.rc8.git0.2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.9.0-0.rc8.git0.2.fc19

Comment 23 Fedora Update System 2013-04-25 03:43:15 UTC
Package kernel-3.9.0-0.rc8.git0.2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.9.0-0.rc8.git0.2.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6574/kernel-3.9.0-0.rc8.git0.2.fc19
then log in and leave karma (feedback).

Comment 24 Alex Murray 2013-04-25 04:52:35 UTC
Thanks Josh for the updated image - out of interest, why does selinux need disabling for this to work? Can Dan Walsh or similar be CC'd into this to try and get selinux to work with this rather than having to disable it? Does selinux also need to be disabled permanently once installed as well or only to boot the installer?

Comment 25 Adam Williamson 2013-04-25 05:13:17 UTC
alex: I checked that with Josh earlier - it was specific to his test image. He built it on F18, and if you build an F19 live image on F18, there are problems with the SELinux configuration. This issue won't affect any official images.

Comment 26 Alex Murray 2013-04-25 05:19:56 UTC
No worries - thanks for resolving everyone.

Comment 27 Fedora Update System 2013-04-30 04:41:22 UTC
kernel-3.9.0-0.rc8.git0.2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 28 Daniel Stone 2013-05-10 15:14:50 UTC
I hit this with the Alpha-1 image too; unfortunately Josh's image now 403s, so I guess I'll just try F18 + yum upgrade.

Comment 29 Josh Boyer 2013-05-10 15:16:08 UTC
(In reply to comment #28)
> I hit this with the Alpha-1 image too; unfortunately Josh's image now 403s,
> so I guess I'll just try F18 + yum upgrade.

Use Beta TC3:

http://alt.fedoraproject.org/pub/alt/stage/19-Beta-TC3/

I killed permissions to the test image on my page because it was built incorrectly.

Comment 30 Daniel Stone 2013-05-10 20:52:28 UTC
That works great, thanks Josh.


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