Description of problem: The efidisk.img image for booting is much less Mac friendly than it could be. 1.) It is possible to have a 32-bit image and a 64-bit image in the same folder with a single config file that works for both, so this does not take much effort. All it would mean is adding a BOOTIA32.efi along with BOOTX64.efi. This would allow 64-bit Mac's with a 32-bit EFI implementation to boot from the image. 2.) There is an infamous problem where some Mac's don't having a functioning keyboard when booting from a CD-ROM with both EFI and BIOS boot support, meaing they get stuck and can not proceed. But when booting from a thumb drive with EFI only support you can navigate a grub menu. Furthermore, including the 'fakebios' option keeps it working through the install, so it would be nice to have an additional option (like rescue, basic video, etc.) that people can select for Mac's that includes the fakebios option. 3.) Finally, for whatever reason, even if you do get lucky and have a Mac with a 64-bit EFI implementation the image begins to boot, but hangs. I don't know what options are being used to create the efi images, but these work fine for me, and I see no reason why they would not work with other systems as well: grub2-mkimage -d /usr/lib/grub2-efi/x86_64-efi/ -o BOOTX64.efi \ -O x86_64-efi --prefix /efi/boot part_gpt part_msdos lvm fat ext2 \ chain boot configfile normal minicmd linux reboot halt search \ gfxterm gfxmenu efi_gop efi_uga video loadbios gzio video_bochs \ video_cirrus echo true loadenv grub2-mkimage -d /usr/lib/grub2-efi/i386-efi -o BOOTIA32.efi -O i386-efi \ --prefix /efi/boot part_gpt part_msdos lvm fat ext2 chain boot configfile \ normal minicmd linux reboot halt search gfxterm gfxmenu efi_gop efi_uga \ video loadbios gzio video_bochs video_cirrus echo true loadenv The only exception I have seen whre this does not work is due to a bug with radeondrmfb which has been reported in 736860 and others already. Even that can be worked around by using nomodeset or nomodeset and vnc to at least circumvent the issue for installation. Combined with some recommendations made in: https://bugzilla.redhat.com/show_bug.cgi?id=746421 these minor things would wipe out about 95% of the misery people encounter trying to install Linux on Mac's. The last real issue remains a way to tell the firmware on the system where to find the EFI image since Mac's don't actually search for it like they should, but that can be fairly easily fixed by booting from OS X install media and running (as an example): bless --mount /Volumes/Untitled --setBoot --file \ /Volumes/Untitled/EFI/BOOT/BOOTIA32.efi Even without doing this you can hold down the Alt key when booting and select Fedora (which might be preferred in a dual boot scenario.) Version-Release number of selected component (if applicable): Fedora 16, grub2-efi-1.99-9 How reproducible: Always Steps to Reproduce: 1. Try to boot a Mac from thumb drive made with efidisk.img 2. It either won't boot because it has a 32-bit EFI and there is no image, or it will probably hang if it has a 64-bit EFI Actual results: Install fails Expected results: Install can (and should) succeed Additional info:
CC'ing some relevant people.
For what it is worth I also have some rough instructions from my installs. They are fairly rough, but demonstrate the issues I have seen, and that, for the most part, things should be able to work correctly. http://fedorasolved.org/Members/jmontleon/installing-fedora-16-on-macbooks-using-grub2-efi
Following Jason's well written instructions and per his suggestion in email, I waited for the final release of Fedora 16 (released on 8 November 2011) as apparently, "a bug was fixed last minute in the beta that caused kernels to hang when efi booting on at least some Mac's". With 64-bit Fedora 16 installed onto a virtual machine system (Virtual Box), including grub2 sources which I downloaded from koji (grub2-efi-1.99-12.fc16.i686.rpm and grub2-efi-1.99-12.fc16.x86_64.rpm from 12.fc16), I was able to build my own copies of both BOOTIA32.efi and BOOTX64.efi (precisely following Jason's instructions). Using my BOOTX64.efi boot loader and Jason's grub.cfg (see his page at the URL in Comment #2 above), from a USB attached disc, I was successfully able to get grub to boot up the Fedora 16 text-based installer on the following machines which have Apple implementations of 64-bit EFI firmware: Mac Pro 2010 (model MacPro5,1) MacBook Air 11" (model MacBookAir4,1) Both machines above booted fine from the default menuentry thus fakebios was *not* required (noted: Jason authored his grub.cfg to use alpha version of F16 whereas I am using initrd.img and vmlinuz from F16 final release as aforementioned). However, using my BOOTIA32.efi with an Apple Late 2006 Intel Xserve (Xserve1,1) which has 32-bit EFI and 64-bit capable Xeon CPUs, I was unsuccessful (even when trying Jason's additional grub.cfg menu items such as those with fakebios, nomodeset or nomodeset and vnc). When attempting to boot with the fakebios grub.cfg options, this text was echoed to the physical display attached to the Xserve's built-in video card: > ROM Image Present This would be followed by a minute or two of disc activity on my USB drive (which also happens when successfully booting the 64-bit aforementioned Macs), and then the display would go entirely dark and no text was visible and the system appeared to be non-responsive. I can't help but wonder if the additional bug Jason refers to above "radeondrmfb which has been reported in 736860" might not have been fully resolved and perhaps is affecting the Xserve1,1? The Xserve1,1 has a default shipping configuration from Apple that includes a baseline video card, the ATI Radeon X1300. Jason's MacBook which gave him trouble had an ATI Radeon X1600. For what its worth, the aforementioned MacPro5,1 shipped by Apple with a standard ATI Radeon HD 5770 (and is capable of mirroring the Fedora 16 installer after grub2 has called initrd and the kernel) to two displays simultaneously. The MacBookAir4,1 has a Chipset Model of "Intel HD Graphics 3000" that is built-in and part of the Sandy Bridge architecture (Core i7 CPU in this case). I'd be happy to further test the Xserve1,1 to determine (and resolve) if it is experiencing the radeondrmfb bug 736860 (note: I have successfully booted this same Xserve1,1 from a legacy 32-bit EFI grub1 bootloader created by Chris Smart that works fine for installing both an Ubuntu 9.10 32-bitand 64-bit system and the Xserve's built-in ATI Radeon X1300 has no problem displaying everything ranging from the grub1 menu to the text-based installer to the terminal prompt with a physical display attached to the Xserve in a KVM context although it was later used headless. Hence, since Ubuntu has worked, there's no logical reason why Fedora 16 or 17 shouldn't be able to work on the Xserve1,1 too. Apple has discontinued its Xserves and its not difficult to imagine many of them in the future will be converted to running Linux on bare metal.
32-bit EFI isn't a supported configuration for Fedora, so I'm afraid this probably isn't an issue we'll look at in detail.
Out of curiosity, why is 32-bit EFI not a supported configuration for Fedora? Logically why wouldn't 32-bit EFI be supported? Thank you for the follow up.
Could you please split out any issues from this bug which remain in Fedora 16 and which are not 32-bit EFI issues, after checking whether they've already been reported? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Trying to tie together all the macbook boot problems. 64-bit grub2-efi packages do not take 32-bit EFI into consideration Bug 746421 Unable to boot Fedora 15 Live iso image from grub2 (iso-scan/filename kernel parameter) Bug 723801 RV530 KMS fails on MacBookPro2,1 EFI Bug 735860
There are lots of related bugs. There may be some underlying issue tying many of them together. It's worth investigating so that these bugs can come tumbling down. via https://bugzilla.redhat.com/show_bug.cgi?id=765954#c11 > However, the commonality appears to be a problem getting VBIOS information > during an EFI boot. > > Bug 751147 does not have the same GPU as the above bugs, but Ben Skeggs > suspects VBIOS corruption during EFI boot. So it too might be related. > https://bugzilla.redhat.com/show_bug.cgi?id=751147#c32 EFI boot fails on Macs with NVIDIA GeForce 8600M GT graphics adapters (MacBook Pro 3,1 and 4,1) Bug 751147 EFI boot failure to properly initialize graphics on Macs with Intel and AMD graphics (MacBookPro 8,2 and 8,3 Bug 765954 Review Request: mactel-boot - boot tools for Intel Apple hardware Bug 755093 MacBookPro6,2: kernel: IRQ handler type mismatch for IRQ 0 Bug 756866 =====BIOS specific BIOS compatibility boot produces corrupted graphics on Macs with NVIDIA GeForce 320M video adapters (Macbook Air 3,1,1 and 3,2) Bug 650949
More bugs: error installing bootloader, LiveCD, Mac OS dual boot Bug 746885 Apple computers require MBR (full or 'hybrid', not protective) to boot Fedora in CSM mode Bug 746901 Also, shouldn't a pure EFI boot/install be attempted when possible? http://arunraghavan.net/2010/02/pure-efi-linux-boot-on-macbooks/
What I have come to realize over time is that it always seems possible to do an EFI install if you are willing to jump through enough hoops. But it is not always best when you get there. Older systems in particular present a number of problems just booting. They boot with a dead keyboard so you can't even select a legacy or EFI boot. They require a 32-bit EFI image since they use a 32-bit EFI implementation Even if you get past those two by making your own boot media you need to use fakebios in grub2 to boot without a dead keyboard. Even once you go through all that, you might hit video bios issues that prevent you using anything better than fbdev for X11. It works, but it's less than ideal. And I have never been able to use loadbios in order to circumvent issues like #735860 with ATI cards. Add to that the fact that Mac's won't legacy boot to a GPT partition and it invites even more fun now that the installer uses GPT unless you add nogpt to the kernel option Then there are models like the MacBook Air 1,1 that has a 64-bit EFI implementation and seems to work fine once you get Fedora installed, but I have never been able to get a Fedora DVD to boot properly, meaning more jumping through hoops to get the installation completed. So the question is how do you get through an EFI install for every case, and once there was it even best. I have written instructions for 4 different models in the past, and each one has something different that goes wrong: http://fedorasolved.org/Members/jmontleon/installing-fedora-16-on-macbooks-using-grub2-efi Any one taken alone seems like it should be workable, but all together it's a big dance, and you need to make sure you're not stepping on any other PC installations while running through it. And finally, if you're looking to compile a list of bugs that affect Mac's https://bugzilla.redhat.com/show_bug.cgi?id=543693 might be a good one to add. It mentions a MacbookPro 8,2 and I have witnessed it on a Macbook Pro 2,2 and a mid-2011 Mac-Mini.
As mentioned before, I have an Xserve1,1 with 32-bit EFI < http://www.everymac.com/systems/apple/xserve/stats/xserve-intel-xeon-2.0-quad-specs.html > that I have not been able to successfully boot Fedora. However, this same Xserve is capable of booting from an EFI boot loader created by Chris Smart < http://blog.christophersmart.com/2009/07/23/linux-on-an-apple-xserve-efi-only-machine/ > for Ubuntu Karmic 9.10 but Chris' boot loader for Red Hat won't work with Fedora 16 for me on this Xserve. It may be that the older ATI graphics card shipped by Apple (ATI Radeon X1300 PCI Express with 64 MB of GDDR3 SDRAM) is troublesome with respect to Fedora (video driver)? Nonetheless, if Ubuntu can boot up then there's no reason why Fedora shouldn't be able to either! I'd love to be able to boot Fedora on the Xserve1,1. I also have the other two machines aforementioned (MacPro5,1 and MacBookAir4,1) which I have been able to boot. Its pretty clear that Apple is here to stay and their Mac hardware will continue to proliferate globally to a worldwide customer base (even as they sell tons of iPads and iPhones, Mac sales are up while the rest of the industry is sagging). Its also clear Apple, true to its nature, unnecessarily deprecates / end-of-lifes its usually decent hardware too soon by dropping support with respect to Mac OS X (case in point, Mac OS X 10.8 "Mountain Lion" will be released later this year and I have friends with Mac Pro 2007 models who are super disappointed that they will not be able to run it < http://arstechnica.com/apple/news/2012/02/which-macs-will-os-x-mountain-lion-support.ars >. These machines should certainly make fantastic Fedora servers or Fedora desktops! I'm not a firmware expert but I am committed to helping in any way I can (testing, feedback, etc.), and am equally committed to giving legacy Apple hardware a longer life that these machines deserve!
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
The bug(s) described here still appear in Fedora 20.
As about ten different bugs ultimately got discussed here, that's insufficiently precise. What bugs precisely do you believe still exist? Note that lack of 32-bit EFI support is not considered to be a bug, as per c#4. We choose not to support 32-bit UEFI firmwares. (There's a possibility we may wish to add some form of support for the much more recent wave of Intel Baytrail-based tablets which 32-bit UEFI firmwares for $REASONS, but that's not decided yet, and I don't know if that support would help the older 32-bit EFI Macs.)
OK, I was primarily referring to the lack of 32-bit EFI, though when its added manually there are graphics problems much like Bug 735860, which was also closed do to F16 being end-of-lifed. When non-EFI boot media is used, boot proceeds well into running from initramfs, but fails with dracut-initqueue warning that /dev/root doesn't exist, like Bug 981486 and others. However, after reviewing those bugs I wanted to revisit how I created the non-EFI boot media to see if I made a mistake. Haven't had a chance to do that yet, so the jury is still out.
I don't think there's going to be any value to re-opening this bug. Can you just follow up on the appropriate bugs for specific issues you run into on the affected hardware when trying a non-EFI install? Just to be realistic, though, I don't think these issues will get a particularly high priority on anyone's list: if I were you I'd work on the assumption Fedora just isn't ever likely to work perfectly on the Apple systems that were shipped with 32-bit EFI firmwares, I'm afraid.