On Oct 24, 2014, at 12:50 PM, SevenBits <sevenbitst...@gmail.com> wrote:
> 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…
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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
