Bug#1109864: systemd-boot: postinst fails when EFI variables cannot be written

[Sofus Albert Høgsbro Rose]

Package: systemd-boot
Version: 257.7-1
Severity: normal
X-Debbugs-Cc: debianbug at sofusrose.com

Dear Maintainer,

I'm preparing a bootable `trixie` ISO with two partitions, intended to be booted using `systemd-boot`:
- A FAT32 `/boot` EFI partition.
- An ext4 `/` partition.

The standard `chroot`-qemu-aarch64-from-x86 approach works very well, until the `postinst` script of `systemd-boot` runs:
```bash
$ sudo chroot "$MOUNTED_ROOT_DIR" /usr/bin/qemu-aarch64-static /bin/bash <<EOF
apt update
apt install --yes systemd-boot  ## Minimal failing example on minbase, after locales
EOF

...
Failed to write 'LoaderSystemToken' EFI variable: No such file or directory
...
```

>From my own testing, I'm relatively certain that this error originates with `bootctl install`. This tracks with the documentation of that option.

Now, obviously, in this context, it's quite a good thing that writing an EFI variable fails while still on the host (indeed, success would be worrying!).  What makes this a package bug is that `dpkg` escalates this to a `postinst` failure.

The workarounds I have been able to devise before making this report all have significant downsides:
- One can make do the `systemd-boot-efi` (and `*-tools`), and manually use `bootctl --no-variables install`. This comes at the cost of all the nice things that the `systemd-boot` ships with - the `kernel-install` invocations in `/etc/kernel/*` and `/etc/initramfs`, services and sockets for ex. updating the random seed on boot, and much more. These must all essentially be copied from the `systemd-boot` package.
    - I should mention that a lack of `systemd-boot` means `kernel-install` isn't invoked; what makes this confusing is #1095646 (I think), which causes `dracut` to run, giving the impression that a boot should be possible (it isn't, since there are no entries generated).
- One could try to manually patch in `--no-variables` in the `postinst` scripts, for the duration of the chroot session only, then also make sure to queue a first-boot to set those EFI variables. The cost of this is having to mess with downloaded `dpkg` `postinst` files. I'm also unsure whether `systemd-boot` will set the desired EFI variables at all, ever.

I have the following concepts of how this might be fixed:
- Errors related to EFI variables could be caught and turned into warnings instead. This runs the risk of `dpkg` improperly succeeding in the "standard case" where users do want EFI variables written.
- The write to EFI variables on the firmware could be outsourced to a very simple package that `systemd-boot` recommends. Then, the `postinst` of this package could default to `--no-variables` (it should be harmless to run `bootctl` twice, but perhaps this could be checked). That "very simple extra package" could even have a variant that sets EFI variables on (first?) boot.

I hope this bug report is helpful and thorough. I am not so familiar with the conventions here, so I apologize if my "ideas" are starkly against the way things are done; in any case, I am happy to help with more information / anything else.

Thank you for your time!

Kindest Regards,
Sofus



Related (upstream):
- `--no-variables` has been replaced "soon": https://github.com/poettering/systemd/commit/7db417bda6a98e86b6a02abe964e657f3d4ec689

Possibly related (arch/upstream):
- https://github.com/archlinux/archinstall/pull/3396
- https://github.com/systemd/systemd/issues/36174
- https://github.com/systemd/systemd/issues/35005

NOTE: My host machine is a Ubuntu machine, but just to be clear, the error happens inside a Debian system that is to be booted directly. The `chroot` is just a way to run commands within that not-yet-booted system. Therefore, it would surprise me if it mattered that the host is Ubuntu based.

For clarity, the Debian system is prepared with the script below.

```bash
DEBIAN_VARIANT="minbase"
DEBIAN_ARCH="arm64"
DEBIAN_RELEASE="trixie"
DEBIAN_ARCHIVES="main contrib non-free non-free-firmware"
DEBIAN_MIRROR_URL="http://deb.debian.org/debian"
DEBIAN_BOOTSTRAP_PKGS="locales"
sudo mmdebstrap \
	--variant=$DEBIAN_VARIANT \
	--arch=$DEBIAN_ARCH \
	--components="$DEBIAN_ARCHIVES" \
	--include="$DEBIAN_BOOTSTRAP_PKGS" \
	$DEBIAN_RELEASE \
	"$ROOT_DIR" \
	"$DEBIAN_MIRROR_URL"
```


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.12-x64v3-xanmod1 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled