Package: systemd-boot
Version: 257.7-1
Severity: normal
X-Debbugs-Cc: [email protected]
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
