[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mac OS X entries don't work (fail or crash), part 1
From: |
Chris Murphy |
Subject: |
Re: Mac OS X entries don't work (fail or crash), part 1 |
Date: |
Fri, 25 Jan 2013 10:37:43 -0700 |
On Jan 25, 2013, at 1:40 AM, Vladimir 'φ-coder/phcoder' Serbinenko
<address@hidden> wrote:
>
> GRUB supports only modules under $prefix/$cpu-$platform which can be on
> memdisk.
I do not understand $prefix. I do understand $cpu-platform. I don't understand
memdisk.
If the grubx64.efi prefix points to the actual location where modules are
stored, is this supported?
> It seems that some people start shuffling it around using
> custom stuff. It's not supported by upstream and if it fails like in
> your case we don't care.
I'm not asking for upstream support. I'm asking to understand design and
intent, so I can properly communicate the bug to Fedora, and to users so the
problem can be fixed. Not just for me.
I totally understand that a grubx64.efi that doesn't contain the modules called
for in grub.cfg, and points to ESP//EFI/fedora, which doesn't contain an
x86_64-efi folder containing GRUB modules, isn't going to work. And I know how
to fix this for myself, but just because I can get it to work for me, doesn't
mean that's the recommended best practice downstream.
So, should the modules be stored on the ESP? Or should they be installed in
/boot/grub, just as with BIOS computers? Or does it not matter?
> Unless you use one of official ways
> (grub-install, grub-mknetdir, grub-mkrescue or grub-mkstandalone) you
> have an unsupported config which may fail in a number of ways but it's
> not my problem. Using unofficial install way = no support. I haven't
> seen any valid reason to use any other install (except when preparing
> coreboot or loongson ROM image). If there are valid reasons a
> corresponding install tool can be added (like it was the case of
> grub-mknetdir).
> Use grub-install to reinstall properly.
My understanding is they do this because grubx64.efi is signed, so they include
one prebaked and signed grubx64.efi for everyone. But it appears to be using an
improper prefix to search for additional GRUB modules, thus even if they were
installed, they wouldn't be found. So that may be the Fedora bug? I've filed it
here:
https://bugzilla.redhat.com/show_bug.cgi?id=903937
But even if we aren't talking about Fedora custom stuff, there is a problem for
Macs and grub-install. The problem is that for Macs the grub-install result is
not persistent. The grubx64.efi is not found by the Mac EFI boot manager, or
the OS X Startup Disk panel. Once the user clears NVRAM, or chooses to boot OS
X from the Startup Disk panel, it's no longer possible to find and thus load
grubx64.efi.
For this to work persistently on Macs, the grubx64.efi needs to be installed on
a JHFS+ volume which contains:
1. a dummy mach_kernel file
2. the grubx64.efi needs to be installed to
/System/Library/CoreServices/boot.efi
3. a SystemVersion.plist file in the same location as the boot.efi, with at
least a ProductName field, so that the boot option has a recognizable name.
So basically, if you want to support booting on Macs, then there are special
requirements because they aren't exactly doing things strictly the UEFI way.
Further, grub-install doesn't like JHFS+ ESPs, and refuses to install a
grubx64.efi file if the ESP is not FAT32. I just tried replacing the JHFS+ ESP
with a FAT32 ESP, and I no longer get the error, and a new grubx64.efi is
installed, whereas with a JHFS+ ESP this is not the case.
So across the board, this isn't working for EFI Macs out of the box.
Chris Murphy