Description of problem: I currently have two 64-bit MacBooks with 32-bit EFI implementations. It may be uncommon outside of Macs, but it is technically possible to have a 32-bit EFI implementation on a 64-bit computer, so it should be taken into consideration. Right now the only way to get /usr/lib/grub2-efi/i386-efi is to install grub2-efi.i686, which is not in the x86_64 repos. There are also several files which conflict between grub2-efi.x86_64 and grub2-efi.i686. Because it is possible to have a 32-bit EFI on a 64-bit computer I should be able to create a 32-bit image on 64-bit computer. My idea for (re)packaging everything so that this is possible are that: 1.) /usr/lib/grub2-efi/{i386-efi,x86_64} should be packaged in grub2-efi-libs.{i686,x86_64} packages, so that the i686 version can be made available in the x86_64 repos. 2.) Both the grub2-efi.i686 and grub2-efi.x86_64 packages own /boot/efi/EFI/redhat/grub.efi, but from my understanding a 64-bit EFI can not and will not try to boot a 32-bit image, and a 32-bit EFI can not and will not try to boot a 64-bit image, so if my understanding is correct, it makes more sense to have grubia32.efi and grubx64.efi as appropriate. I have done this on boot media, such as a thumb drive for installation for instance and it works fine on both 64-bit and 32-bit EFI systems. 3.) Both the grub2-efi.i686 and grub2-efi.x86_64 packages own /boot/efi/EFI/redhat/grub.cfg which also makes them conflict. So maybe grub2-efi-cfg.noarch with this and other configuration files in /etc/grub.d? Whether a 32-bit or 64-bit EFI it seems that the there is not reason for a separate grub.cfg to exist. 4.) Finally it looks like both the grub2-efi.i686 and grub2-efi.x86_64 packages try to install the docs in /usr/share/doc/grub2-efi-199, which again makes them conflict. So, maybe a grub2-efi-docs.noarch. Maybe this and the step above could be merged to just grub2-efi-common.noarch? The only issue left that I see if everything here were done is that grub.efi (or grubia{32,x64}.efi if my idea make sense) would still be in an i686 package that conflict with the x86_64 package because they provide all the scripts/binaries for grub. So maybe these can be created after the installation of the appropriate packages if necessary, bundled with the lib or common packages, or maybe they would also have to be split out. I don't know what makes the most sense in this case. There certainly seem to be ways around it, even if they aren't 100% the best; certainly better than the current scenario though. And finally, by copying off /usr/lib/grub2-efi/1386-efi, removing the package, installing grub2-efi.x86_64, and restoring /usr/lib/grub2-efi/1386-efi it seems it is fine to run something like: grub2-mkimage -d /usr/lib/grub2-efi/i386-efi -o BOOTIA32.efi -O i386-efi \ --prefix /efi/boot part_gpt part_msdos lvm fat ext2 chain boot configfile \ normal minicmd linux reboot halt search gfxterm gfxmenu efi_gop efi_uga \ video loadbios gzio video_bochs video_cirrus echo true loadenv and get a good functioning 32-bit EFI image using the x86_64 package/binaries/scripts. Anaconda would also need to intelligently determine if the system is using a 32 or 64-bit EFI implementation and install the proper packages (or blindly install both, I suppose that is an option as well), but that is kind of a separate issue from the packaging. Version-Release number of selected component (if applicable): grub2-efi-1.99-9.fc16.{x86_64,i686} How reproducible: Always Steps to Reproduce: 1. Find a 64-bit computer and 32-bit EFI (for example Macbook 2,1, Macbook Pro 2,2) 2. Install Fedora and get it EFI booting. 3. Notice that you need to go out of your way to install grub2-efi.i686 so that you can create an image for your system Actual results: You need to go get grub2-efi.i686 on your own from Koji, or the Fedora 16 i686 repos, etc, which should not be the case. You also then run into dependency problems when a new grub2-efi.x86_64 package becomes available and you have to go and manually seem the i686 update to resolve the issue, which is definitely also not user friendly. Expected results: I should be able to get a 32-bit EFI image without downloading the package separately and worrying about dependency problems when updating my system. Additional info:
As far as I know some fragments of a full answer to this request is: 32-bit EFI requires the CPU to be in 32-bit mode when calling into EFI, and 64-bit EFI requires the CPU to be in 64-bit mode. When the "wrong" kernel is used it might be able to boot, but it can't make any EFI calls and will thus only have limited and incorrect detection of hardware. That is not going to work well and is not supported. (You can try to attach a dmesg from a 64-bit kernel on the 32-bit EFI - I think it will confirm that.) So Apple decided to create machines with 64-bit capable CPUs but designed them in such a way that they can't run in full 64-bit mode. They use their own variant of EFI 1.1 which is 32-bit. These crippled machines can also not run OS/X in 64-bit mode. You say that these machines and running 64-bit kernels on 32-bit EFI is possible and should be taken into consideration. I think the pragmatic answer is that no, it is not possible, and no, that is not going to happen. (IIRC Apple did the opposite and used some tricks to be able to continue running 32-bit OS/X on 64-bit UEFI until it had stabilized enough ... but that is a different story.) It is generally recommended to run 64-bit OS and hardware that is capable of doing that, but this crippled hardware is not capable of doing that ... and there wouldn't be much benefit from running 64-bit on this relatively old and small hardware. I do however see some benefits from some parts of the proposal. I have a "need" for building live images that can boot both 32- and 64-bit EFI systems, and I thus need to build in a 64-bit system with grub2-efi.x86_64 and also have /usr/lib/grub2-efi/i386-efi/ available. Another workaround for my need would be to run 32-bit user-space on 64-bit EFI and 64-bit kernel. That do however for other reasons not really work.
Created attachment 533135 [details] dmesg output from macbook 2,1
From a Macbook 2,1 Booting from OS X install media and running 'ioreg -l -p IODeviceTree | grep firmware-abi' returns '| | "firmware-abi" = <"EFI32">' That same sytem: uname -a Linux macbook 3.1.0-5.fc16.x86_64 #1 SMP Thu Oct 27 03:46:50 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux dmesg output is attached. I don't really consider a Core 2 Duo with 3GB of RAM all that old/small/underpowered; especially compared to some of the netbooks people are toting around today. They were sold into late 2007; it's not a ten year old computer. It certainly runs Fedora 16 very well despite your saying that, 'no, it is not possible'. I have working graphics, ethernet, audio, webcam, bluetooth, wireless, etc. without issue.
(In reply to comment #2) > Created attachment 533135 [details] > dmesg output from macbook 2,1 That shows that you don't use EFI at all. I assume you would see exactly the same dmesg (possibly with even better hardware support) if you booted in BIOS / "Boot Camp" mode. I can only quote https://bugzilla.redhat.com/show_bug.cgi?id=728198#c4 - even though it seems like CPU detection works for you.
Trying to tie together all the macbook boot problems. Unable to boot Fedora 15 Live iso image from grub2 (iso-scan/filename kernel parameter) Bug 723801 Make installation more Mac friendly Bug 746434 RV530 KMS fails on MacBookPro2,1 EFI Bug 735860
The kernel has no support for calling 32-bit firmware from a 64-bit kernel at present, so grub is the least of the difficulties here.
With the packaging scheme used in future grub2 packages it is possible to install x86 efi and x86_64 efi subpackages at the same time and use a parameter to grub2-install to specify which one to use.
As per comment #6, this isn't something we ever intend on supporting. I'm sorry your hardware vendor did this.