libfido2 links against pcsclite's libpcsclite.so.1, which since
pcsclite 2.3.1 is a shim that dlopens libpcsclite_real.so.1. nixpkgs
patches that dlopen to an absolute store path. make-initrd-ng only
follows DT_NEEDED, so the real library never ends up in the initrd.
systemd-cryptsetup then logs at boot:
loading ".../pcsclite-2.4.1-lib/lib/libpcsclite_real.so.1" failed:
cannot open shared object file: No such file or directory
and FIDO2 tokens behind PC/SC (NFC readers) cannot be used to unlock
LUKS in stage 1. Add the real library to the initrd store paths.
systemd v261 added systemd-pcrlogin@.service, which logind starts on
first login of a user to measure the user record into the 'login'
NvPCR. NixOS does not install the unit, so every first login logs:
systemd-logind: Failed to start user measurement service
'systemd-pcrlogin@1000.service', ignoring: Unit not found.
Install the unit on systems with systemd.tpm2.enable. The unit has ConditionSecurity=measured-os and does nothing elsewhere.
We aren't linking systemd to gnutls anymore so these options
were all silently ignored. Which is pretty bad!
Assisted-by: Claude <noreply@anthropic.com>
This adds io.systemd.PCRExtend if the system has TPM2
enabled.
Additionally, this requires the system to fullfill
ConditionSecurity=measured-uki.
Change-Id: I3f1046cdc7463f3b6d3205030f7f12ac95e5cd9e
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
This enables the ability to use systemd-repart over Varlink at
/run/systemd/io.systemd.Repart.
Change-Id: Ia74fdf8c2cbc4ec52994ba8ceb5796acc731abd3
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
I have effectively renounced on maintaining all these packages and I do
not plan to return them except if I'm forced to.
I am also fine with most of these packages being dropped for next
releases if no maintainer shows up.
Change-Id: I8d167c8029b6991181bd7a094af21c3313af2b51
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
initrd-nixos-activation ran the closure's prepare-root unconditionally. For a
non-NixOS init= there is no prepare-root, so the service failed, and since
initrd-switch-root.service requires it, switch-root never ran and the machine
dropped to the emergency shell. This broke init=/bin/sh recovery, and microVMs
that serve /nix/store over virtiofs and boot an arbitrary binary as init=.
initrd-find-nixos-closure already detects this and writes a non-empty NEW_INIT
to /etc/switch-root.conf (empty for a NixOS init). Read it via the same
EnvironmentFile= initrd-switch-root uses and skip activation when it's set, so
a non-NixOS init= switch-roots into its target directly. The NixOS path is
unchanged.
Also add a test booting a non-NixOS init=. It uses a store path rather than
/bin/sh: a real root already has /bin/sh and an os-release, but a fresh test
root has neither, so the test uses a tmpfs root and writes os-release first.
Assisted-by: Claude:claude-opus-4-8
Replace `systemd.user.extraConfig` with a freeform `systemd.user.settings.Manager` submodule, rendered via `utils.systemdUtils.lib.settingsToSections`. `extraConfig` is removed via `mkRemovedOptionModule`. Mirrors the existing `systemd.settings.Manager` migration of the system-side manager.
Updates the two in-tree consumers (`nixos/modules/testing/test-instrumentation.nix` and `nixos/tests/systemd.nix`) to the new option.
Adds `nixos/tests/systemd-user-settings` to assert the rendered `user.conf` contents.
Drop the `with utils;`, `with systemdUtils.unitOptions;` and `with lib;` blocks and qualify all references with `lib.`, `utils.systemdUtils.lib.` and `utils.systemdUtils.types.` instead. No behavioural change.
Replace the free-form `systemd.coredump.extraConfig` option with a structured `systemd.coredump.settings.Coredump` submodule rendered via `utils.systemdUtils.lib.settingsToSections`, in line with RFC 42. A `mkRemovedOptionModule` entry points existing users at the new option, and the systemd-coredump NixOS test now exercises the new settings option by asserting the rendered `coredump.conf` contents.
`config.system.build.kernel.config` is not actually accurate. When a
kconfig is specified in the `config` argument to `kernel/build.nix`
(a.k.a. `manualConfig` or `linuxManualConfig`), then `isSet` will
return `true` and other queries like `isYes` will be accurate. But if
a kconfig is not specified in that `config` argument, then `isSet`
will return `false` and other queries will be inaccurate, e.g. `isYes`
"MODULES"` can return `false` even though your `configfile` has it
enabled.
Note the difference between the `config` argument and the `configfile`
argument. The `configfile` is how the kernel will be actually built,
while `config` is merely passed through as a source of eval-time
information. Importantly, neither is derived from the other *in any
way*, unless `builtins.isPath configfile || allowImportFromDerivation`
in which case the default value for `config` is derived from reading
`configfile`.
The more generic `kernel/generic.nix` (a.k.a. `buildLinux`) creates
its `configfile` in a derivation, so it cannot be read at eval time by
default. It calls into `kernel/build.nix`, and only passes a `config`
with `CONFIG_MODULES`, `CONFIG_FW_LOADER`, and `CONFIG_RUST` set. So
almost nothing in `kernel.config` is accurate in the typical
case. `MODULES` happens to be one of the three that *is* accurate
typically, but regardless we obviously can't rely on that since a user
of `kernel/build.nix` is likely to mess it up. Even worse,
`structuredExtraConfig` is not incorporated into `kernel.config` at
all, which leads to the incredibly confusing scenario where a kconfig
is specified in `structuredExtraConfig` but still is not represented
accurately by these queries.
All of this is why, in most cases, the implementation of
`requiredKernelConfig` deliberately does absolutely nothing and
creates an empty list of assertions, and it's all extremely confusing.
With all that in mind:
TODO:
- The structured config used to generate the `configfile` should be
reflected in the `config` argument to `kernel/build.nix`, and
consequently `kernel.config`.
- The three kconfigs represented by `config` in `kernel/generic.nix`
now, `CONFIG_MODULES`, `CONFIG_FW_LOADER`, and `CONFIG_RUST`, should
be set in the structured config.
- Queries for kconfigs that we don't actually know the value of at
eval time should fail to evaluate, rather than evaluating
inaccurately.
- Most of the ways we use these eval-time queries should instead be
done at build time, so they can use the complete `configfile` rather
than the incomplete eval-time `config` value.
- The ones that we still want to happen at eval-time should be more
prepared for the possibility that we can't know the value of
arbitrary kconfigs at eval time.
---
Anyway, all that is to say: I'd like for this all to be better, but am
not willing to work on the kernel expressions myself at the moment, so
I thought I'd write down the reasons why this change was necessary,
and the extent of the problem.
We had already successfully considered this issue in one place in
`systemd/initrd.nix`, but it seems there are two more places where we
should have taken the same care.
Previously, this was patched directly into the systemd derivation. Now,
this is done via the module system. To make building systemd and
maintaining it simpler.
nikstur