Description of problem: I'm having odd problems with grub-0.97-79.fc16 (EFI version) on my 2011 mac mini. Getting it to boot properly (either from DVD or USB) is a real hit-and-miss. Most of the time it does not work properly. Version-Release number of selected component (if applicable): grub-0.97-79.fc16.x86_64 How reproducible: 9 out of 10 times Steps to Reproduce: 1. Boot DVD install media or USB with efidisk.img 2. 3. Actual results: Few scenario's I've encountered: 1. Boot just fine 2. Presents black screen and hangs 3. Shows the boot menu, but when trying to edit the boot cmd it hangs 4. Stops half way painting the borders and hangs Expected results: Boots to grub menu and does not hang when modifying the boot cmd line or doing a plain boot. Additional info: Continuation of BZ #741781 0.97-75 works every time and boots the system just fine 0.97-78 works every time and boots the system just fine It seems -79 introduced this erratic behaviour. How to investigate what causes this problem? btw when I remove grub.conf I always get to grub prompt just fine with 0.97-79. Manually loading the kernel works every time. Loading initrd does not work every time. When initrd.img loads, it takes a long time. After giving the boot command the system hangs again.
Best as I can tell, EFI booting Apple hardware with an OS other than Mac OS is hit or miss, likely due to Apple's non-standard EFI implementation (mostly Intel EFI 1.10 and some UEFI 2.x and maybe some Apple specific stuff also). This is why they include a CSM (Compatibility Support Module) to emulate BIOS, so "legacy" booting is still possible with other OS's (non-Mac OS's). For most people it is non-trivial and non-obvious to determine if they've actually booted EFI only, or CSM/BIOS, but dmesg is considerably different in the very initial stages of booting depending on which method is active. It's easy to end up with GRUB/GRUB2 BIOS (first part in the MBR then stage loaded per usual) as well as EFI on the same hard drive. If you remove "rghb" and "quiet" from the kernel argument (from the grub menu directly or edit grub.conf) you'll get a lot of text during boot that might reveal what the problem is at the moment of hang. You could then post full results of dmesg output to a file on a USB stick for each boot. For the 1 in 10 where you're apparently (?) getting a full GUI this is straight forward. But in the cases where the screen goes black and there's an apparent hang, at least for me it's just that the video driver loading conflicts with EFI so there's simply no video but the system is still otherwise active. So you could just wait a bit longer than usual, and do an option-command-Fn-F2 and login as root in the blind, then also in the blind mount a USB stick, and point dmesg output to a file on the USB stick. Point is, it probably really isn't hanging, it's just losing video at the time the video driver and/or X are becoming active. And I have had this problem with both Grub legacy and Grub 2. At least for my Macbook 4,1 I have 100% failure to EFI boot with a GUI. I can choose kernel parameter nomodeset=0 to prevent nouveau from loading and end up with a text only boot but otherwise with full services. And as it turns out it's a nouveau conflict with EFI where EFI isn't giving up the information nouveau (or the Nvidea proprietary driver) needs. So I'm SOL for a GUI boot on this hardware. On the Macbook 8,1 I also haven't gotten it to do EFI boot yet, but I haven't spent the time to figure out what its problem is (different video hardware so it could be something else). So for now, I tolerate CSM/BIOS based booting of Apple hardware and that appears to work pretty much all of the time.
@Chris, thanks for your elaborate explanation. Unfortunately you headed into the wrong direction :-). My problem is with the latest version of grub (efi) (legacy / 0.97) itself. It either does not start properly or freezes during operation. When it manages to start the kernel it works like a charm. So no issues with the kernel and graphical desktop, X drivers itself. Older versions of grub 0.97 work fine as does grub2-efi. The real problem here is that I cannot reliably boot from install media in EFI mode. I can work around this by creating a custom efidisk.img using an older grub.efi. Once I get my system booted using efi I can install grub2-efi and work around grub 0.97 efi problems. Regarding your problem EFI booting into the GUI on the MBA. I have that problem as well with my MBA. In EFI mode there is no (emulation) VGA BIOS and both nouveau and the binary nvidia driver seem to need this to get up and running. I also still use CSM/BIOS on the MBA.
retested with grub-0.97-83 using tflink's preTC1 boot iso from 11 Oct. First boot from CD into grub efi went without a hitch and installation got through just fine. After the first reboot a got a black screen when grub started... Getting grub 0.97 efi to work on a macmini5,1 is still a hit and miss.
The problem I'm having with grub 0.97 booting off the F16beta DVD in EFI mode is that it frequently hangs. Sometimes it hangs at the splash screen before the menu appears (and doesn't ever appear). Or it hangs at some point between grub and linux handoff at the menuless grub splashscreen but before any text as appeared. Frequently the computer just reboots. I get a successful boot about 1 in 4 attempts. And yes, I'm not having this issue with grub2-efi. But as this is unofficially but effectively a proprietary Apple EFI, and officially it's Intel EFI 1.10, in no case is it UEFI 2.x, even fot this year's hardware. Even Microsoft Windows 7 x86_64 supports only UEFI 2.x, not Intel EFI 1.10. This is really Apple's problem to fix, so I don't expect too much effort to solve issues related to Apple's almost totally non-standard EFI implementation. While on the MBP 4,1 2008 I can do a text only boot using EFI (including from a USB stick, which isn't supported by the CSM for booting), on the MBP 8,2 I bought earlier this year I can't even do that in EFI mode. Text is immediately garbled upon transition from grub2-efi to linux and so far I haven't figured a way around it. This sort of regression would be embarrassing for any other company but the reality is Apple sells a particular experience as a product, more so than hardware. And that experience is 99.9% Mac OS, iOS, AppStore, iTunes, and at best 0.1% Windows. Other OS's simply don't register as a factor as far as I can tell.
(In reply to comment #4) > While on the MBP 4,1 2008 I can do a text only boot using EFI (including from a > USB stick, which isn't supported by the CSM for booting), on the MBP 8,2 I > bought earlier this year I can't even do that in EFI mode. Text is immediately > garbled upon transition from grub2-efi to linux and so far I haven't figured a > way around it. In what way is it garbled? Removing "set gfxpayload=keep" (or setting it to auto) will in some cases help with grub2 1.99.
If you imagine a screen of text, and what would happen to that text if you took the upper left corner and lower right corner and "pulled" them apart a football field in length, that's about what the text looks like. It seems stretched out into lines. But is completely unrecognizable. This happens after choosing a menu item from grub. And it happens whether I use grub2-efi or grub legacy efi on that particular hardware model (the 8,2 which is the 2011 15" Macbook Pro). The next time I get a chance I will try manipulating gfxpayload, and report back. But my vague recollection is that it didn't alter the outcome on this particular model.
(In reply to comment #6) I'm sorry for tricking you into getting so off topic here. That display garbling issue sounds like a completely different issue that should be filed separately. A smolt profile and dmesg output would probably be nice if you can find a way to get them. dmesg and X log from BIOS/CSM might also be useful. Please CC me. (I am however quite sure I have seen it work on MBP 8,2 in EFI with nomodeset (note, not any "=0"))
Also bad on my MacBook3,1.
(In reply to comment #7) > (I am however quite sure I have seen it work on MBP 8,2 in EFI with nomodeset > (note, not any "=0")) I have tried F16 on a Macbook Pro 8,2 with nomodeset and the display is garbeled immediately after Grub Legacy or Grub2 menu vanishes and the kenel and initrd are being loaded. Text display is useless as is graphics. There is an Ubuntu guide for the Macbook Pro 8,1 8,2 and 8,3 that apparently discusses some changes to a kernel module and recompiling the kernel to fix this problem but I haven't tried it.
(In reply to comment #9) > I have tried F16 on a Macbook Pro 8,2 with nomodeset and the display is > garbeled immediately after Grub Legacy or Grub2 menu vanishes and the kenel and > initrd are being loaded. That indicates that the reason it worked for me is either because I used grub2-efi or because of xdriver=fbdev. (As in Bug 726159) You could perhaps file a bug report for the failing KMS ... even though it probably will get very low priority because Fedora doesn't have official "support" for EFI Mac and because of lack of Apple documentation.
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.