Implementation is now compatible with the option's .type already defined.
This allows us to pass `config.users.users.<user>.hashedPassword` even if this is null (the default).
Before:
true => access
false => no access
hash => access via password
null => eval error
After:
true => access
false => no access
hash => access via password
null => no access
This adds support for declaring tmpfiles rules exclusively for the
systemd initrd. Configuration is possible through the new option
`boot.initrd.systemd.tmpfiles.settings` that shares the same interface as
`systemd.tmpfiles.settings`.
I did intentionally not replicate the `rules` interface here, given that
the settings attribute set is more versatile than the list of strings
used for `rules`. This should also make it unnecessary to implement the
workaround from 1a68e21d47 again.
A self-contained `tmpfiles.d` directory is generated from the new initrd
settings and it is added to the initrd as a content path at
`/etc/tmpfiles.d`.
The stage-1 `systemd-tmpfiles-setup.service` is now altered to no longer
operate under the `/sysroot` prefix, because the `/sysroot` hierarchy
cannot be expected to be available when the default upstream service is
started.
To handle files under `/sysroot` a slightly altered version of the
upstream default service is introduced. This new unit
`systemd-tmpfiles-setup-sysroot.service` operates only under the
`/sysroot` prefix and it is ordered between `initrd-fs.target` and the
nixos activation.
Config related to tmpfiles was moved from initrd.nix to tmpfiles.nix.
In #327506, we stopped using `/sbin` in the `pathsToLink` of `initrdBinEnv`. This inadvertantly stopped including the `sbin` directory of the `initrdBin` packages, which meant that things like `mdadm`'s udev rules, which referred to binaries by their `sbin` paths, stopped working.
The purpose of #327506 was to fix the fact that `mount` was not calling mount helpers like `mount.ext4` unless they happened to be in `/sbin`. But this raised some questions for me, because I thought we set `managerEnvironment.PATH` to help util-linux find helpers for both `mount` and `fsck`. So I decided to look at how this works in stage 2 to figure it out, and it's a little cursed.
---
What I already knew is that we have [this](696a4e3758/nixos/modules/system/boot/systemd.nix (L624-L625))
```
# util-linux is needed for the main fsck utility wrapping the fs-specific ones
PATH = lib.makeBinPath (config.system.fsPackages ++ [cfg.package.util-linux]);
```
And I thought this was how `mount` finds the mount helpers. But if that were true, then `mount` should be finding helpers in stage 1 because of [this](696a4e3758/nixos/modules/system/boot/systemd/initrd.nix (L411))
```
managerEnvironment.PATH = "/bin";
```
Turns out, `mount` _actually_ finds helpers with [this configure flag](696a4e3758/pkgs/os-specific/linux/util-linux/default.nix (L59))
```
"--enable-fs-paths-default=/run/wrappers/bin:/run/current-system/sw/bin:/sbin"
```
Ok... so then why do we need the PATH? Because `fsck` has [this](a75c7a102e/disk-utils/fsck.c (L1659))
```
fsck_path = xstrdup(path && *path ? path : FSCK_DEFAULT_PATH);
```
(`path` is `getenv("PATH")`)
So, tl;dr, `mount` and `fsck` have completely unrelated search paths for their helper programs
For `mount`, we have to use a configure flag to point to `/run/current-system`, and for `fsck` we can just set PATH
---
So, for systemd stage 1, we *do* want to include packages' `sbin` paths, because of the `mdadm` problem. But for `mount`, we need helpers to be on the search path, and right now that means putting it somewhere in `/run/wrappers/bin:/run/current-system/sw/bin:/sbin`.
Since the systemd boot counting PR was merged, dashes in specialisation
names cause issues when installing the boot loader entries, since dashes
are also used as separator for the different components of the file name
of the boot loader entries on disk.
The assertion avoids this footgun which is pretty annoying to recover
from.
With the the Systemd-based initrd, systemd-journald is doing the logging.
One of Journald's Trusted Journal Fields is `_HOSTNAME` (systemd.journal-fields(7)).
Without explicitly setting the hostname via this file or the kernel cmdline, `localhost` is used and captured in the journal.
As a result, a boot's log references multiple hostnames.
With centralized log collection this breaks filtering (more so when logs from multiple Systemd-based initrds are streaming in simultaneously.
Fixes#318907.
Windows with BitLocker and TPM enabled doesn't support boot chaining.
This option activates a special experimental mode in systemd-boot that
tries to detect such systems and, if detected and selected by the user
at the boot menu, set the BootNext EFI variable to it before resetting.
The [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/)
allows for using a key called "devicetree" for specifying which
devicetree the bootloader should use during boot. With regards to
systemd-boot, this key is used to specify which file should be picked up
from the ESP to install to the EFI DTB Configuration Table. Linux then uses
this Configuration Table to setup the machine. This change is similar to
the one done in https://github.com/NixOS/nixpkgs/pull/295096, where that
change was for adding DTB support to systemd-stub, and this is for
systemd-boot.
Regardless of mutable or immutable users, systemd-sysupdate never
updates existing user records and thus will for example never change
passwords for you.
It only support initial passwords and now actively asserts agains other
paswords.
On Linux we cannot feasbibly generate users statically because we need
to take care to not change or re-use UIDs over the lifetime of a machine
(i.e. over multiple generations). This means we need the context of the
running machine.
Thus, stop creating users statically and instead generate them at
runtime irrespective of mutableUsers.
When /etc is immutable, the password files (e.g. /etc/passwd etc.) are
created in a separate directory (/var/lib/nixos/etc). /etc will be
pre-populated with symlinks to this separate directory.
Immutable users are now implemented by bind-mounting the password files
read-only onto themselves and only briefly re-mounting them writable to
re-execute sysusers. The biggest limitation of this design is that you
now need to manually unmount this bind mount to change passwords because
sysusers cannot change passwords for you. This shouldn't be too much of
an issue because system users should only rarely need to change their
passwords.
systemd-sysusers cannot create normal users (i.e. with a UID > 1000).
Thus we stop trying an explitily only use systemd-sysusers when there
are no normal users on the system (e.g. appliances).
The activation script that remounts the /etc overlay now handles other
mount points on top of /etc by bind mounting them to the new temporary
/etc overlay and then atomically revealing it.
One of the main premises of NixOS is being able to declaratively specify
the services enabled/running on a machine. Since systemd presets allow
to bypass this this declarative nature, add a single preset with the
highest priority (prefixed with "00") that makes systemd ignore all
other presets.
If we let systemd setup /etc/machine-id, we get to use
ConditionFirstBoot in systemd units and any other integrations related
to systemd's detection of first boot. See machine-id(5).
Fix regular expression used to get bootloader versions from bootctl status.
This avoids problems that occur in minor environments like mine.
References: #296563
we have a zoo of ways to call subprocesses.
Let's just replace this with one function that has reasonable defaults.
i.e. I catched instances where commands where run in a shell.
When `services.resolved` is enabled, then `resolve [!UNAVAIL=return]`
is added to `system.nssDatabases.hosts` with priority 501,
which prevents lower-priority NSS modules from running
unless systemd-resolved is not available.
Quoting from `man nss-resolve`:
> To activate the NSS module, add "resolve [!UNAVAIL=return]" to the line
> starting with "hosts:" in /etc/nsswitch.conf. Specifically, it is
> recommended to place "resolve" early in /etc/nsswitch.conf's "hosts:"
> line. It should be before the "files" entry, since systemd-resolved
> supports /etc/hosts internally, but with caching. To the contrary, it
> should be after "mymachines", to give hostnames given to local VMs and
> containers precedence over names received over DNS. Finally, we
> recommend placing "dns" somewhere after "resolve", to fall back to
> nss-dns if systemd-resolved.service is not available.
Note that the man page (just) recommends "early" and means with this
"before the 'files' and 'dns' entries". It does not insist on being
first or excluding other modules.
For this reason, libvirt NSS modules should run before the `resolve`
module. They should come right next to `mymachines` because both are
conceptually very similar -- they resolve local VMs/containers.
Since the data source of the libvirt NSS modules are local
plain text files (see source code of the libvirt NSS module),
no performance impact is expected form this raise of priorities.
Other NSS modules in NixOS also explicitly set their priority, which is
why this change increases consistency.
Fixes#322022
Any future behavioral modifications to switch-to-configuration should
also be made to switch-to-configuration-ng. Leave a note at the top of
the script to ensure people don't forget.
These messages should be able to be printed in all cases. In particular, trying to coerce a `null` to a string is an error unless passed through `toString`.
This patch is about removing `wireguardPeerConfig`,
`dhcpServerStaticLeaseConfig` - a.k.a. the
AbstractSingletonProxyFactoryBean of nixpkgs - and friends.
As a former colleague said
> worst abstraction ever
I second that. I've written enough networkd config for NixOS systems so
far to have a strong dislike. In fact, these don't even make sense:
`netdevs.wireguardPeers._.wireguardPeerConfig` will be rendered into
the key `[WireGuardPeer]` and every key from `wireguardPeerConfig` is in
there. Since it's INI, there's no place where sections on the same level
as wireguardPeerConfig fit into. Hence, get rid of it all.
For the transition, using the old way is still allowed, but gives a
warning. I think we could drop this after one release.
The tests of rosenpass and systemd-networkd-dhcpserver-static-leases
were broken on the rev before, hence they were updated, but are still
not building.
This adds an implementation of switch-to-configuration that allows for
closer interaction with the lifecycle of systemd units by using DBus
APIs directly instead of using systemctl. It is disabled by default, but
can be enabled by specifying `{ system.switch = { enable = false; enableNg = true; }; }`.
This fixes the usage of fonts whose filenames contain special
characters of various sorts.
For example, the setting
```nix
boot.plymouth.font =
"${pkgs.noto-fonts}/share/fonts/noto/NotoSans[wdth,wght].ttf";
```
will cause a build failure, without this patch.
and turn it in to a list.
The current setting of system.forbiddenDependenciesRegex is a string, meaning only one such regex as any additional setting would result in conflicts.
As maintainers have already started using this setting eg. in profiles, it would be good if this setting would accept a list of regex to allow the end
user to make use of it in addition to package maintainers.
Closes#233865. Currently, the documentation for `boot.loader.grub.theme` misleadingly implies that it needs a package for a grub theme instead of a path to a grub theme.
This allows us to set things like dependencies in a way that we can
catch typos at eval time.
So instead of
```nix
systemd.services.foo.wants = [ "bar.service" ];
```
we can write
```nix
systemd.services.foo.wants = [ config.systemd.services.bar.name ];
```
which will throw an error if no such service has been defined.
Not all cases can be done like this (eg template services), but in a lot
of cases this will allow to avoid typos.
There is a matching option on the unit option
(`systemd.units."foo.service".name`) as well.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
This option makes it easier to reuse a system's ukify.conf without the
need for manually calling the generator on `settings` again to receive a
rendered configuration file.
Theoretically, a complete configuration file could now be provided by
users.
Running systemd-timesyncd with an empty list of timeservers to sync from
does not work.
In case an empty list is configured here, systemd will fall back to its
compiled-in defaults, which NixOS sets to `{0..4}.nixos.pool.ntp.org`,
as per https://github.com/systemd/systemd/blob/main/docs/DISTRO_PORTING.md#ntp-pool
This has caused some confusion. Explicitly document this, and describe
how to disable timesyncd.
We need to make sure systemd-tmpfiles-setup.service ran before we
start systemd-binft.service. Otherwise it might fail to start
due to non-existant files
Fixes#295365
This ensures a ".dtb" PE section makes it into the UKI so systemd-stub
can install the correct devicetree for use by the Linux kernel. This is
often needed on systems that boot with u-boot since the devicetree used
by u-boot is often a paired down version of what the Linux kernel needs.
On those kinds of boards, the lack of this PE section means that u-boot
will end up installing its internal devicetree into the UEFI
configuration table, which is what the Linux kernel ends up using.
Without sort-keys specified on entries, the entries are sorted only by
file name (in decreasing order, so starting at the end of the alphabet!),
without taking any other fields into account (see
[the boot loader specification reference][1]).
Moreover, entries without a sort-key are always ordered after all
entries with a sort-key, so by not adding a sort-key to the NixOS ones,
we cannot add a sort-key to any other entry while keeping it below the
NixOS entries.
So currently we have options to set the file names for additional entries like
memtest and netbootxyz.
However, as mentioned above, the sorting by file name is not very intuitive and
actually sorts in the opposite order of what is currently mentioned in the option
descriptions.
With this commit, we set a configurable sort-key on all NixOS entries,
and add options for setting the sort-keys for the memtest and netbootxyz
entries.
The sorting by sort-key is more intuitive (it starts at the start of the
alphabet) and also takes into account the machine-id and version for entries
with identical sort-keys.
We use a bootspec extension to store the sort keys, which allows us to
redefine the sort key for individual specialisations without needing any
special casing.
[1]: https://uapi-group.org/specifications/specs/boot_loader_specification/#sorting
The maximum length for a GPT label supported by systemd is 36
characters. When a repart definition contains a label that is longer
than the supported maximum length, it is ignored by systemd-repart and
a log message is produced.
The new assertion makes this obvious to the user at evaluation time,
allowing them to either drop the property entirely or choose a supported
label within the length limit instead.
Since we are not in a `callPackage` context, dependencies in
`nativeBuildInputs` don't get spliced to the buildPlatform, causing a
cross-compiled nixos system to fail at this step when running mypy built
for the hostPlatform.
Before there was a kernel modules path named kernel-modules which then got turned
into linux-X.X.XX-modules-shrunk. Now the unshrunk package is called linux-X.X.XX-modules
and gets turned into X.X.XX-modules-shrunk.
this lets us *dis*able filesystem explicitly, as is required by e.g. the
zfs-less installer images. currently that specifically is only easily
possible by adding an overlay that stubs out `zfs`, with the obvious
side-effect of also removing tooling that could run without the kernel
module loaded.
These should be defaults as they're pretty reasonable to want to
override as a user. Unsure how to change the slice defaults to be
overridable, that should probably be a later conversation.
Lists are convenient to have in sysupdate configuration when using
multiple `MatchPattern` under `Target` when the target can have multiple
filenames. This use-case is helpful for BootLoaderSpec bootcounting where the target file on
disk can have multiple filenames, and in order for sysupdate to properly
ensure only N number of instances of this target exist at one time, we
need to have multiple match patterns.
Previously any user-provided config for boot.uki.settings would need to
either specify a full set of config for ukify or a combination of
mkOptionDefault to merge the "settings" attribute set with the module's
defaults and then mkOverride or mkForce to override a contained
attribute.
Now it is possible to trivially override parts of the module's default
config, such as the initrd or kernel command line, but overriding the
full set of settings now requires mkOverride / mkForce.
There were several modules, critically including NetworkManager, which
were not prepared for this change. Most of the change was good,
however. Let's bring back the dependency and change the assertion to a
warning for now.
