If that quoted segment is from the same grub.cfg file that successfully launches your 64-bit distributions in EFI mode, then it's booting your 32-bit distribution in EFI mode, too. That said, a cross-bit-size boot like this means you won't have access to your EFI runtime variables in the 32-bit distribution, so for most intents it will work just like a BIOS-mode boot; it's just the technical detail of how the boot loader works that's different from a BIOS-mode boot. The practical upshot of this is that, unless there's something else in GRUB of which I'm unaware, it can't launch a purely BIOS-bootable OS; for instance, it couldn't boot DOS, OS/2, BeOS, or most versions of Windows XP.littlenoodles wrote:Code: Select all
menuentry 'Mageia Cauldron (Cauldron)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-e81f18b2-85f1-44d7-bd71-efef6bab4d22' { insmod part_gpt insmod ext2 set root='hd0,gpt5' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5 e81f18b2-85f1-44d7-bd71-efef6bab4d22 else search --no-floppy --fs-uuid --set=root e81f18b2-85f1-44d7-bd71-efef6bab4d22 fi linux /boot/vmlinuz BOOT_IMAGE=linux root=UUID=e81f18b2-85f1-44d7-bd71-efef6bab4d22 quiet resume=UUID=14ecbfe3-30c9-4a65-8e0b-31ecd1f7c47b vga=788 initrd /boot/initrd.img } submenu 'Advanced options for Mageia Cauldron (Cauldron)' $menuentry_id_option 'osprober-gnulinux-advanced-e81f18b2-85f1-44d7-bd71-efef6bab4d22' { menuentry 'linux (on /dev/sda5)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz--e81f18b2-85f1-44d7-bd71-efef6bab4d22' { insmod part_gpt insmod ext2 set root='hd0,gpt5' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5 e81f18b2-85f1-44d7-bd71-efef6bab4d22 else search --no-floppy --fs-uuid --set=root e81f18b2-85f1-44d7-bd71-efef6bab4d22 fi linux /boot/vmlinuz BOOT_IMAGE=linux root=UUID=e81f18b2-85f1-44d7-bd71-efef6bab4d22 quiet resume=UUID=14ecbfe3-30c9-4a65-8e0b-31ecd1f7c47b vga=788 initrd /boot/initrd.img } etc...
Correct; rEFInd actively scans for boot loaders and presents a list of whatever it finds. The default program and configuration file options cause it to scan for Linux kernels in common kernel locations, so the main obstacles to booting Linux with rEFInd but without using GRUB are filesystem drivers and the fact that some distributions still ship with pre-3.3.0 kernels, which lack the EFI stub loader feature. In your case, rEFInd can't boot the 32-bit distribution's kernels because, even if they have EFI stub loader support, they would be built for the wrong bit depth and so won't run on your 64-bit system; you'll need a separate boot loader to launch them.I thought you had said that I wouldn't need to be specific about the filename. i.e., when Mint decides to issue a new kernel, so the kernel filename changes, rEFInd would still be able to boot it without my having to doctor it's config file up. Or are you saying refind will automatically detect the kernel and present me with an option to boot it directly (maybe it's there if I scroll to the right...)?