Hi!
on a system with systemd-boot-efi installed (and not it's signed counterpart),
but shim-signed installed, systemd-boot's postinst will fail every other time
if the ESP is not mounted.
I used reinstalling shim-signed as trigger here:
Log started: 2025-07-31 03:09:11
Preparing to unpack .../shim-signed_1.46+15.8-1_amd64.deb ...
Unpacking shim-signed:amd64 (1.46+15.8-1) over (1.46+15.8-1) ...
Setting up shim-signed:amd64 (1.46+15.8-1) ...
No DKMS packages installed: not changing Secure Boot validation state.
Processing triggers for systemd-boot (257.7-1) ...
[1mdpkg:[0m error processing package systemd-boot (--configure):
installed systemd-boot package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
systemd-boot
Log ended: 2025-07-31 03:09:12
Log started: 2025-07-31 03:09:14
Preparing to unpack .../shim-signed_1.46+15.8-1_amd64.deb ...
Unpacking shim-signed:amd64 (1.46+15.8-1) over (1.46+15.8-1) ...
Setting up shim-signed:amd64 (1.46+15.8-1) ...
No DKMS packages installed: not changing Secure Boot validation state.
Setting up systemd-boot (257.7-1) ...
Log ended: 2025-07-31 03:09:14
The culprit is the invocation of
esp_path="$(bootctl --quiet --print-esp-path 2>/dev/null)"
in remove_shim() in systemd-boot's postinst, combined with `set -e`.
Executing this command exits with exit code 1 if no ESP can be found.
I understand this is a bit of an exotic setup, but I don't think having this
particular combination of packages installed without a currently mounted ESP is
in some way forbidden, and there might be valid reasons like manually managing
multiple ESPs, or robustness concerns about having the ESP mounted all the
time, that make it likely to trigger in practice.
I think the fix is quite simple - gracefully handle no ESP being mounted, which
seems to already be the intention. E.g., the invocation could be extended with
a final `|| true` to make it infallible.