Bug 466954
| Summary: | EFI on x86_64 doesn't currently boot. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stewart Adam <s.adam> | ||||||||
| Component: | kernel | Assignee: | Brian Maly <bmaly> | ||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | rawhide | CC: | bmaly, dcantrell, ddumas, katzj, kernel-maint, notting, pjones, quintela, tcallawa | ||||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-04-16 19:44:46 UTC | Type: | --- | ||||||||
| 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: | 446452 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Stewart Adam
2008-10-14 18:26:34 UTC
Which Macbook Pro? And booting the 32bit or 64bit iso? 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. 64bit should be what would work on that hardware (and 32 won't; EFI is picky). 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. 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: CONFIG_EFI=y CONFIG_FB_EFI=y CONFIG_EFI_VARS=y CONFIG_EFI_PARTITION=y I'm not sure what to do from here. Are there any other tests I can do to help pinpoint the bug? Same problem with Snapshot 2, x86_64. 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. 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. This appears to be kernel, not grub -- booting the F9 install kernel+initrd with the newest grub build works fine. Moving from the Preview list, this isn't something we'd slip preview for. I just tried compiling a vanilla 2.6.27.4 kernel (with make vanilla-x86_64) and the same problem occurs, so this could be an upstream problem. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This appears to be 4583ed514ea9ac844a6eb02d33120beaedf6837f . Maybe. Further debugging is still required. Well, reverting 4583ed514 seems to fix the problem /there/, but something else still breaks it between there and 55f262391a2365d657a00ed68edd1a51bca66af5 . Is there anything I can do to help debugging? This currently only seems to manifest on x86_64 Apple hardware. 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... Created attachment 333609 [details]
patch to resolve EFI not booting on Apple MacBook Pro 3.1
Preliminary patch I pushed upstream.
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).
Upstream commit for patch in Comment #19: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=dd39ecf522ba86c70809715af46e6557f6491131 Created attachment 334063 [details] previous patch depends on this patch Previous patch to fix efi_ioremap depends on this patch as well. Upstream commit: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=0fc59d3a01820765e5f3a723733728758b0cf577 ~Attention~ 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: https://fedoraproject.org/wiki/QA/Test_Days/2009-04-09 https://fedoraproject.org/wiki/Features/EFI Built in the rawhide kernel. Still doesn't boot, I'm using the x86_64 image available here: https://fedoraproject.org/wiki/Test_Day:AnacondaStorageRewrite_2009-04-14 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. 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? 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. 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. 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! |