В Mon, 27 Oct 2014 10:30:31 -0600
Chris Murphy <li...@colorremedies.com> пишет:
>
> On Oct 27, 2014, at 1:39 AM, Andrei Borzenkov <arvidj...@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).
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
