On Friday, October 24, 2014, Chris Murphy <li...@colorremedies.com> 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. > 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? 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 > Grub-devel@gnu.org <javascript:;> > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel