[Top][All Lists]

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

Re: GRUB booting Mac OS X (xnu)

From: SevenBits
Subject: Re: GRUB booting Mac OS X (xnu)
Date: Fri, 24 Oct 2014 14:50:21 -0400

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...
 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.

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?

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?

Chris Murphy
Grub-devel mailing list

reply via email to

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