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
There is not reason to build an extra variant of OVMF only to get Secure
Boot support. We can just use the already built OVMFFull. Since
useSecureBoot is now no-op, it is also removed.
ids that were allocated and later freed only live in
/var/lib/nixos/{uid,gid}-map. userborn allocates from /etc/passwd
alone, so without this a new user could get a previously-used uid and
inherit file ownership.
Service has a ConditionPathExists on the uid-map and a sentinel under
/var/lib/userborn, so it runs at most once and is a no-op on fresh
installs.
Boots with the perl impl, removes a user, switches to userborn with a
new user, and asserts no uid collision and that the removed user is
revived with its original uid.
Fails until the migration service lands in the next commits.
This ensures the filter is sent to the sync endpoint properly. Originally found this shortcoming of the refactored test in my personal package repository, this commit upstreams the fix. Continuwuity just ignores incorrect sync filters, so this just exists for completeness.
