Re: Mac OS X entries don't work (fail or crash), part 1

[Andrey Borzenkov]

On Fri, Jan 25, 2013 at 10:00 AM, Chris Murphy <address@hidden> wrote:
>
> Fedora 18, grub2-efi-2.00-13.fc18
>
> When I choose any Mac OS X entry I get:
>
> error: can't find command 'xnu_uuid'
> error: can't find command 'xnu_kernel64'
> error: can't find command 'xnu_kextdir'
>
> Press any key to continue…
>
> I already know how I can fix this, I'm inquiring on what exactly is wrong and 
> how it needs to get fixed in Fedora so it works.
>

How it should be implemented in Fedora is probably better discussed
with Fedora developers. They obviously had some reasons to implement
it this way ...

> 1. The Fedora installed grubx64.efi doesn't have the necessary xnu modules 
> baked into it. Should it? Or is it better for it to depend on finding the 
> modules and loading them on demand?
>

grubx64.efi is what is known as core.img elsewhere. Normally core.img
includes just enough to be able to access ${prefix} directory.

Is grubx64.efi shipped with and installed by RPM or built dynamically?

> 2. The grubx64.efi prefix is looking on the ESP in /EFI/fedora/x86_64-efi for 
> the modules. Is this the correct location for modules on (U)EFI systems?
>

At the end it is up to distribution to decide. grub-install right now
does not support it in this exact form.

> 3. The Fedora grub2-efi package doesn't install any modules to either 
> location (not to the ESP, not to /boot/grub2). Should it?
>

Do you have /boot/grub2-efi? openSUSE 12.2 shipped two packages with
different default ${prefix}.

> 4. The Fedora installer, doesn't call grub2-install, to cause the modules to 
> be installed anywhere. Should it?
>

Ask Fedora :)

> Clearly either the grubx64.efi needs the xnu mod files baked in, OR the 
> modules need to be installed by the grub2 package in a location where 
> grubx64.efi can find them; OR the installer needs to call grub2-install to 
> get them installed to a location where grubx64.efi can find them. I'm just 
> not clear where they are supposed to go on a (U)EFI system.
>

Well ... without secure boot it does not really matter. Having them in
ESP has marginal advantage of having everything in one place, but

- you need framework to manage multiple installations of the same OS.
They obviously cannot all go into the same place
- you cannot easily use software RAID to protect ${prefix}
- you cannot use encrypted partitions

With secure boot using ESP as ${prefix} allows you to ship signed
grubx64.efi and (with current support added to grub) signed modules
and do not modify grubx64.efi to encode ${prefix}. Of course, you
still need to somehow sign grub.cfg which is generated on end system.
Which needs secure way to tell grub to use end user key ... which
probably means putting it somewhere into firmware boot-ony variable.

Without support for signature verification in grub your only option is
to disable module loading in which case it does not matter what prefix
is set to :)

> The grub2-install help description for --boot-directory= says they should go 
> in /boot/grub2, apparently even on (U)EFI systems, not on the ESP. If I use 
> this to direct it to /boot/efi, they still end up in the wrong place because 
> a grub2 folder is created.
>

I think using /EFI/fedora/grub(2)/x86_64-efi in this case would be
better and compatible with current grub-install. After all, there
could be multiple bootladers installed in ESP as well.

> When I run grub2-install by itself, the modules are installed to 
> /boot/grub2/x86_64-efi, but I also get a message:
>
> /boot/efi doesn't look like an EFI partition.
>
> So grub2-install presumably wanted to do something on the ESP? What?

Surprise - install grubx64.efi :)

> I see nothing written.  Is the failure because Fedora is using an HFS+ volume 
> as the EFI System partition, grub2-install then falls back to installing 
> modules into /boot/grub2?
>

Currently grub is always installing modules in /boot/grub (or
${bootdir}/${grubdirname} to be sure). Only core.img a.k.a.
grubx64.efi goes into ESP.


> + test -n /boot/efi
> ++ /usr/sbin/grub2-probe --target=fs --device-map=/boot/grub2/device.map 
> /boot/efi
> + efi_fs=hfsplus
> + test xhfsplus = xfat
> + gettext_printf '%s doesn'\''t look like an EFI partition.\n' /boot/efi
> + gettext_printf_format='%s doesn'\''t look like an EFI partition.\n'
> + shift
> ++ gettext '%s doesn'\''t look like an EFI partition.\n'
> + printf '%s doesn'\''t look like an EFI partition.\n' /boot/efi
> /boot/efi doesn't look like an EFI partition.
> + efidir=

ESP is by definition FAT. Firmware is free to support additional
filesystems but ESP is the only partition that is guaranteed to be
supported by firmware. I do believe that Mac can boot off HFS+ though.