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

    From =?utf-8?q?Sofus_Albert_H=C3=B8gsbro@21:1/5 to All on Fri Jul 25 11:40:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to [email protected] on Fri Jul 25 12:30:01 2025
    On Fri, 25 Jul 2025 11:30:39 +0200 =?utf-
    8?q?Sofus_Albert_H=C3=B8gsbro_Rose?= <[email protected]> wrote:
    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

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)