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,