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"
```

to be booted using `systemd-boot`:
until the `postinst` script of `systemd-boot` runs:
/bin/bash <<EOF
minbase, after locales
directory

This only happens if /sys/firmware/efi/ is available in the chroot. If
you make sure that isn't the case when you do your builds/installs, it
should not happen anymore.

I have the same issue on my armhf board booting with U-Boot EFI
services. efivars is mounted read-only and remounting it read-write
fails with the following kernel error: "Firmware does not support
SetVariableRT. Can not remount with rw".

Interestingly, running the postinst script again will return success
because it detects that systemd-boot is installed in the ESP and runs
"bootctl update --graceful" instead of "bootctl install".

It is expected that some EFI platforms do not have persistent storage
for EFI variables, so couldn't the postinst script run "bootctl install"
with --no-variables if efivars is mounted read-only ?