Foxboron
Update the documentation for signing systemd-boot
systemd v250 will automatically update the bootloader (https://github.com/systemd/systemd/commit/71c8bf28378958a5ab2348e9ec586fbe78c71dfd) which could break booting (as the updated bootloader isn't signed).
Another change in v250 (https://github.com/systemd/systemd/commit/12caf7271655e16030e34279b1fb0b29a592f6ad), is that /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed will be used over /usr/lib/systemd/boot/efi/systemd-bootx64.efi if it exists.
This means for systemd >=v250 the following commands should be used (not tested with systemd v250):
$ sbctl sign -s /usr/lib/systemd/boot/efi/systemd-bootx64.efi -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed
$ bootctl update
Unfortunately, after reading the code, I don't think bootctl update will install the signed bootloader if the unsigned version is the same. Doing a manually cp could be a solution.
and for systemd <v250
$ sbctl sign -s /efi/EFI/systemd/systemd-bootx64.efi
I mean, this is down to preference and there isn't one way to do this. The README.md are just examples on usage, not guidance and I'm not quite sure what documentation should be updated?
They are just examples, but the README.md is the most prominent kind of documentation (AFAIK) for how to use sbctl, so IMO it is worth mentioning (we don't necessarily need to be provide a solution) so the user's systems don't break when they update systemd.
Which is why I have started mocking up the following section in the manpage :)
Generally speaking the sbctl hook should run after the bootloader install so I don't think existing systems are going to break. It would just allow some people to simplify their setups.
Feel free to contribute a change :)
diff --git a/docs/sbctl.8.txt b/docs/sbctl.8.txt
index 2927280..6291c13 100644
--- a/docs/sbctl.8.txt
+++ b/docs/sbctl.8.txt
@@ -174,10 +174,34 @@ database (see **FILES**). Subsequent executions of *sbctl generate-bundles*
will rebuild these bundles, so you don't need to re-specify all parameters
after each system update.
-Hint: systemd-boot will automatically show entries for any bundles found in
+Tip: systemd-boot will automatically show entries for any bundles found in
*esp/EFI/Linux/+++*+++.efi*.
+Option ROM
+----------
+UEF
+
+
+Usage
+-----
+
+ $ sbctl create-keys
+
+ $ sbctl enroll-keys
+
+ $ sbctl sign -s /boot/vmlinuz
+
+ $ sbctl sign -s /efi/EFI/BOOT/BOOTX64.EFI
+
+ $ sbctl bundle -i /boot/intel-ucode.img
+ -l /usr/share/systemd/bootctl/splash-arch.bmp
+ -k /boot/vmlinuz-linux
+ -f /boot/initramfs-linux-lts.img
+ -c /etc/kernel/cmdline
+ /efi/EFI/Linux/linux-linux.efi
+
+
Notes
-----
All commands that take path arguments convert them into absolute paths when
Which is why I have started mocking up the following section in the manpage :)
I like that and TIL about /usr/share/systemd/bootctl/splash-arch.bmp :)
Generally speaking the sbctl hook should run after the bootloader install so I don't think existing systems are going to break. It would just allow some people to simplify their setups.
If nothing changes, existing systems will break (AFAIU):
- systemd is upgraded v249 -> v250 (
zz-sbctl.hookis called) - Reboot
systemd-boot-update.serviceupdates the bootloader- Reboot
- The system won't boot as the bootloader isn't signed
One way to avoid this, is if the systemd package calls bootctl update as recommended in: https://github.com/systemd/systemd/commit/71c8bf28378958a5ab2348e9ec586fbe78c71dfd.
Right, I missed the first sentence.
It's still not going to break any Arch install however. https://github.com/archlinux/svntogit-packages/blob/packages/systemd/trunk/PKGBUILD#L221-L222
I need to think a bit how to solve this.
Wouldn't some systemd service file that is always run after systemd-boot-update.service do the trick?
See also: https://github.com/systemd/systemd/issues/26881
