I've been trying to get rEFInd to detect and boot a 32bit Ubuntu kernel on 64bit hardware (from an external USB hard drive attached to a Apple Mac Mini). I've succeeded doing exactly this with a 64bit kernel.
I've set up refind_linux.conf (which is at the root of the hfs+ "boot" partition and other rEFInd files (which are in System/Library/CoreServices in the "boot" partition) according to instructions for using Linux' efi stub loader capability. I've blessed the bootx64.efi file, so rEFInd can be chosen after holding the option key during bootup.
I should mention that the rEFInd choice that appears for this 32bit kernel is the one specified in a manual stanza in the refind.conf file. Even though I've enabled scan_all_linux_kernels and properly set up refind_linux.conf, those choices don't show up.
After the rEFInd menu appears and I click on the selection for the 32bit kernel, action stops with an error:
Invalid loader file!
Error: Not Found while loading vmlinuz-3.8.0-30-generic
Any ideas? Super Grub 2 doesn't seem to have a problem booting up this 32bit kernel on my 64bit hardware.
Take care,
dgktkr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EFI runs binaries for a single architecture. That is, an IA-32 (32-bit x86) EFI will run only IA-32 binaries, an X64 (64-bit x86-64) EFI will run only X64 binaries, and so on.
The EFI stub loader in the Linux kernel is a binary of the same type as the kernel itself -- a 32-bit kernel has an IA-32 EFI stub loader, a 64-bit kernel has an X64 EFI stub kernel, and so on. Thus, it's impossible to run a 32-bit kernel on a 64-bit EFI when using the EFI stub loader.
GRUB 2 works because it's not using the EFI stub loader; it's loading the kernel in other ways that don't rely on the EFI stub loader. For your purposes, it's best to either stick to a 64-bit kernel on your 64-bit EFI or use GRUB 2 or some other boot loader rather than use the EFI stub loader.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the quick reply. It makes clear that I'd be wasting my time trying to get a 32bit kernel booted on my 64bit hardware with the EFI stub loader.
dgktkr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Something similar to the above but the reverse: 32 bit EFI implementation and 64 bit kernel:
I have a Core2 Duo Macbook that only has a 32 bit implementation of EFI. (I'm trying to set it up for my daughter to use - Linux Mint, it will be Linux only). Currently, the new SSD disk has a GPT partition table. I have managed to install rEFInd on the ESP from OS X running in an external enclosure. rEFInd supports booting the 64bit Mint installer ISO from a memory stick (this FAT32 formatted memory stick uses "ISO-2-USB EFI-Booter for Mac" to boot the ISO image), and can install the OS but not GRUB. I have tried following the rEFInd instructions to copy /boot and the kernel files to the ESP partition (FAT32), but these kernels are not presented as bootable options by rEFInd which, even though it is set to scan it isn't picking them up (note too that the rEFInd 32 bit ext4 driver is installed too). Is that because they are 64 bit kernels and I am having to run a 32 bit rEFInd? rEFInd is not showing any boot options for the SSD. If I somehow manage to install a 32 bit EFI GRUB, perhaps by retrying with a 32 bit mint installer, will rEFInd automatically detect it? Must the OS be 32 bit - if I recall correctly this machine did run a 64 bit OS X?
Many thanks for rEFInd - it is wonderful technology!
-Jonathan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recently picked up a intel Mac-Mini with a 32-bit BIOS and a 64-bit CPU, and the only Linux distro that I could find that addressed my situation (in current releases) was Debian.
Debian 8/"Jessie" has a "mac" installer ISO that installed an EFI GRUB on my Mac Mini, and a 32-bit install, with no problem. It boots into GRUB without a delay when I power it on.
After you have a working GRUB, I expect it would be easier (or maybe just more possible) to install a 64-bit distro without modifying the bootloader (and then reconfigure GRUB separately), than it would be to install a distro and bootloader off the same installer.
Also, with Debian's "multi-arch", I think you may be able to simply switch the kernel on your 32-bit install to a 64-bit kernel, and run the 32-bit apps under the 64-bit kernel, and later "upgrade" the install (or even just some of the apps) to 64-bit versions.
Aside from Debian, I seem to remember that Ubuntu had a section on their support forum for intel-mac users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Use the EFI stub loader with a 32-bit distribution -- If you install a 32-bit distribution, your 32-bit rEFInd and EFI should be able to launch the kernel. (This depends on the distribution including the EFI stub loader in its 32-bit kernels, which Ubuntu does, so Mint should as well.) Note that the 32-bit distribution will install in BIOS mode and may try to install a BIOS-mode GRUB, so the following option at least partially applies.
Use a BIOS-mode GRUB with your 64-bit distribution -- If you install the distribution in BIOS mode, it should install a BIOS-mode GRUB. Note, however, that to do this on a GPT disk, the installer may insist on a BIOS Boot Partition being present on the disk, so you may need to create such a partition. Once this is set up, rEFInd should detect the BIOS-mode GRUB and launch it, which in turn should launch Linux in 64-bit mode.
Use a 32-bit EFI-mode GRUB with your 64-bit distribution -- This combination should work, but I've not tested it myself. You'll have to jump through some significant hoops to get the 32-bit GRUB installed, though. There may be a guide somewhere on how to do it, but I don't know where. I've never done this before myself, and it's a significant enough task to undertake that I can't give you step-by-step instructions.
Upgrade your firmware -- I've heard of procedures to install 64-bit EFIs on at least some Mac models that have 64-bit CPUs and 32-bit EFIs. I've never looked into these procedures in any detail, though, so I don't know if they support all such models or just a few. This procedure is also likely to be at least a little bit risky, since a mistake could render the Mac completely useless until it's serviced by a professional. If successful, it would be possible for a 64-bit rEFInd to launch a 64-bit Linux kernel on the system. I don't have pointers to detailed instructions on how to do this, but a Web search should turn something up. If I'm not mistaken, these procedures enable you to run more recent versions of OS X on the hardware than is officially supported, which may be a "plus" to this option.
Overall, the first two options are likely to be the easiest and safest to pull off. The third option is safe, but will require more hoop-jumping than the first two options. The fourth may be worth investigating if you're willing to take a chance but want the greatest flexibility moving forward.
There are other solutions, too, but the ones that occur to me are very "fringe," which is why I haven't mentioned them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Rod: Thanks for the lengthy and detailed response with all the posssible options. I got it to work through option three - 32-bit EFI-mode GRUB with the installed 64-bit distribution. As the grub-efi-ia32 package wouldn't install, I ended up compiling GRUB in a chroot within the Mint live environment (and ran ./configure with --target=i386 ). Whilst the process did involve apt installing many packages to do the build, it wasn't especially difficult (maybe setting up the chroot would challenge beginners but I'm not even sure that it was necessary). I'll post full details here of how I did it in a couple of days to provide a reference for others.
There are still some things I would like to know though:
BIOS booting - I was under the impression that I needed an MBR-partitioned hard-disk to perform BIOS booting, I didn't know that a (GPT) BIOS boot partition would do it. The hybrid MBR page has also confused me on this matter. So, if I had wanted to use option two, it wasn't clear how I would go about 'installing the distribution in BIOS mode'. Would it have been enough to have used any 32 bit distribution installer that had a partitioner that somehow (?) knew/insisted on the creation of a BIOS boot partition, or would I have had to first create a hybrid MBR, or would the presence of an existing BIOS boot partition told the distribution to use 'BIOS mode'?
There is information out there that a 64 bit kernel could have issues talking to 32 bit firmware, e.g. "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." -Matthew Garrett 2012-04-28 13:46:48 EDT. Is this still true? Do you know of such issues? Since my machine does indeed fully boot into the desktop (so it can read the system memory map), the only 'EFI' things that I can think might require testing by me would be efibootmgr, and maybe graphics card initialization?
I can set fstab to mount the (FAT) ESP under /boot to make grub-update automatically update "grub.cfg" there rather than on my ext4 /boot partition. Of course this means that on the ESP, grub will have to go in /grub rather than the existing /efi/grub, so hopefully this will not be a problem for rEFInd. Is there a better way to make it work automatically, like make grub use a grub.cfg on the ext4 /boot partition? I'm assuming that there is really a limitation that grub.efi must be in the same folder as grub.cfg?
@Brian: If I had known about the Debian Mac .iso, I might have considered doing things differently. However, I'm trying to get my teenage daughter to like Linux more. Although she's been using my Debian/Ubuntu machines since the age of five, at the moment she doesn't think it is as cool as mom's Windows, so I'm playing a pragmatic long term game and am trying to make her see the error of her ways via some Linux bling!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On most PCs, it's possible to boot in BIOS mode from GPT disks. On Macs, this is possible, but you need some way to activate the Compatibility Support Module (CSM), and the easiest and most commonly-applicable way to do this is to have either an MBR hard disk or a GPT disk with a hybrid MBR. (It can also be done by the presence of a BIOS-bootable CD, and perhaps by BIOS-bootable USB drives, but I've not really explored such possibilities in detail.) Your question touches on the very complex topic of controlling the boot mode (BIOS vs. EFI). I can't cover that all here. My page on CSMs may be a helpful starting point -- but as with so many things, Apple has their own twist on it. I don't have a URL to any guide that really covers this adequately for Macs; but start with my CSM page and know that the presence of an MBR (or hybrid MBR) activates a Mac's CSM will get you most of the way there.
Your Matthew Garrett quote is from over three years ago. I believe that the Linux kernel now does a better job of cross-bit-depth communication with the EFI, but I haven't been following the details very closely. You can look for a directory called /sys/firmware/efi. If it's present, you've booted in EFI mode and should be able to talk to the EFI from Linux; if it's absent, you've either booted in BIOS mode or you've booted in EFI mode but without the EFI-communication facilities working. If your system is working, I wouldn't worry too much about this detail, but efibootmgr relies on EFI communications, as you seem to understand.
The conventional place to mount the ESP in most distributions is /boot/efi, so that's where I recommend you mount it unless you have a specific reason to do otherwise. Some people mount the ESP at /boot, though. This is particularly common with Arch Linux. This placement makes it easy to store your kernel on the ESP, which is helpful if you're using gummiboot/systemd-boot (or if you want to use rEFInd without any filesystem drivers). How any of this will interact with your self-built GRUB depends on how it was compiled, and in particular where it looks for configuration files. Dealing with such headaches was one of the motivations for my forking rEFIt to rEFInd, so I hope you'll forgive that I'm unable to offer much assistance on that point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've been trying to get rEFInd to detect and boot a 32bit Ubuntu kernel on 64bit hardware (from an external USB hard drive attached to a Apple Mac Mini). I've succeeded doing exactly this with a 64bit kernel.
I've set up refind_linux.conf (which is at the root of the hfs+ "boot" partition and other rEFInd files (which are in System/Library/CoreServices in the "boot" partition) according to instructions for using Linux' efi stub loader capability. I've blessed the bootx64.efi file, so rEFInd can be chosen after holding the option key during bootup.
I should mention that the rEFInd choice that appears for this 32bit kernel is the one specified in a manual stanza in the refind.conf file. Even though I've enabled scan_all_linux_kernels and properly set up refind_linux.conf, those choices don't show up.
After the rEFInd menu appears and I click on the selection for the 32bit kernel, action stops with an error:
Any ideas? Super Grub 2 doesn't seem to have a problem booting up this 32bit kernel on my 64bit hardware.
Take care,
dgktkr
EFI runs binaries for a single architecture. That is, an IA-32 (32-bit x86) EFI will run only IA-32 binaries, an X64 (64-bit x86-64) EFI will run only X64 binaries, and so on.
The EFI stub loader in the Linux kernel is a binary of the same type as the kernel itself -- a 32-bit kernel has an IA-32 EFI stub loader, a 64-bit kernel has an X64 EFI stub kernel, and so on. Thus, it's impossible to run a 32-bit kernel on a 64-bit EFI when using the EFI stub loader.
GRUB 2 works because it's not using the EFI stub loader; it's loading the kernel in other ways that don't rely on the EFI stub loader. For your purposes, it's best to either stick to a 64-bit kernel on your 64-bit EFI or use GRUB 2 or some other boot loader rather than use the EFI stub loader.
Hi Rod,
Thanks for the quick reply. It makes clear that I'd be wasting my time trying to get a 32bit kernel booted on my 64bit hardware with the EFI stub loader.
dgktkr
Hi Rod,
Something similar to the above but the reverse: 32 bit EFI implementation and 64 bit kernel:
I have a Core2 Duo Macbook that only has a 32 bit implementation of EFI. (I'm trying to set it up for my daughter to use - Linux Mint, it will be Linux only). Currently, the new SSD disk has a GPT partition table. I have managed to install rEFInd on the ESP from OS X running in an external enclosure. rEFInd supports booting the 64bit Mint installer ISO from a memory stick (this FAT32 formatted memory stick uses "ISO-2-USB EFI-Booter for Mac" to boot the ISO image), and can install the OS but not GRUB. I have tried following the rEFInd instructions to copy /boot and the kernel files to the ESP partition (FAT32), but these kernels are not presented as bootable options by rEFInd which, even though it is set to scan it isn't picking them up (note too that the rEFInd 32 bit ext4 driver is installed too). Is that because they are 64 bit kernels and I am having to run a 32 bit rEFInd? rEFInd is not showing any boot options for the SSD. If I somehow manage to install a 32 bit EFI GRUB, perhaps by retrying with a 32 bit mint installer, will rEFInd automatically detect it? Must the OS be 32 bit - if I recall correctly this machine did run a 64 bit OS X?
Many thanks for rEFInd - it is wonderful technology!
-Jonathan
I recently picked up a intel Mac-Mini with a 32-bit BIOS and a 64-bit CPU, and the only Linux distro that I could find that addressed my situation (in current releases) was Debian.
Debian 8/"Jessie" has a "mac" installer ISO that installed an EFI GRUB on my Mac Mini, and a 32-bit install, with no problem. It boots into GRUB without a delay when I power it on.
After you have a working GRUB, I expect it would be easier (or maybe just more possible) to install a 64-bit distro without modifying the bootloader (and then reconfigure GRUB separately), than it would be to install a distro and bootloader off the same installer.
Also, with Debian's "multi-arch", I think you may be able to simply switch the kernel on your 32-bit install to a 64-bit kernel, and run the 32-bit apps under the 64-bit kernel, and later "upgrade" the install (or even just some of the apps) to 64-bit versions.
Aside from Debian, I seem to remember that Ubuntu had a section on their support forum for intel-mac users.
Jonathan,
Broadly speaking, you have four options:
Overall, the first two options are likely to be the easiest and safest to pull off. The third option is safe, but will require more hoop-jumping than the first two options. The fourth may be worth investigating if you're willing to take a chance but want the greatest flexibility moving forward.
There are other solutions, too, but the ones that occur to me are very "fringe," which is why I haven't mentioned them.
Hi
@Rod: Thanks for the lengthy and detailed response with all the posssible options. I got it to work through option three - 32-bit EFI-mode GRUB with the installed 64-bit distribution. As the grub-efi-ia32 package wouldn't install, I ended up compiling GRUB in a chroot within the Mint live environment (and ran ./configure with --target=i386 ). Whilst the process did involve apt installing many packages to do the build, it wasn't especially difficult (maybe setting up the chroot would challenge beginners but I'm not even sure that it was necessary). I'll post full details here of how I did it in a couple of days to provide a reference for others.
There are still some things I would like to know though:
BIOS booting - I was under the impression that I needed an MBR-partitioned hard-disk to perform BIOS booting, I didn't know that a (GPT) BIOS boot partition would do it. The hybrid MBR page has also confused me on this matter. So, if I had wanted to use option two, it wasn't clear how I would go about 'installing the distribution in BIOS mode'. Would it have been enough to have used any 32 bit distribution installer that had a partitioner that somehow (?) knew/insisted on the creation of a BIOS boot partition, or would I have had to first create a hybrid MBR, or would the presence of an existing BIOS boot partition told the distribution to use 'BIOS mode'?
There is information out there that a 64 bit kernel could have issues talking to 32 bit firmware, e.g. "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." -Matthew Garrett 2012-04-28 13:46:48 EDT. Is this still true? Do you know of such issues? Since my machine does indeed fully boot into the desktop (so it can read the system memory map), the only 'EFI' things that I can think might require testing by me would be efibootmgr, and maybe graphics card initialization?
I can set fstab to mount the (FAT) ESP under /boot to make grub-update automatically update "grub.cfg" there rather than on my ext4 /boot partition. Of course this means that on the ESP, grub will have to go in /grub rather than the existing /efi/grub, so hopefully this will not be a problem for rEFInd. Is there a better way to make it work automatically, like make grub use a grub.cfg on the ext4 /boot partition? I'm assuming that there is really a limitation that grub.efi must be in the same folder as grub.cfg?
@Brian: If I had known about the Debian Mac .iso, I might have considered doing things differently. However, I'm trying to get my teenage daughter to like Linux more. Although she's been using my Debian/Ubuntu machines since the age of five, at the moment she doesn't think it is as cool as mom's Windows, so I'm playing a pragmatic long term game and am trying to make her see the error of her ways via some Linux bling!
Jonathan,
In response to your questions:
/sys/firmware/efi. If it's present, you've booted in EFI mode and should be able to talk to the EFI from Linux; if it's absent, you've either booted in BIOS mode or you've booted in EFI mode but without the EFI-communication facilities working. If your system is working, I wouldn't worry too much about this detail, butefibootmgrrelies on EFI communications, as you seem to understand./boot/efi, so that's where I recommend you mount it unless you have a specific reason to do otherwise. Some people mount the ESP at/boot, though. This is particularly common with Arch Linux. This placement makes it easy to store your kernel on the ESP, which is helpful if you're using gummiboot/systemd-boot (or if you want to use rEFInd without any filesystem drivers). How any of this will interact with your self-built GRUB depends on how it was compiled, and in particular where it looks for configuration files. Dealing with such headaches was one of the motivations for my forking rEFIt to rEFInd, so I hope you'll forgive that I'm unable to offer much assistance on that point.