В Fri, 24 Oct 2014 13:29:01 -0600 Chris Murphy <li...@colorremedies.com> пишет:
> > 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. > The error message on your screenshot does not look like coming from grub2. Also magic it displays is rather amusing bor@opensuse:~/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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
