You are not logged in.
I've been secure-booting this laptop with a signed UKI using shimx86 for a long time. Last night when I did "pacman -Syu" I got these messages:
[2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] ==> Creating unified kernel image: '/boot/EFI/BOOT/grubx64.efi'
[2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] -> Using cmdline file: '/etc/kernel/cmdline'
[2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] ==> Unified kernel image generation successful
[2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] ==> Running post hooks
[2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] -> Running post hook: [sign_kernel]
[2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] Signing /boot/EFI/BOOT/grubx64.efi
[2024-08-07T17:06:05+0200] [ALPM-SCRIPTLET] Signing Unsigned original image
[2024-08-07T17:06:05+0200] [ALPM-SCRIPTLET] -> Running post hook: [sbctl]
[2024-08-07T17:06:05+0200] [ALPM-SCRIPTLET] old configuration detected. Please use `sbctl setup --migrate`
[2024-08-07T17:06:05+0200] [ALPM-SCRIPTLET] Secureboot key directory doesn't exist, not signing!
[2024-08-07T17:06:05+0200] [ALPM-SCRIPTLET] ==> Post processing done
Being the good citizen I am, I did the "sbctl setup --migrate" as suggested:
# sbctl setup --migrate
old configuration detected. Please use `sbctl setup --migrate`
sbctl is not installd
# sbctl status
old configuration detected. Please use `sbctl setup --migrate`
Installed: ✗ sbctl is not installed
Setup Mode: ✓ Disabled
Secure Boot: ✓ Enabled
Vendor Keys: microsoft
#
The migration not only didn't work, it also doesn't make sense: If sbctl is not installed, why is the sbctl binary there? Also, if /boot/EFI/BOOT/grubx64.efi can't be signed, why does the system still boot up in SB mode? The grubx64.efi has today's timestamp, and according to dmesg's first line of output the kernel image is two days old. So I am running secore boot with an up-to-date UKI which, according to sbctl (which maybe is or s not installed) has not been signed. Can someone explain what is going on here?
(I don't want to discuss the merits of SB here. I'm using it because there is Windows on the same computer which requires SB. I select which OS to boot in the BIOS boot menu, so it's not what people typically call "dual boot").
Last edited by musbur (2024-09-15 15:18:07)
Offline
Note: I looked in the pacman logs and it turns out that the "old configuration detected" has been there since mid-August, but the "not signing" error only started today.
Offline
The migration not only didn't work, it also doesn't make sense: If sbctl is not installed, why is the sbctl binary there?
When working with sbctl there are two kinds of "installed" - the pacman package itself and the status of sbctl - see https://wiki.archlinux.org/title/Unifie … lling_keys after the first "status" command.
Also, if /boot/EFI/BOOT/grubx64.efi can't be signed, why does the system still boot up in SB mode?
Because it's already signed before the invocation of sbctl:
[2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] ==> Creating unified kernel image: '/boot/EFI/BOOT/grubx64.efi' [2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] -> Using cmdline file: '/etc/kernel/cmdline' [2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] ==> Unified kernel image generation successful [2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] ==> Running post hooks [2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] -> Running post hook: [sign_kernel] [2024-08-07T17:06:04+0200] [ALPM-SCRIPTLET] Signing /boot/EFI/BOOT/grubx64.efi [2024-08-07T17:06:05+0200] [ALPM-SCRIPTLET] Signing Unsigned original image [...]
The line last quoted here indicates a successful signing operation.
Last edited by -thc (2024-09-15 09:51:53)
Offline
Thanks for your reply. I've dug a bit deeper into my setup and have found some stuff I vaguely remember doing myself -- either by copying from the Wiki, or fruits of my own genius. See below. Either way, that seems to take care of the signing business without sbctl being involved. I wonder why sbctl starts caring all of a sudden, and from where the binary gets called. At least under /etc there is no file that contains the string "sbctl" so it's not part of any "hook" file for the UKI rebuild.
I'll try and do my research.
# cat /etc/initcpio/post/sign_kernel
#!/bin/sh
UKI="/boot/EFI/BOOT/grubx64.efi"
echo "Signing $UKI"
/etc/mok/sign_mok "$UKI"
#
# cat /etc/mok/sign_mok
#!/bin/sh
dir=$(dirname "$0")
if ! sbverify --list "$1" 2>/dev/null | grep -q "signature certificates"
then sbsign --key "$dir/MOK.key" --cert "$dir/MOK.crt" --output "$1" "$1"
fi
#
Offline
Upon carefully re-reading the secure boot Wiki entry it turns out that sbctl is just a helper script that does stuff which I already have done by hand. I just uninstalled it which stopped the complaints.
Offline