grub-devel
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]