PDA

View Full Version : Grub error on Mb Air, dual boot F18+ Lion


warpino
24th January 2013, 01:13 PM
Hi all,

I succesfully installed Fedora 18 (final) on my Macbook Air 4.2.
My partitioning scheme includes an hfs+ partition on /dev/sda4, mounted at /boot/efi and an ext4 root partition / .
I can boot into Fedora without any problem but if I try to boot in Mac Os X choosing "Mac Os X 64 bit on /dev/sda2" in the Grub menu I get the following error:

error: can't find command 'xnu_uuid'
error: can't find command 'xnu_kernel64'
error: can't find command 'xnu_kextdir'

If I want to boot Lion I have to keep the Option key pressed at startup and then choose 'Macintosh HD' as the boot device, which I find a bit annoying.
Can anyone help to solve that?

Thank you in advance !

chrismurphy
24th January 2013, 08:13 PM
It's a bug. I either get those errors, or I get a XNU kernel panic. I'm not sure if upstream is aware of this yet as I haven't filed a GRUB bug yet, or searched for one, or even asked on the list. It should be fixed, but I actually prefer option boot rather than waiting for GRUB to come up.

warpino
24th January 2013, 08:24 PM
It's a bug. I either get those errors, or I get a XNU kernel panic. I'm not sure if upstream is aware of this yet as I haven't filed a GRUB bug yet, or searched for one, or even asked on the list. It should be fixed, but I actually prefer option boot rather than waiting for GRUB to come up.

Thank you very much for your reply chrismurphy. I will check this thread in the next days and see if someone solved it in some way.

:)

chrismurphy
24th January 2013, 08:27 PM
What version of Mac OS X?

warpino
25th January 2013, 01:03 AM
Lion 10.7.5

srs5694
25th January 2013, 04:30 AM
You could replace or supplement GRUB (presumably GRUB 2) with something else. GRUB Legacy (in the F18 packages as grub-efi) and rEFInd (http://www.rodsbooks.com/refind/) are the two that can do the job by themselves, but rEFIt (http://refit.sourceforge.net/) could be used as a first-stage boot manager in conjunction with GRUB to boot Linux (or even without it if you were to jump through some extra hoops), and gummiboot (http://freedesktop.org/wiki/Software/gummiboot) could be made to work with some additional reconfiguration.

If you decide to try rEFInd, I recommend downloading the binary zip file and installing it from OS X. To boot without using GRUB, you'll then need to install the EFI driver for whatever filesystem you use on /boot and run the mkrlconf.sh script from Linux. Installing rEFInd from Linux on a Mac would require using the Linux port of "bless," and the install script doesn't yet know how to do that.

chrismurphy
25th January 2013, 04:15 PM
This is being tracked in bug 903937 (https://bugzilla.redhat.com/show_bug.cgi?id=903937).

The first problem, with the errors reported, is that the necessary GRUB modules are not baked into the grubx64.efi file that's included with Fedora 18. And the prefix baked into the grubx64.efi is pointing to a location that doesn't contain those modules. So when GRUB reads the grub.cfg, and you execute one of the Mac options, the cfg is requesting modules that GRUB can't find because they aren't there. So that's a bug.

The next bug, separate, is that when you run grub2-install, it does install the modules in the usual location in /boot/grub2/x86_64-efi (for BIOS computers they go in /boot/grub2/i386-pc). But the grubx64.efi isn't looking in that location, so it doesn't find them. Further, grub2-install does create a new grubx64.efi which *does* point to the correct location, and tries to put it on /boot/efi/EFI/fedora however because Fedora 18 is using a "new way" of Mac boot support, this is a JHFS+ EFI System partition, not FAT32. So grub2-install fails to install this grubx64.efi which would work.

If you resolve that by unmounting /boot/efi (the anaconda/mactelboot created JHFS+ one), and replacing it with the real ESP (the FAT32 one), grub2-install works completely. The grubx64.efi points to /boot/grub2/x86_64.efi, and it finds the modules it needs. However it doesn't find a grub.cfg because again Fedora puts it in a different location, so you have to create a new one with grub2-mkconfig -o /boot/grub2/grub.cfg which is where the grubx64.efi file is looking for it.

Now that this is resolved, you can reboot and get a GRUB menu. However, this is very fragile. If you zap the PRAM. If you use Startup Disk panel to change the startup disk to OS X, you totally lose the ability to ever rechoose GRUB without using the OS X bless command, which I still haven't figured out how to use correctly because the documentation sucks, and the error messages are obscure.

However, I can nevertheless, before fragility breaks this setup, choose a Mac OS X option. And I get a kernel panic.

So no matter how you look at this, right now it's fundamentally broken. You basically have to use the option key to switch between OS X and Fedora, and not use the OS X options in the GRUB menu.

warpino
26th January 2013, 04:36 PM
So no matter how you look at this, right now it's fundamentally broken. You basically have to use the option key to switch between OS X and Fedora, and not use the OS X options in the GRUB menu.

which is what I think I will be doing as the solutions in your post are surely useful but too complicated for me ;) and also because I already had an headache trying to fix the EFI partition after removing Ubuntu on my MB and ended up reinstalling everything.

Thanks a lot!

chrismurphy
26th January 2013, 07:08 PM
Can you report the result of uname -a on your installation of OS X?

warpino
27th January 2013, 02:30 PM
$ uname -a

Darwin MacBook-Air-of-xxx.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

srs5694
27th January 2013, 06:24 PM
which is what I think I will be doing as the solutions in your post are surely useful but too complicated for me ;) and also because I already had an headache trying to fix the EFI partition after removing Ubuntu on my MB and ended up reinstalling everything.

Please re-read my earlier post in this thread. (http://forums.fedoraforum.org/showpost.php?p=1628842&postcount=6) If GRUB 2 isn't working, there are alternatives!

chrismurphy
28th January 2013, 02:33 AM
Please re-read my earlier post in this thread. (http://forums.fedoraforum.org/showpost.php?p=1628842&postcount=6) If GRUB 2 isn't working, there are alternatives!

Well the GRUB2 part of Fedora mactelboot ends up being annoying but trivial. The nice thing about Fedora mactel boot is that it gets you a nice icon in the Mac EFI boot manager, and also in the OS X System Preferences Startup panel. The missing piece isn't actually the GRUB2 part, I'd rather see that whole menu suppressed and find the OS X options there superfluous. What's missing is a Fedora/GNOME+KDE equivalent to the OS X System Preferences Startup Disk panel to choose the OS you want to boot, before you reboot. This could easily be done with a GUI wrapper for efibootmgr but I don't know of such a thing.

geohas
27th March 2014, 11:13 PM
This Solution worked for me on a MB Pro with Fedora 20.

edit the /etc/grub.d/40_custom

add the following

menuentry "MacOS X Snow Leopard" {
insmod hfsplus
set root=(hd0,gptX) #change X to the Mac partition
chainloader /System/Library/CoreServices/boot.efi
}

update grub.cfg with sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

cantanima
3rd February 2015, 04:53 AM
Fedora really borked grub on my mid-2013 MBP (mid-2012?), though to be fair, grub's auto-configuration seems to be pretty confused itself. I could boot Fedora, but not OSX (unless I held down the alt/option key).
This Solution worked for me on a MB Pro with Fedora 20.

edit the /etc/grub.d/40_custom

add the following

menuentry "MacOS X Snow Leopard" {
insmod hfsplus
set root=(hd0,gptX) #change X to the Mac partition
chainloader /System/Library/CoreServices/boot.efi
}

If anyone else struggles with this, I had to modify the above code as follows:

menuentry "MacOS X Snow Leopard" {
insmod hfsplus
set root=(hd1,gptX) #change X to the Mac partition
chainloader /System/Library/CoreServices/boot.efi
boot
}

Apparently my MBP thinks the hard drive is hd1 instead of hd0. No idea why, but if it helps somebody...

chrismurphy
4th February 2015, 10:14 PM
There's a way to get GRUB to search for its root (the HFS+ ESP in this case) by UUID. On my Mac it flips hd0/hd1 between the SSD and cd/dvd drive in a non-deterministic manner, so I can't use either hd0 or hd1 in the grub.cfg.

Also since posting this, the errors in the first posting are actually expected because apparently the xnu modules in GRUB are meant to only work with a BIOS GRUB. That is, GRUB is installed depending on a Macs CSM/BIOS mode boot (meant for Windows), and these xnu modules allow switching and booting OS X in EFI mode. They don't work with EFI GRUB, and yet they still get created by grub-mkconfig. So the bug is actually in os-prober and grub-mkconfig. There's some effort to just blow this away but it probably won't get done for Fedora 22.

Long term, yes, what's needed is to get grub-mkconfig to create a single OS X boot entry that uses Apple's boot loader. Right now only Apple's bootloader can boot off Core Storage volumes (their version of LVM), which is now being used by default on both encrypted and unencrypted volumes.

Alternatively, and in the meantime, there are two ways to reboot OS X: Hold down the option key at boot chime, and choose the OS X volume. Or in linux use efibootmgr. You can use efibootmgr -v to see the BootOrder and boot list. And then use efibootmgr -n <bootnumber> for the OS you want to boot next one-time only. There's also a way to change the boot order.

Gotcha with the efibootmgr method though, is some Macs have firmware that always defers to boot information in the HFS+ Volume header, and will only fallback to NVRAM boot entries in case of ambiguity with the HFS+ Volume header. I have one Mac that no matter what will always boot Fedora, unless I use the OS X startup disk panel to choose OS X. The NVRAM entries don't change, but it writes something to the OS X volumes HFS+ volume header to indicate that's now the preferred boot volume.

Pretty tedious!

cantanima
6th February 2015, 03:53 AM
There's a way to get GRUB to search for its root (the HFS+ ESP in this case) by UUID. On my Mac it flips hd0/hd1 between the SSD and cd/dvd drive in a non-deterministic manner, so I can't use either hd0 or hd1 in the grub.cfg.What kind of Mac is it?

Alternatively, and in the meantime, there are two ways to reboot OS X: Hold down the option key at boot chime, and choose the OS X volume.I've thought of that as a possibility, but it would be nicer to rely on grub.

Or in linux use efibootmgr. You can use efibootmgr -v to see the BootOrder and boot list. And then use efibootmgr -n <bootnumber> for the OS you want to boot next one-time only. There's also a way to change the boot order.
I'll have to look into this. Again, the Mac you have that doesn't work with this, what kind is it?

Thanks.

chrismurphy
7th February 2015, 09:29 AM
What kind of Mac is it?

MBP 8,2

I've thought of that as a possibility, but it would be nicer to rely on grub.

Well at the moment GRUB upstream doesn't care about this problem enough to fix it. You could edit /etc/default/grub and add GRUB_DISABLE_OS_PROBER=true, then edit /etc/grub.d/40_custom to add an entry for OS X that includes:

set root=(hd1,gpt3)
chainloader (hd1,gpt3)/System/Library/CoreServices/boot.efi

And then run grub2-mkconfig to update the grub.cfg with these changes.