4

I have here a machine which won't boot 64-bit kernels (it has efi32 with a little bit of... uncommon firmware).

Currently, my only way to boot my 64-bit linux system is:

  1. Booting a 32-bit distro from a boot/live cd,
  2. Using kexec to boot my own 64 bit kernel.

Of course I could reinstall a 32-bit distro, but this is not what I want. I want a 32bit kernel/initrd combo, which could work as a bootloader to my real, 64bit kernel/initrd.

It were a minimal initrd system which is capable to load and start my own secondary kernel. Is there any already existing solution for the job?

PersianGulf
  • 10,728
  • 8
  • 51
  • 78
peterh
  • 9,488
  • 16
  • 59
  • 88

2 Answers2

3

A 32-bit grub bootloader will boot a 64-bit Linux image compiled with the CONFIG_EFI_MIXED option using the "linux" and "initrd" commands.

Note that these Grub commands execute EFI's ExitBootServices() prior to starting the kernel. Thus the kernel cannot use secure boot nor can it access the ROMs of PCI slots (most notably the BIOS of the graphics' card).

An alternative is to run the "shim" bootloader and then Grub and use Grub's linuxefi and linuxrdefi commands. These don't run ExitBootServices() but call into a EFI stub in the kernel which copies out ROMs, etc and then calls ExitBootServices() itself before starting the kernel proper. Attempting to run Grub's "linuxefi" command without the shim bootloader results in a "incorrect checksum" error, regardless of the presence or otherwise of secure boot. Unfortunately this approach has two issues: (1) the kernel must be 32-bit and (2) there is currently a bug in the 32-bit EFI stub which prevents the kernel from starting (it hangs with no output).

The bug is notorious. Moreover some 64-bit linux images fail, strongly suggesting some alignment or data-overwriting issue.

The only way forward to get the result you want is to modify the kernel so that it can be started with a 32-bit EFI stub and then transition to the 64-bit kernel proper. It is possible that the author of CONFIG_EFI_MIXED is working on this, perhaps you could email them.

vk5tu
  • 1,389
  • 13
  • 12
1

CONFIG_EFI_MIXED might be what you need.

Michael Shigorin
  • 1,031
  • 7
  • 9
  • Thank you, it seems very-very promising! But this is what I don't understand: "Note that it is not possible to boot a mixed-mode enabled kernel via the EFI boot stub - a bootloader that supports the EFI handover protocol must be used." What the heck is that? – peterh Sep 28 '14 at 15:37
  • I didn't use this myself so far (albeit could run into this shortly); the original announce (https://lkml.org/lkml/2014/3/4/242) does mention "Syslinux, efilinux, Grub" though. – Michael Shigorin Sep 29 '14 at 20:03
  • I am currently on the recompilation of a suse kernel, if it works I will accept your answer! Thank for your help! – peterh Sep 29 '14 at 20:57
  • Did it work? I haven't tested this yet although it looked like an answer to one of my own problems when this code has been added to the kernel (the problem was low-prio and is still unsolved, so I'm still interested). – Michael Shigorin Oct 12 '14 at 15:37
  • I didn't test until now (recompiling a suse kernel isn't the best documented thing), but anyways your answer should be okay, so I can accept that. Thank you very much! – peterh Oct 12 '14 at 15:43
  • Erm, I'm actually more interested in the real result than official acceptance but thank you either :-) So please notify if you remember to. – Michael Shigorin Oct 13 '14 at 15:59
  • :-( It didn't work, I simply got the same boot loader error as before. I googled a lot around that and found, there could be either 32 or 64 bit EFI stub in the kernel, and never both of them. What I can't understand, what the hell this EFI_MIXED is for? (Currently I am constructing a minimal initrd which loads the 64bit kernel with kexec.) – peterh Oct 14 '14 at 11:05
  • Heh, and I didn't even get as far as you have (since another hardware sample with 64-bit firmware available optionally has arrived). What I can't understand is that there seems to be no UEFI-specific mailing list, e.g. shim development communications are reportedly carried out over personal email. – Michael Shigorin Oct 15 '14 at 11:41
  • I think it is because EFI lives mainly in intel macs and on some servers. The first gives the "quality" which the apple ever produced. With the second were probably much fewer problem. Although in this case I were also not happy to the kernel developers, I don't think it were impossible to use some like a multiarch stub. – peterh Oct 16 '14 at 10:01
  • Finally I found a way - I created the kexec-from-initramfs system, but it hanged up. Finally I installed grub (bios grub!) into my linux root partition, and made the refind bootloader to chainload it. So, mac firmare boots refind, refind boots grub-pc, and grub-pc boots my suse kernel. And works like charm! :-) – peterh Nov 01 '14 at 00:01
  • Wow :] It was EDK2 build of refind then, GNU-EFI one doesn't do "legacy" chainloading (I didn't get around to trying the former for ALT Linux yet, might be worth the trouble...) Thanks for sharing, I've (ab)used elilo to ensure that non-signed Linux kernels (and only Linux kernels) boot via shim and signed refind but didn't even consider tricks like this one. – Michael Shigorin Nov 02 '14 at 09:45
  • 1
    My problem was, that my computer has a 64bit cpu, but only a 32bit EFI. And the 32bit EFI simply won't boot a 64bit kernel. The 64bit kernel had been able to get a 32bit EFI stub, but it simply didn't exist in linux, not even with the new kernel compilation flags. But it supported 64bit windowses even if they don't support EFI, thus it had to have some like a "BIOS emulation mode". The firmware bootloader won't see that, but refind could. It was the story. :-) – peterh Nov 02 '14 at 16:00