fwupd stopped honouring the FWUPD_EFIAPPDIR environment variable in
https://github.com/fwupd/fwupd/pull/9846; the location is a compile-time
constant (`EFI_APP_LOCATION`) since then, so setting the variable on
fwupd.service had no effect.
Drop `RuntimeDirectory` from the signing unit too: the directory is now
created and populated by the fwupd module, and RuntimeDirectoryPreserve
defaults to `no`, so systemd removed it (together with the unsigned app)
whenever the unit stopped -- which `partOf = fwupd.service` makes happen
on every fwupd restart.
Cover the whole path in the limine secure boot test, which so far never
enabled fwupd: it now asserts that both the unsigned app and the signed
variant end up in /run/fwupd-efi.
Assisted-by: claude-code with claude-opus-5[1m]-high
The installer being placed directly at (e.g.)
/nix/store/272h8d4df6by64ycl3s01bixrcaq5a9a-limine-install.py causes
Python to search the script's directory for imports if -P is not added,
so add -P to avoid Python automatically adding /nix/store to the script's
sys.path.
From the python manpage:
> -P: Don't automatically prepend a potentially unsafe path to sys.path
> such as the current directory, the script's directory or an empty string.
> See also the PYTHONSAFEPATH environment variable.
The documentation describes this as a set of files copied to /boot, with
the attribute name denoting the destination file name in /boot.
This uses essentially the same description as refind, systemd-boot and
grub. However limine put it into limine_install_dir (/boot/limine by
default) by accident, which broke downstream users.
For example, nixos-apple-silicon uses boot.loader.limine.additionalFiles
(and similar directives for other bootloaders) to update its m1n1
bootloader (which chainloads into u-boot, which chainloads into the
bootloader selected in NixOS), and due to this bug, put new versions of
it in the wrong location, effectively never updating m1n1.
Fix this, by updating the location. The next commit adds a regression VM
test for it.
This is for instance useful on Asahi where an additional initrd archive
containing firmware blobs and per-device calibration files is placed
on the ESP and updated by the Asahi Linux Installer.
These need to be loaded alongside the NixOS initrd.
Implemented for systemd-boot and Limine. Grub is left out since its
install script does not use bootspec yet.
Co-authored-by: Florian Klink <flokli@flokli.de>
Allows running additional shell commands after the limine install script
generates menu entries, mirroring the systemd-boot option of the same
name.
Co-authored-by: Florian Klink <flokli@flokli.de>
The signing service builds `fwupd_efi` as a bash array but referenced
it as a scalar, tripping SC2128 (array expanded without index) and
SC2046 (unquoted command substitution). With enableStrictShellChecks
these are promoted to errors, breaking the unit-script build when
secureBoot, fwupd and strict shell checks are all enabled.
Loop over the array and sign every matched fwupd EFI binary, quoting
the basename and the -o argument. Indexing a single element would
silently skip any additional files the glob matches.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
Add boot.loader.limine.resolution option to control the framebuffer
resolution that Limine sets via GOP before booting Linux. This affects
early boot graphics drivers like simpledrm and efifb.
This is distinct from style.interface.resolution which only controls
the Limine bootloader's own menu interface - the new option sets the
per-entry "resolution:" directive in limine.conf which calls
gop->SetMode() to change the actual framebuffer resolution before
handing off to the kernel.
Example usage:
boot.loader.limine.resolution = "3840x1600x32";
This enables users to get native resolution early boot graphics
instead of being limited to whatever GOP mode the UEFI firmware
provides by default (often 1024x768).
Previously, all generations for the primary system profile
read their data from the currently active one rather than
their own path, and specialisations in general all used
their parent bootspec rather than their own. This fixes both issues.
This commit still uses the parent path's build date for
specialisations, but this is more minor issue and the times
shouldn't be meaningfully different in most cases anyways.
