systemd 260 introduces some new linkConfig options to configure ethernet
devices and a new [MobileNetwork] section (and options) to configure
cellular network connections using a new integration with ModemManager.
- https://github.com/systemd/systemd/releases/tag/v260
Fix by walking the newly-mounted metadata layer before the overlay is
(re)mounted and removing trusted.overlay.opaque from any upperdir
directory that now has a counterpart in the lowerdir. This turns those
directories back into merged views: user-placed files and individual
whiteouts are preserved, only the blanket hiding of lowerdir content
is undone.
Applied in both the activation script (switch-to-configuration) and
the initrd rw-etc service (boot), since the upperdir persists across
reboots. Uses the new clear-etc-opaque entrypoint of nixos-init so the
initrd stays bash-free.
Fixes#505475
`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.
LUKS itself supports empty passphrases, and NixOS even has
boot.initrd.luks.devices.<name>.tryEmptyPassphrase option, but still the
NixOS interactive LUKS passphrase prompt rejects empty passphrases.
Fix it.
Implementation note. The "open" command line is changed due to details
in how empty passphrases and trailing newlines are handled when reading
from stdin. This code path is only for the interactive prompt, not when
using keyfiles, and the "reuse passphrase" logic already strips trailing
newlines, so that's nothing new.
The check ran `realpath /run/current-system` under errexit, so a
missing current-system symlink aborted the script.
Drop the realpath calls (the -f test and jq already follow symlinks)
and use a static store path for the empty fallback instead of mktemp/trap.
Also exempt dry-activate, which makes no state changes and was being
blocked from showing its diff, and let jq fail loudly on malformed
inhibitor JSON instead of silently treating it as empty.
