How to create arbitrary UEFI boot stubs?

Question

I installed TinyCore as my maintenance OS. I gave that GRUB2. But the TinyCore install instructions tell you to add GRUB2 using the MBR method. (It works but that's just because EFI is backward compatible with MBR.) Ideally I'd like to chain it so that the EFI boot stub vectors over to TinyCore's /boot/grub, so that from TinyCore's GRUB2 I can boot any other OS I want. Or second choice, I'd like to chain it so that the EFI boot stub vectors to TinyCore's vmlinuz.

TinyCore does not have efibootmgr. efibootmgr is giving me the "system does not support efivars" when I boot from a Ubuntu USB stick.

Is there a way to just grab TinyCore's grub directory, bring it to some other Linux machine and have that create a grub.efi from it that I can then bring back to this machine and copy to my ESP on this machine?

Answer 1

efibootmgr is giving me the "system does not support efivars" when I boot from a Ubuntu USB stick.

This happens because you're booting from the USB stick using the legacy BIOS style, so UEFI's compatibility support module will disable the UEFI run-time interface that would be used to access the boot variables. If you can boot the USB stick in native UEFI mode, then efibootmgr will work. If the firmware boot settings include a choice whether UEFI or legacy boot methods are tried first, try switching it to "UEFI first" mode while booting from the stick.

With a legacy MBR GRUB2, you can only boot operating systems that are bootable with the legacy MBR style. In order to chain to an operating system that's been installed to boot using native UEFI, you'll need an UEFI version of GRUB2.

The problem in transplanting an UEFI GRUB from one distribution to another is that different distributions set it up in slightly different ways: for example, Debian used to plant a very minimal grub.efi to ESP with embedded instructions to read further GRUB modules and the configuration file from another filesystem specified at the GRUB installation time (typically the filesystem that contains the /boot directory).

The problem with this approach is that Secure Boot makes this impossible if enabled: all executable code loaded must be signed, and since GRUB modules are not using the same binary file format as the standard UEFI binaries, they cannot be signed in a way that would be recognizable as such for the UEFI firmware.

RedHat-derived distributions, on the other hand, tend to embed all the necessary GRUB modules into the main grubx64.efi binary, which can then be successfully loaded in one operation by the Secure Boot shim.efi. The GRUB configuration file is also placed in the ESP filesystem, typically reflecting the naming of the main UEFI GRUB binary, i.e. if the binary is renamed to foo.efi it will look for foo.cfg in the same directory.

Knowing this, you could just make sure Secure Boot is disabled, grab the grub.efi binary from a RedHat/CentOS/Fedora installation media, write it a minimal configuration file manually, place them into your ESP (perhaps as \EFI\boot\bootx64.efi and \EFI\boot\bootx64.cfg, so UEFI should pick them up automatically with no need of UEFI variables) and boot once. Then you could see if the GRUB configuration file generated by TinyCore's native GRUB configuration generator is compatible with that version of GRUB, and either replace the simplified configuration file with a real one, or replace the transplanted version of GRUB with TinyCore's preferred version of UEFI GRUB.

If you want to boot TinyCore's vmlinuz directly from the UEFI firmware, the kernel needs to be compiled with CONFIG_EFI_STUB=y, and then you'll need to figure out what to do with the boot parameters and the initramfs file. I made such a set-up once, by configuring the boot options into UEFI boot variable. Without a bootloader, you probably won't have any way to change the boot parameters at boot time, so you'd better generate several UEFI boot variable settings ahead of time with different boot parameters, so that you'll have a way to access the system if something goes wrong with a kernel update for example.

(If your firmware-level UEFI boot options include a way to boot into UEFI Shell, it can be very useful in setting a "bootloaderless" UEFI-bootable installation.)

The UUIDs used in UEFI boot variables can be discovered by running the blkid command. GRUB uses the filesystem UUID (= the UUID= field), while the UEFI boot variables use the partition's unique UUID (= the PARTUUID= field).

Answer 2

Here's how I did it. First I set my PC EFI options to EFI boot only. Then I booted Ubuntu 16.04.4 off a DVD. (Obviously it was a UEFI boot.). Inside Ubuntu 16.04.4 I did the following.

1. Mounted my ESP partition. (It was partition 1 of disk 1)
2. mkdir /path/to/mounted/esp/partition/EFI/prime_boot
3. grub-mkimage -o /path/to/mounted/esp/partition/EFI/prime_boot/bootx64.efi --format=x86_64-efi '--prefix=(hd0,gpt1)/EFI/prime_boot' ext2 part_gpt

4. Set up the following grub.cfg file in /path/to/mounted/esp/partition/EFI/prime_boot/

   menuentry "GRUB chainloader" { chainloader (hd0,gpt2)/boot/efi/core.efi }

5. efibootmgr -c -d /dev/sda -p 1 -l \EFI\prime_boot\bootx64.efi -L "Primary Loader"

6. Set up the boot ordering in the EFI menus to use "Primary Loader"

Now you've got the EFI using this primary loader to vector off to the boot loader in the TinyCore partition. So now you set up the TinyCore partition's boot loader.

1. Mount the TinyCore partition. (Mine was disk 1 partition 2)
2. grub-mkimage -o /path/to/mounted/tinycore/partition/boot/efi/corex64.efi --format=x86_64-efi '--prefix=(hd0,gpt2)/boot/efi' ext2 part_gpt
3. Now create the multi-boot grub.cfg in /path/to/mounted/tinycore/partition/boot/efi/

I know one would wonder why I jump from primary boot loader to multi-boot loader. I just want to do as little as possible in my esp partition. I want TinyCore (my maintenance OS) to be the owner of the multi-boot boot manager.