Bug 466954 - EFI on x86_64 doesn't currently boot.
Summary: EFI on x86_64 doesn't currently boot.
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Brian Maly
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F11Blocker, F11FinalBlocker
TreeView+ depends on / blocked
Reported: 2008-10-14 18:26 UTC by Stewart Adam
Modified: 2013-01-10 04:51 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-04-16 19:44:46 UTC

Attachments (Terms of Use)
patch to resolve EFI not booting on Apple MacBook Pro 3.1 (1.79 KB, patch)
2009-02-28 16:37 UTC, Brian Maly
no flags Details | Diff
updated patch to resolve issue (2.56 KB, patch)
2009-03-04 20:49 UTC, Brian Maly
no flags Details | Diff
previous patch depends on this patch (547 bytes, patch)
2009-03-04 20:56 UTC, Brian Maly
no flags Details | Diff

Description Stewart Adam 2008-10-14 18:26:34 UTC
Description of problem:
Creating a Live USB key using the new --mactel option from livecd-iso-to-disk results in a bootable key which is displayed in the Macbook Pro's boot options, but selecting the USB key will result in a GRUB splash screen with no text. Hitting a key displays the menu as expected, but from there the kernels won't boot.

Version-Release number of selected component (if applicable):
F10 Snapshot

How reproducible:

Steps to Reproduce:
1. Start MacBook Pro, holding alt/option key
2. Select Live USB key
3. Press any key to display the menu from the blank screen
4. Select a kernel
Actual results:
The USB key's activity lights flash for a few seconds then everything hangs. The GRUB splash screen with no text is still showing, so no errors are displayed.

Expected results:
kernel starts, or kernel panic is displayed instead of GRUB splash screen.

Additional info:

Comment 1 Jeremy Katz 2008-10-15 01:53:55 UTC
Which Macbook Pro?  And booting the 32bit or 64bit iso?

Comment 2 Stewart Adam 2008-10-15 02:03:15 UTC
MacBook Pro 4,1 (Feb. 2008) with all updates applied. Let me know if you need the boot ROM version. I'm booting the 64bit ISO, but if you'd like I can give the 32bit ISO a try later this week.

Comment 3 Jeremy Katz 2008-10-15 13:37:53 UTC
64bit should be what would work on that hardware (and 32 won't; EFI is picky).

Comment 4 Stewart Adam 2008-10-16 04:37:46 UTC
I just gave the i686 image a go for fun and it did work (GRUB I mean) but same symptoms - no text until I enter the menu and no kernels boot.

Comment 5 Stewart Adam 2008-10-17 17:56:58 UTC
Hm, so I just tried putting compiling grub2 and making an EFI image as shown here: http://grub.enbug.org/TestingOnEFI

Turns out that version is freezing too, so unless there's been a major bug introduced to GRUB I think our kernel is at fault. According that page, we need to include EFI support in the kernel for it to boot properly... I grep'ed the the kernel config and this came up:


I'm not sure what to do from here. Are there any other tests I can do to help pinpoint the bug?

Comment 6 Stewart Adam 2008-10-18 16:49:24 UTC
Same problem with Snapshot 2, x86_64.

Comment 7 Stewart Adam 2008-10-26 02:30:00 UTC
I hate to reply to my own comment twice in a row,  but I just tried with Snapshot 3, x86_64 and same results.

In case this help narrow the problem down, I did some reading and a few people on forums mentioned that Apple's firmware is picky about EFI images and won't boot single arch images. This probably isn't true anymore as of Bootcamp 2.1 since the single-arch EFI image loads, it just can't boot any kernels. I compile grub2 for i386 and x86_64 anyways and created a fat EFI image (which bundles the x32 and x64 images together) using the tools provided in rEFIt and it still had the same problem.

Comment 8 Jesse Keating 2008-10-27 22:02:40 UTC
I seem to be able to reproduce the inability to boot kernels on my intel imac
(which is capable of x86_64).  Adding myself to this bug so that I can test any
potential fixes.

Comment 9 Peter Jones 2008-10-28 18:31:54 UTC
This appears to be kernel, not grub -- booting the F9 install kernel+initrd with the newest grub build works fine.

Comment 10 Jesse Keating 2008-10-28 23:19:54 UTC
Moving from the Preview list, this isn't something we'd slip preview for.

Comment 11 Stewart Adam 2008-10-29 22:05:42 UTC
I just tried compiling a vanilla kernel (with make vanilla-x86_64) and the same problem occurs, so this could be an upstream problem.

Comment 12 Bug Zapper 2008-11-26 03:52:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:

Comment 13 Peter Jones 2009-01-15 22:37:23 UTC
This appears to be 4583ed514ea9ac844a6eb02d33120beaedf6837f .  Maybe.  Further debugging is still required.

Comment 14 Peter Jones 2009-01-15 22:51:44 UTC
Well, reverting 4583ed514 seems to fix the problem /there/, but something else still breaks it between there and 55f262391a2365d657a00ed68edd1a51bca66af5 .

Comment 15 Stewart Adam 2009-01-16 18:30:50 UTC
Is there anything I can do to help debugging?

Comment 16 Peter Jones 2009-02-12 18:18:59 UTC
This currently only seems to manifest on x86_64 Apple hardware.

Comment 17 Stewart Adam 2009-02-21 19:25:01 UTC
I tried applying the commit diffs from http://people.fedoraproject.org/~pjones/bz466954.txt backwards, but there's been too many changes since - they don't apply cleanly anymore...

Comment 18 Brian Maly 2009-02-28 16:37:28 UTC
Created attachment 333609 [details]
patch to resolve EFI not booting on Apple MacBook Pro 3.1

Preliminary patch I pushed upstream.

Comment 19 Brian Maly 2009-03-04 20:49:52 UTC
Created attachment 334057 [details]
updated patch to resolve issue

New patch. Use efi_ioremap instead and fix efi_ioremap to handle larger mem region allocations (>400K).

Comment 21 Brian Maly 2009-03-04 20:56:03 UTC
Created attachment 334063 [details]
previous patch depends on this patch

Previous patch to fix efi_ioremap depends on this patch as well.

Upstream commit:

Comment 23 Chris Ward 2009-04-06 09:30:24 UTC

This bug appears to pertain to an important F11 feature, EFI, which the Fedora Community will be testing in an upcoming Fedora Test Day. Your participation in the action would be greatly appreciated!

More information:

Comment 24 Jesse Keating 2009-04-14 00:38:07 UTC
Built in the rawhide kernel.

Comment 25 Stewart Adam 2009-04-16 02:43:20 UTC
Still doesn't boot, I'm using the x86_64 image available here:

There does seem to be some improvement though, as now I can see from the read LED on the USB key that it loads vmlinuz0/initrd.img and it gets at least partway through the boot process.

The read LED will flash for a few seconds as it reads vmlinuz0/initrd.img, then there's nothing for about 10-15 seconds, and then the read LED comes on again and flickers for another 20 seconds or so. Something seems to happen as it boots up, since ctrl+alt+delete or pressing the power button and then "enter" (which should result in the clicking of the "shutdown" button) does nothing.

Comment 26 Brian Maly 2009-04-16 16:16:15 UTC
Can you see if you can ssh into the system? I saw the same behavior on several systems and the problem turned out to be failure in video init (i.e. something happening but blank screen). I could ssh in though. The video problem was easy to fix. 

If you can ssh in, please attach a /var/log/dmesg to this BZ.

Also, what type of hardware is affected?

Comment 27 Stewart Adam 2009-04-16 17:06:15 UTC
I don't have another machine nearby, so I'll post the results later tonight when I get home. This is still on the MacBook Pro 4,1 with all firmware updates applied.

Comment 28 Brian Maly 2009-04-16 17:13:17 UTC
MacBook Pro specifically has video init issues. You may need an extra patch thats not in this kernel image, but Im happy to help get this working. Thanks for the info though. Your exact hardware was tested and working with the latest kernel, not sure what changes were included in the F11 UEFI test day image. Might be missing a kernel patch, etc.

Comment 29 Stewart Adam 2009-04-16 19:44:46 UTC
I'll set this back to closed since the original issue has been fixed, I've reported bug #496134 about the video problem. Thanks for the help!

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