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. 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. Chris Murphy _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel