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: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Mac OS X entries don't work (fail or crash), part 1
Date: Fri, 25 Jan 2013 09:40:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11

On 25.01.2013 07:00, Chris Murphy 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.
> 
> 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?
> 
> 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?
> 
> 3. The Fedora grub2-efi package doesn't install any modules to either 
> location (not to the ESP, not to /boot/grub2). Should it?
> 
> 4. The Fedora installer, doesn't call grub2-install, to cause the modules to 
> be installed anywhere. Should it?
> 

GRUB supports only modules under $prefix/$cpu-$platform which can be on
memdisk. 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. 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.

> 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.
> 
> 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.
> 
> 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? 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?
> 
> Results from grub2-install --debug:
> 
> 
> address@hidden ~]# grub2-install --debug
> + setup_verbose=--verbose
> + efi_quiet=-q
> + '[' -z '' ']'
> + bootdir=/boot
> + '[' -n '' ']'
> ++ echo /boot/grub2
> ++ sed 's,//*,/,g'
> + grubdir=/boot/grub2
> + device_map=/boot/grub2/device.map
> + '[' x86_64-efi = i386-pc ']'
> + '[' x86_64-efi = sparc64-ieee1275 ']'
> + set /usr/bin/grub2-mkimage dummy
> + test -f /usr/bin/grub2-mkimage
> + :
> + '[' xefi = xefi ']'
> + test -n ''
> + test -d /boot/efi
> ++ /usr/sbin/grub2-probe --target=device --device-map= /boot/efi
> + install_device=/dev/sda4
> ++ /usr/sbin/grub2-probe --target=device --device-map= /boot
> + test x/dev/sda4 '!=' x/dev/sda6
> + efidir=/boot/efi
> + 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=
> + test -n ''
> + efidir=/boot/grub2
> + efi_distributor=
> + efi_file=grub.efi
> + mkdir -p /boot/grub2
> + mkdir -p /boot/grub2/x86_64-efi
> + test no = yes
> + test -f /boot/grub2/device.map
> + device_map=
> 
> I have previously fixed the missing modules part of this, but then get a 
> kernel panic when choosing the OS X options. I'll discuss that part after I 
> resolve where everything is supposed to go so I can file an appropriate 
> Fedora bug, and the work around for where things should go in the future.
> 
> 
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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