Arch Linux

marcoh00

Member

Registered: 2025-09-04

Posts: 1

Secure Boot using shim and grub2 - reboot on kernel load

Hello there,

a few weeks ago, I decided to explore what I'd have to do in order to craft a bootc-compatible Arch Linux image. You can find it here and it can probably answer any questions you may have on what I tried and how the system is configured. If anyone else is interested, feel free to contribute by the way

Anyway, once booting the image worked, I decided I wanted to implement Secure Boot. For this, I went with the signed shim route (I currently use Fedora's shim and sign both my grub image as well as the kernel during the container build. When I boot without SB, the system comes up flawlessly and I can validate the signatures of both the kernel file referenced by the bootloader and the grub2 efi file using the certificate. Of course, the certificate was previously enrolled using MokManager (which worked, because otherwise, grub wouldn't load).

These are the modules included in the efi image (which are basically the ones from Ubuntu as mentioned in the Wiki, minus those that are not available on arch plus blscfg):

all_video boot cat configfile echo true font gfxmenu gfxterm gzio halt iso9660 jpeg minicmd normal part_apple part_msdos part_gpt password password_pbkdf2 png reboot search search_fs_uuid search_fs_file search_label sleep test video fat loadenv loopback chain efifwsetup efinet read tpm tss2 tpm2_key_protector memdisk tar squash4 xzio blscfg linux btrfs ext2 xfs tftp http efinet luks luks2 gcry_rijndael gcry_sha1 gcry_sha256 gcry_sha512 mdraid09 mdraid1x lvm serial

All tests were conducted on a QEMU VM using the edk2 secureboot firmware.

As I said, booting this without SB works. When enabling SB, grub is loaded and shows the menu. Once I select the Arch Linux entry, the screen goes black and after a few seconds, the system reboots. When I enable some debugging messages (

set debug=loader,linux

for grub and

loglevel=7

as a kernel cmdline) I at least get something:

Booting a command list

loader/efi/linux.c:469:linux: shim_lock enabled, falling back to legacy Linux kernel loader
loader/i386/linux.c:204:linux: prot_mode_mem = 0x5e00000, prot_mode_target = 5e00000, prot_size = 425b000
loader/i386/linux.c:871:linux: bzImage, setup=0x4e00, size=0x425b000
loader/i386/linux.c:1112:linux: Initrd at addr 0x2a2d4000 which is expected in range 0xa05b000 ~ 0x37feffff
loader/i386/linux.c:1139:linux: Initrd (0x1c5b9000) at 0x1c5b9000, size=0xdd1a17a
loader/i386/linux.c:531:linux: real_size = 6000, mmap_size = 2000
loader/i386/linux.c:379:linux: addr = 10000, size = 20000, need_size = 9000
loader/i386/linux.c:379:linux: addr = 50000, size = 40000, need_size = 9000
loader/i386/linux.c:541:linux: real_mode_target = 87000, real_size = 6000, efi_mmap_size = 3000
loader/i386/linux.c:564:linux: real_mode_mem = 0x7eebb000
loader/i386/linux.c:574:linux: code32_start = 5e00000

I already asked a few AI assistants which mostly agreed with each other that this could be because of the way the legacy linux loader works and that other distributions patch their grub packages because of this (which might be the reason openSUSE uses linuxefi/initrdefi commands by default). But all of them quickly start hallucinating what the problem is exactly and which patches are needed (Fedora and openSUSE both apply >200 patches (!!!) after all).

Due to bootc/ostree constraints switching to systemd-boot is not an option unfortunately.

So, my question is: Has anyone a working shim+grub setup using the archlinux grub? If not, does anyone know a bit about how this works on a lower level and which patches might be needed?

Thanks!

-thc

Member

Registered: 2017-03-15

Posts: 998

Re: Secure Boot using shim and grub2 - reboot on kernel load

Let me recap your situation as far as I understand it:

You use a QEMU VM with EDK2 secure boot firmware. You've set up your own MOK certificate and enabled it in the (virtual) EFI firmware. The signed grubx64.efi is loaded and the signed kernel too (otherwise GRUB would have reported a violation). Then it reboots. Without secure boot it works.

I suspect an error in the virtual firmware. You could try another (secure boot capable) hypervisor. You could try a physical machine instead. You could try disabling shim validation (just to tweak things). You could try your own SB keys.