From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XiHhX-0001tK-Ji for mharc-grub-devel@gnu.org; Sun, 26 Oct 2014 02:53:19 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiHhR-0001t4-HL for grub-devel@gnu.org; Sun, 26 Oct 2014 02:53:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiHhM-0003bs-P4 for grub-devel@gnu.org; Sun, 26 Oct 2014 02:53:13 -0400 Received: from mail-la0-x234.google.com ([2a00:1450:4010:c03::234]:56824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiHhM-0003bV-Bz for grub-devel@gnu.org; Sun, 26 Oct 2014 02:53:08 -0400 Received: by mail-la0-f52.google.com with SMTP id hz20so4353507lab.39 for ; Sat, 25 Oct 2014 23:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=2nyklzp+JgQRH0DOVU5WyBrnBr0VaLFOo3t+jfyrRvw=; b=XjdBPrqzXIwfopPR+ClHvpzUklCAaAEEWeVVpEBnsvmqi+c6yt7cO4XBmnqXxYmr2a CTGnpWKdgFbtlH8FvFU0MH859PPKBrBfG2H/FFOaqQyfcoMbfPeaDEunf5Eu3uJO2LGc m4aF+LkOyaj7OMDJEwxBRciLaSg5QAF5EyT1wYFmjErYJx0dEMcZAjrr3InuJDncRRZZ 7OAMAf/QKj70avalFcV9rPh4gD4AQNCqvGHVjXXvQft7d8SHUw8LAe1Oqz0yRcB4zGx8 lnlhHsNsQgM7RMh+HskRh9JFfmQbDRht/qg/790KftwwwlpWWefDIlVHHD8kx0ofrFWP tZqA== X-Received: by 10.112.28.103 with SMTP id a7mr15197153lbh.8.1414306386735; Sat, 25 Oct 2014 23:53:06 -0700 (PDT) Received: from opensuse.site (ppp91-76-139-38.pppoe.mtu-net.ru. [91.76.139.38]) by mx.google.com with ESMTPSA id pd6sm3646807lbb.1.2014.10.25.23.53.05 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Oct 2014 23:53:05 -0700 (PDT) Date: Sun, 26 Oct 2014 09:53:05 +0300 From: Andrei Borzenkov To: Chris Murphy Subject: Re: GRUB booting Mac OS X (xnu) Message-ID: <20141026095305.6a6adea9@opensuse.site> In-Reply-To: References: <23F75FF8-A1AA-4BE0-9CB6-1AC8C7F78CD3@colorremedies.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::234 Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 06:53:18 -0000 =D0=92 Fri, 24 Oct 2014 13:29:01 -0600 Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > On Oct 24, 2014, at 12:50 PM, SevenBits wrote: >=20 > > On Friday, October 24, 2014, Chris Murphy wro= te: > > We need to re-evaluate how GRUB will boot OS X for the following reason= s: > >=20 > > 1. Apple OS X 10.10 (just released) now by default converts for existin= g, and new installs, the partition to use their "LVM-like" technology, call= ed Core Storage. Neither GRUB nor Linux can read this format. > >=20 > > I believe there wasn't more published on this. Why would Apple do this?= It makes resizing disks 10x harder=E2=80=A6 >=20 > Apple doesn't explain much of anything except in glittering generalities.= It's possible they have some future plan as yet unrealized. But the resizi= ng shouldn't be much different, the disktuil command has always done fs res= ize and partition resize in one step. They can do fs resize and LV resize i= n 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 ju= st adds a FAT32 volume where there would have been free space. >=20 >=20 > > =20 > > So the xnu module can't locate xnu to directly boot it, nor do grub-mk= config+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 stopp= er problem; as a majority of OS X users are expected to be using 10.10 by t= he end of the year, if historical upgrade behavior applies. > >=20 > > 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 eit= her, even if the user hasn't upgraded to OS X 10.10 (applies to 10.7 releas= ed 4 years ago, and newer OS versions). > >=20 > > 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). > >=20 > > 4. Since OS X 10.8 there's no longer a 32-bit kernel, so the 32-bit ker= nel boot option is obsolete. > >=20 > > My suggestion is that GRUB chainload the Apple bootloader, which is fou= nd on an unencrypted HFS+ formatted volume, with a unique partition type GU= ID: 426F6F74-0000-11AA-AA11-00306543ECAC (Apple Boot partition), colloquial= ly called "Recovery HD". This used to work with GRUB2 of some version (?) b= ut isn't anymore and I'm not sure why. > > https://savannah.gnu.org/bugs/?42954 > > https://bugzilla.redhat.com/show_bug.cgi?id=3D1128374 > >=20 > > Once the Apple bootloader is chainloaded, it can of course read Core St= orage volumes, encrypted or not, and properly ask for user authentication i= f the volume is encrypted. So it seems like the simplest solution. > >=20 > > Apologies for my ignorance, but isn't how OS X has traditionally been b= ooted with GRUB to begin with? >=20 > Maybe I don't understand the question. For years now, GRUB uses two or th= ree xnu modules to directly bootload xnu, not chainload the Apple bootloade= r. The grub.cfg also contains a lot of script text doing things like checki= ng for a hibernation/sleep image, and maybe some other things. It's a lot m= ore complicated than a linux menu entry. >=20 > >=20 > > I don't see how this will work. My understanding is that the Recovery H= D 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 load= er in this partition just boot the Recovery software, and not the actual OS= X system that the user actually intends to use? >=20 >=20 > Apple's firmware can read HFS+ directly, it cannot read Core Storage volu= mes. 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 implemen= tation of the main volume as a Core Storage volume would still work this wa= y. Once the kernel+kextcache are running, it of course understands Core Sto= rage and the rest of boot completes normally. >=20 > 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 t= he firmware boot manager UI. >=20 > Like I said, I used to be able to use GRUB to chainload boot.efi on Recov= ery HD, and I'd immediately get a screen to enter the password to unlock th= e encrypted volume. But now I get errors with GRUB 2.02, I haven't done muc= h regression testing to see when this broke; it's also possible something o= n Apple's end changed which broke things. Afterall they do annual releases = these days. >=20 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'=20 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.