Regression caused by systemd 252 - Access Denied

[patrakov]

I updated systemd in my Arch Linux system (which has an old board, MSI Z87I) to 252.1-1. As a result, it no longer boots with Secure Boot enabled.

I have reported this to systemd maintainers: https://github.com/systemd/systemd/issues/25336, however they say:

We have moved to a different way the inner kernel is loaded that relies less on hacks. As part of this process we install a secure boot override (so the kernel does not have to be signed) that does not appear to work with your firmware. This is something I half expected and I am too not sure how to deal with.

Maybe we should fall back to the EFI handover protocol in these cases while it's still supported by us… In the meantime you can fix this by having the kernel signed before it's embedded in the UKI. In fact, it's something that sbctl should really be doing anyways…

So let's sign the vmlinuz before mkinitcpio has a chance to look at it. I.e., here is what systemd maintainers seem to expect:

1. A new linux package is installed, and pacman runs all its hooks
2. sbctl should sign the vmlinuz file at this point, but currently doesn't know that it should do it
3. mkinitcpio produces the initrd and combines it with everything else by running objcopy, resulting in the unsigned Unified Kernel Image
4. sbctl should sign the UKI at this point, and does it correctly

[patrakov]

Fixed locally by adding a file, /etc/pacman.d/hooks/89-sbctl.hook:

[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Operation = Remove
Target = usr/lib/modules/*/vmlinuz

[Action]
Description = Signing Linux kernels...
When = PostTransaction
Exec = /bin/sh -c 'for file in /usr/lib/modules/*/vmlinuz ; do /usr/bin/sbctl sign "$file" ; done'

[Foxboron]

Probably fixed these days.