All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: GRUB booting Mac OS X (xnu)
Date: Mon, 27 Oct 2014 21:01:46 +0300	[thread overview]
Message-ID: <20141027210146.04df5e4d@opensuse.site> (raw)
In-Reply-To: <E0B6F436-7DFE-4659-9E8D-345D8D65386C@colorremedies.com>

В Mon, 27 Oct 2014 10:30:31 -0600
Chris Murphy <lists@colorremedies.com> пишет:

> 
> On Oct 27, 2014, at 1:39 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 
> 
> 
> > It does not look like anything needs to
> > be changed in grub2 though. You will need to modify os-prober to
> > return efi loader type in this case; grub2 already supports
> > chainloading EFI binary in 30_os-prober.
> 
> 30_os-prober creates this entry for EFI systems:
>  284		  chainloader /EFI/${DEVICE}
> 

No, it does not. It creates

      prepare_grub_to_access_device ${DEVICE} | sed -e "s/^/\t/"

      cat <<EOF
        chainloader ${EFIPATH}


where DEVICE and EFIPATH are whatever is returned by os-prober.

> This won't work on Macs, because the OS X bootloader isn't a.) on the ESP and b.) isn't in an \EFI directory.
> 

Fine. So write or extend os-prober script that returns correct path.

> So it looks like os-prober needs to look for the Apple Boot partitiontypeGUID, pass that device to 30_os-prober which can then do:
> 		chainloader /System/Library/CoreServices/boot.efi
> 
> Currently 30_os-prober lines 44 to 103 appear obsolete and should be removed. That's what creates the OS X entries right now using the various xnu modules.
> 
> 
> > 
> > You still need to keep current xnu loader (and macosx os-prober type)
> > for the case of CSM boot though.
> 
> What's the use case for this?

If you do not use it does not mean nobody is using it. It still works
just fine if you want it.

> Something like linux BIOS installation with i386 version of GRUB, and
 it uses the xnu modules to EFI boot OS X? OK, but that's still broken
 today 

No, it is not. Please test it.

> and going forward because neither GRUB nor linux can read Core
 Storage, which is where the xnu kernel and its initramfs are found.
 And anyone using any version of OS X for the past three years with
 full disk encryption likewise can't use GRUB xnu modules to EFI boot
 OS X from CSM mode either. This seems like a very legacy use case.
> 
> If it's possible to have an i386 30_os-prober that keeps the current osx xnu module boot entries intact; but on x86_64 the 30_os-prober makes the grub.cfg with chainloader, then I'm fine with that.
> 
> > 
> >> The Apple Boot [1] is used by OS X 10.7 through 10.10, so it's a good start point to search for OS X since it won't be anywhere else.
> >> 
> > 
> > give grub device name; it is file system and has UUID right? So it is
> > going to find it during boot just fine.
> 
> Yes, I mean for grub-mkconfig to create the entry via os-prober it's going to need to know to only look for OS X's bootloader that has the Apple Boot partitiontype GUID because it's not going to find it anywhere else. And if it does, it's not really an OS X bootloader, it's likely a renamed grubx64.efi masquerading as an OS X bootloader, so that the built-in firmware boot manager displays it as a boot option at start up time (which it doesn't do if the EFI binary is on the EFI System partition).


  reply	other threads:[~2014-10-27 18:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 15:20 GRUB booting Mac OS X (xnu) Chris Murphy
2014-10-24 18:50 ` SevenBits
2014-10-24 19:29   ` Chris Murphy
2014-10-26  6:53     ` Andrei Borzenkov
2014-10-26 21:49       ` Chris Murphy
2014-10-27  4:06         ` Chris Murphy
2014-10-27  4:15           ` Chris Murphy
2014-10-27  7:39           ` Andrei Borzenkov
2014-10-27 16:30             ` Chris Murphy
2014-10-27 18:01               ` Andrei Borzenkov [this message]
2014-10-27 19:05                 ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141027210146.04df5e4d@opensuse.site \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    --cc=lists@colorremedies.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.