Re: GRUB booting Mac OS X (xnu)

[Andrei Borzenkov]

В Fri, 24 Oct 2014 13:29:01 -0600
Chris Murphy <address@hidden> пишет:

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


The error message on your screenshot does not look like coming from
grub2. Also magic it displays is rather amusing

address@hidden:~/src/grub> echo -e '\x73\x69\x68\x54' 
sihT

Could you test with earlier versions? I usually made recovery CD to
boot, it is fast and can be done from build directory directly, which
makes bisecting easier.