grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB booting Mac OS X (xnu)


From: Chris Murphy
Subject: Re: GRUB booting Mac OS X (xnu)
Date: Fri, 24 Oct 2014 13:29:01 -0600


On Oct 24, 2014, at 12:50 PM, SevenBits <address@hidden> wrote:

On Friday, October 24, 2014, Chris Murphy <address@hidden> wrote:
We need to re-evaluate how GRUB will boot OS X for the following reasons:

1. Apple OS X 10.10 (just released) now by default converts for existing, and new installs, the partition to use their "LVM-like" technology, called Core Storage. Neither GRUB nor Linux can read this format.

I believe there wasn't more published on this. Why would Apple do this? It makes resizing disks 10x harder…

Apple doesn't explain much of anything except in glittering generalities. It's possible they have some future plan as yet unrealized. But the resizing shouldn't be much different, the disktuil command has always done fs resize and partition resize in one step. They can do fs resize and LV resize in one step also. But I don't have 10.10 installed yet so I don't know if it shrinks the PV as well, and leaves some free space or like before if it just adds a FAT32 volume where there would have been free space.


 
 So the xnu module can't locate xnu to directly boot it, nor do grub-mkconfig+os-prober even find that there's an OS X installation available, to know to create boot entries for it. This is probably the biggest show stopper problem; as a majority of OS X users are expected to be using 10.10 by the end of the year, if historical upgrade behavior applies.

2. Increasingly, users are using OS X's full disk encryption (FileVault 2), which likewise uses Core Storage. GRUB xnu modules can't boot this either, even if the user hasn't upgraded to OS X 10.10 (applies to 10.7 released 4 years ago, and newer OS versions).

3. The existing GRUB xnu modules don't support signature verification, so it's a problem for distributions that create a prebaked grubx64.efi that's signed, because potentially arbitrary code can be executed by including the xnu module in the prebaked binary. So distributions aren't doing this, meaning it's not available, and thus xnu based boot entries for OS X fail (and have been failing for a couple years).

4. Since OS X 10.8 there's no longer a 32-bit kernel, so the 32-bit kernel boot option is obsolete.

My suggestion is that GRUB chainload the Apple bootloader, which is found on an unencrypted HFS+ formatted volume, with a unique partition type GUID: 426F6F74-0000-11AA-AA11-00306543ECAC (Apple Boot partition), colloquially called "Recovery HD". This used to work with GRUB2 of some version (?) but isn't anymore and I'm not sure why.
https://savannah.gnu.org/bugs/?42954
https://bugzilla.redhat.com/show_bug.cgi?id=1128374

Once the Apple bootloader is chainloaded, it can of course read Core Storage volumes, encrypted or not, and properly ask for user authentication if the volume is encrypted. So it seems like the simplest solution.

Apologies for my ignorance, but isn't how OS X has traditionally been booted with GRUB to begin with?

Maybe I don't understand the question. For years now, GRUB uses two or three xnu modules to directly bootload xnu, not chainload the Apple bootloader. The grub.cfg also contains a lot of script text doing things like checking for a hibernation/sleep image, and maybe some other things. It's a lot more complicated than a linux menu entry.


I don't see how this will work. My understanding is that the Recovery HD contains an install of OS X that is specifically designed to recovery the OS X copy on the main user partition. Wouldn't chain loading the boot loader in this partition just boot the Recovery software, and not the actual OS X system that the user actually intends to use?

Apple's firmware can read HFS+ directly, it cannot read Core Storage volumes. So in the case of encrypted installations, the firmware loads /System/Library/CoreServices/boot.efi from the Recovery HD partition and presumably the unencrypted kernel and kextcache (initramfs). Any unencrypted implementation of the main volume as a Core Storage volume would still work this way. Once the kernel+kextcache are running, it of course understands Core Storage and the rest of boot completes normally.

To boot recovery mode requires an additional flag. Typically this is done by the user with command-r or explicitly choosing Recovery HD icon from  the firmware boot manager UI.

Like I said, I used to be able to use GRUB to chainload boot.efi on Recovery HD, and I'd immediately get a screen to enter the password to unlock the encrypted volume. But now I get errors with GRUB 2.02, I haven't done much regression testing to see when this broke; it's also possible something on Apple's end changed which broke things. Afterall they do annual releases these days.


Chris Murphy

reply via email to

[Prev in Thread] Current Thread [Next in Thread]