Bug#1107066: systemd-boot: fails to boot in rare scenarios

[Raphaël Halimi]

Package: systemd
Version: 257.5-2
Severity: minor
Tags: patch

Dear developers,

TL;DR postinst should remove its previous boot entry when first 
installed, install mm alongside shim and fb in the default boot path, 
and either not use `--make-machine-id-directory=auto` or fix 
`$ESP/loader/loader.conf`

Long version:

The current systemd-boot maintainer scripts work pretty well for the 
vast majority of cases, but may fail to do the right thing in some rare 
scenarios (hence the "Severity: minor" tag).

Please note: all the facts described here were tested on a Bookworm 
install, with systemd-boot from backports, and homemade helper packages 
to mimic the current systemd-boot maintainer scripts and sign 
systemd-boot with a MOK, but in theory the errors described here would 
also apply to Trixie, and should IMHO be fixed.

Here is the faulty scenario: let's say debian-installer is customized to 
not install GRUB, install systemd-boot, generate a MOK, sign 
systemd-boot with it (on Bookworm), and generate UKIs also signed by the 
MOK, all before first boot.  The MOK is imported, the system boots for 
the first time, shim chainloads systemd-boot and everything works 
perfectly well as intended.

Now, let's say that the machine must be reinstalled for some reason, and 
the same procedure runs again, without wiping the boot entries and/or ESP.

Here's what happens during the second install:
- sd-boot postinst runs `bootctl install` again, which blindly adds its 
boot entry (plain sd-boot without shim) at the top of boot order
- postinst checks for shim's boot entry, finds it and does nothing, 
despite that it's not the default one anymore

Then, on first boot:
- UEFI boots plain sd-boot (without shim), which fails. To fix this, 
postinst should check if the entry it previously created is still first 
in boot order, and also if the ESP's GUID did not change. The simplest 
thing to do is to simply delete the entry when the package is installed 
for the first time (i.e. if $2 is empty)
- UEFI tries the default boot path, but since a MOK import was requested 
during installation, shim tries to run mm, which fails. To fix this, 
postinst should also copy mm to the default path, in addition of shim 
and fb.

After this step, if mm is copied to the default path by other means, 
UEFI tries again the default boot path, shim runs mm, and the MOK is 
imported. After a reboot, UEFI again boots plain systemd-boot without 
shim and fails, and tries again the default boot path, shim then runs 
fb, which fixes the boot entry to chainload sd-boot through shim.

Finally, after another reboot, UEFI at last loads shim which chainloads 
systemd-boot, but there's still another problem: if d-i reuses the ESP 
without formating it, systemd-boot tries to boot the kernels/UKIs from 
the previous install, due to the presence of a `default` directive in 
`$ESP/loader/loader.conf`, and since those entries have the `root=` 
parameter which refers to the old (now missing) partition, this of 
course fails.

This directive is inserted by `bootctl install` because it's called in 
the postinst with the undocumented option 
`--make-machine-id-directory=auto`, **and** systemd-boot is configured 
to use Type #1 entries (i.e. there's no `/etc/kernel/install.conf` with 
`layout=uki`, or not yet).

To fix this, either remove this option from the postint and let 
systemd-boot decide by itself which entry should be considered the 
default (as intended by upstream), or fix `$ESP/loader/loader.conf` 
afterwards to set the `default` directive and boot the new kernels/UKIs, 
which would be consistent with the "take over ESP and EFI boot entry" 
logic of the postinst.

You'll find attached a series of patches to fix all of those three 
problems.  Patches numbered "0003" are mutually exclusive. I tried to 
mimic your coding style as much as I could, but they may not be perfect 
in this regard.

By the way, I won't open a new bug report for that, but when you fixed 
#1106024, you didn't add code to the `remove_shim` function to remove 
fb, and since mm would also need this, I also attached a patch to clean 
up those files.

Regards,

-- 
Raphaël Halimi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-boot-entry-not-set-ad-default.patch
Type: text/x-patch
Size: 4460 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20250531/76473dda/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Copy-Mok-Manager-to-default-boot-path.patch
Type: text/x-patch
Size: 1710 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20250531/76473dda/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Drop-make-machine-id-directory-option.patch
Type: text/x-patch
Size: 827 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20250531/76473dda/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Fix-loader.conf.patch
Type: text/x-patch
Size: 2258 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20250531/76473dda/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Cleanup-shim-helpers-on-remove.patch
Type: text/x-patch
Size: 1020 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20250531/76473dda/attachment-0004.bin>