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
Summary: | EFI boot on Mac halts after GRUB | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Josef Skladanka <jskladan> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | anaconda-maint-list, awilliam, bcl, daniel, gansalmon, itamar, jonathan, kernel-maint, lmacken, madhu.chinakonda, murray.alex, robatino, satellitgo |
Target Milestone: | --- | Keywords: | CommonBugs |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | https://fedoraproject.org/wiki/Common_F19_bugs#uefi-mac-fail | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-04-30 04:41:19 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: | 834087 |
Description
Josef Skladanka
2013-04-18 08:44:21 UTC
Proposing as Alpha Blocker 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 (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. 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. Actually, I guess it's barely possible that CONFIG_LDM_PARTITION is doing something wacky here. 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 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... 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. 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? 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. 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. 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/ 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 (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. 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. (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. 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. 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 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 Great. Thanks for testing. The fix has been committed to the F19 and rawhide kernels. (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 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 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). 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? 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. No worries - thanks for resolving everyone. 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. 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. (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. That works great, thanks Josh. |