Secure boot keys [dracut] lost on garuda-update

Issues & Assistance Unsupported Software (AUR & Other)
1

Some change since broke my latest update today, and now it cannot sign kernels. Previously I had signing keys in /etc/secureboot/keys/… where I can now only find broken symlinks to /etc/efi-keys that does not exist. My current kernel is

I cannot recall exactly how I setup the keys in 2021 when this stuff was still quite experimental. Possibly I had them in /etc/efi-keys that has since been deleted (as obsolete?), or I had them in /etc/secureboot as files, that have now been replaced with symlinks. I also noticed that dracut-garuda.conf had been changed to look for the keys in /usr/share/secureboot, that also does not exist and that I have never used. Also it would appear sbctl prefers /var/lib/sbctl/keys where it just created me a set of new keys (that I cannot currently enroll to my UEFI firmware).

Note: I am using dracut to build uefi boot images for my kernels, using custom keys (Microsoft NOT included), and systemd-boot without grub. I am working on the headless box from another country, so having my keys recreated and uploaded is a lot of hassle. It would need local console access to enter UEFI setup and delete the existing keys if permanently lost.

  • Any ideas on where to look for the key files now?
  • Where to keep (new key files) as the best practice? /usr/share, /var/lib or /etc?

Related documentation: Unified kernel image - ArchWiki

2

The previous time when I had trouble with this same machine:

3

What error are you are getting?

If you are using sbctl with custom keys, the relevant directory is /var/lib/sbctl.

5 Likes
4

Already closed terminal, so I can’t get the original errors. Dracut was complaining about not being able to open the key files (from /usr/share)

uefi_secureboot_cert="/var/lib/sbctl/keys/db/db.pem"
uefi_secureboot_key="/var/lib/sbctl/keys/db/db.key"

After changing /etc/dracut.conf.d/dracut-garuda.conf paths as above, It no longer complains about missing keys but gave me a segfault on sbverify.

dracut --force
Signing Unsigned original image
/usr/bin/dracut: line 2715: 1625037 Segmentation fault      (core dumped) sbverify --cert "${uefi_secureboot_cert}" "$outfile" > /dev/null 2>&1
dracut[F]: *** Creating signed UEFI image file '/boot/efi/EFI/Linux/linux-6.6.10-zen1-1-zen-rolling.efi.tmp' failed ***

Turns out that /boot/efi not having enough space for another kernel caused the segfault, since after freeing up space it passed without errors (I can debug this if needed, to improve dracut/sbverify to print an out of disk space error instead).

It would seem that my old keys from /etc/efi-keys got migrated to /var/lib/sbctl by some upgrade script, and thus are the ones enrolled to UEFI. I could sbverify these keys against an old kernel image signed (and mtimed) earlier than my previous reboot, and against the newly built image.

And it’ll take until June for someone to be ready to fix it on console, so for safety reasons I am avoiding reboots for now. Thanks for the help!

5

That makes sense, glad to hear you got it figured out.

Your setup is kind of odd because you have multiple different solutions for handling the signing installed concurrently. For example, this looks like you have dracut-ukify installed:

It seems strange to use dracut-ukify for signing if you already have sbctl installed, since you could just sbctl itself for that (it even ships with a Pacman hook for this). In fact, you don’t even need sbsigntools installed at all if you are using sbctl. And dracut can create UKIs on its own (without any additional packages needed) by running a rebuild with the --uefi flag.

But, it sounds like everything is working okay now so perhaps it is fine to just leave it be like you say. Good luck with the reboot in June! :wave:

3 Likes
6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.