This makes it so that the getty units are only included if
`config.console.enable` is set to `true`. Previously, they would be
included, but disabled in that case, which is unnecessary.
The assertion is based on the availability of `move-mount-beneath`, which is only used in re-activation logic for switchable systems. Systems that have `system.switch.enable == false` should be allowed to user older kernels.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
As it helps making deps easier to discover - as we don't currently
render submodule options in the module correctly - and is arguably
more technical correct: When using nixos-install to install nixos
into a chroot in i.e. /mnt, there's no gurantee that /mnt/dev exists
before the specialfs phase ran.
On recent kernels (> 6.12 ?) we get the following warning otherwise:
`mount: /tmp/nixos-etc-metadata.aHpRhO5sC4: WARNING: source write-protected, mounted read-only.`
Previously, if any unit had a socket associated with it, stc-ng
counted it as "socket-activated", meaning that the unit would get
stopped and the socket get restarted. That can wreak havoc on units
like systemd-udevd and systemd-networkd.
Instead, let units set the new flag notSocketActivated, which sets a
boolean on the unit indicating to stc-ng that the unit wants to be
treated like any other non-socket-activated unit instead. That will
stop/start or restart these units on upgrades, without unnecessarily
tearing down any machinery that the system needs to run.
Add an option for shell script fragments that are ran before switching
to a new NixOS system configuration (pre installation of bootloader or
system activation). Also add a new subcommand for
switch-to-configuration called "check" that will cause the program to
always exit after checks are ran.
See https://github.com/systemd/systemd/issues/33414.
The way this was phrased sounded like a dumb search/replace operation to
me. This resulted in random parts of my routing being broken (forward
from if X -> Y being fine, but the opposite direction being broken).
This change makes it explicit that it's a little more complicated and
you should really consult the docs before making that change.
Now it's placed between initrd-switch-root.target and
initrd-switch-root.service, meaning it is truly the last thing to
happen before switch-root, as it should be.
Reverts #344407
This has broken nixos-rebuild switch so that it no longer updates the profile, which has bad consequences including not updating the systemd-boot menu with new generations.
Originally, we switched to bsdtar from libarchive to solve a reproducibility issue related to hardlinks
As of gnu cpio 2.14 the --ignore-dirnlink option is introduced and now included in --reproducible, which solves this issue
By switching back, we are in turn solving an issue in libarchive >=3.7.5 erroring out with "Error reading archive -: (null)"
Change-Id: Ib6140d599b6547d8e941b0251ce996e303c41fa6
Prior to this contribution, every boot with a default configuration was
considered `ConditionFirstBoot=true` by systemd, since /etc/machine-id
was not commited to disk.
This also extends the systemd with a check for subsequent boots not
being considered first boots.
The perl snippet as been added years ago. I assume the intention was to
remove the `## file: iwlwifi.conf` section up to the next `## file:`,
but as there is no file following, the snippet currently does nothing.
We should be fine to remove it.
Signed-off-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
Before this change, the hash of the etc metadata image was included in
the mount unit that's responsible for mounting this metadata image in the
initrd.
And because this metadata image changes with every change to the etc
contents, the initrd would be rebuild every time as well.
This can lead to a lot of rebuilds (especially when revision info is
included in /etc/os-release) and all these initrd archives use up a lot of
space on the ESP.
With this change, we instead include a symlink to the metadata image in the
top-level directory, in the same way as we already do for things like init and
prepare-root, and we deduce the store path from the init= kernel parameter,
in the same way as we already do to find the path to init and prepare-root.
Doing so avoids rebuilding the initrd all the time.
When installing NixOS on a machine with Windows, the "easiest" solution
to dual-boot is re-using the existing EFI System Partition (ESP), which
allows systemd-boot to detect Windows automatically.
However, if there are multiple ESPs, maybe even on multiple disks,
systemd-boot is unable to detect the other OSes, and you either have to
use Grub and os-prober, or do a tedious manual configuration as
described in the wiki:
https://wiki.nixos.org/w/index.php?title=Dual_Booting_NixOS_and_Windows&redirect=no#EFI_with_multiple_disks
This commit automates and documents this properly so only a single line
like
boot.loader.systemd-boot.windows."10".efiDeviceHandle = "HD0c2";
is required.
In the future, we might want to try automatically detecting this
during installation, but finding the correct device handle while the
kernel is running is tricky.
This reverts commit 4daccf208f
The reverted commit claims that bootctl fails if machine-id is not set.
I can not reproduce this. I think this has since been fixed now that
bootctl has support for arbtirary entry-tokens and not just machine-id.
In the case of NixOS the entry-token is the string "nixos"
systemd 256 supports network.wireguard.* credentials (https://github.com/systemd/systemd/pull/30826).
Check whether PrivateKey / PresharedKey starts with an @, if so it is a credential.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Move replaceRuntimeDependencies to the replaceDependencies namespace,
where the structure is more consistent with the replaceDependencies
function. This makes space for wiring up cutoffPackages as an option
too.
By default, the system's initrd is excluded. The replacement process does not
work properly anyway due to the structure of the initrd (the files being copied
into it, and it being compressed). In the worst case (which has been observed
to actually occur in practice), a store path makes it into the incompressible
parts of the archive, checksums are broken, and the system won't boot.
Instead of iterating over all replacements and applying them one by one,
use the newly introduced replaceDependencies function to apply them all
at once for replaceRuntimeDependencies. The advantages are twofold in
case there are multiple replacements:
* Performance is significantly improved, because there is only one pass
over the closure to be made.
* Correctness is improved, because replaceDependencies also replaces
dependencies of the replacements themselves if applicable.
Fixes: https://github.com/NixOS/nixpkgs/issues/4336
tpm2.target was functionally useless without these services and this
generator. When systemd-cryptsetup-generator creates
systemd-cryptsetup@.service units, they are ordered after
systemd-tpm2-setup-early.service, not tpm2.target. These services are
themselves ordered after tpm2.target.
Note: The systemd-tpm2-setup(-early) services will serve no *function*
under a normal NixOS system at the moment. Because of their
ConditionSecurity=measured-uki, they will always be skipped, unless
you are building an appliance with the system.build.uki feature. Thus,
these are enabled solely for their systemd unit ordering properties.
Avoid running Python scripts in the root of the package, as this
triggers `os.listdir` on the Nix store directory during import. This
operation can be time-consuming on large store directories
(see issue #283795 for more details).
The issue was initially fixed in #284153 but was reverted in #306339.
Co-authored-by: Sönke Hahn <soenkehahn@gmail.com>
The Rust `switch-to-configuration-ng` rewrite was carefully written
to be compatible with the original Perl script, has been checked
against NixOS VM tests, and has been available on an opt‐in basis
for testing for the 24.05 release cycle.
The next step towards replacing the Perl script entirely is to
switch it on by default so that we can get real‐world testing from
a much greater number of users. Maintaining two implementations in
parallel is becoming a burden; we are having to adjust the systemd
service activation behaviour slightly to fix a long‐standing bug,
and backporting the changes to the Perl script is an unpleasant
process. We will do it anyway to ensure that the Rust and Perl
implementations keep parity with each other throughout the 24.11
release cycle, but we think the time has come to flip the switch.
Taking this step now will give us two to three months to test this in
the wild before the 24.11 release and gain confidence that there are
no regressions. If any non‐trivial problems arise before the final
release, we will revert to the Perl implementation by default. Doing
this switch ASAP will help to disentangle any problems that might
arise from the Rust implementation from problems that arise from the
systemd service activation changes, or the upcoming switch to using
systemd in stage 1 by default.
The main concern that was raised about replacing the Perl script in the
PR that added `switch-to-configuration-ng` was that it is currently
possible to run NixOS on systems that cannot natively host a Rust
compiler. This does not apply to any platforms that have official
support from NixOS, and as far as I know we do not know of any such
systems with users that are not cross‐compiling anyway.
My understanding is that these systems are already broken by default
anyway, as `systemd.shutdownRamfs.enable` is on by default and uses
`make-initrd-ng`, which is also written in Rust. Switching the default
while keeping the Perl implementation around will give us at least
an entire release cycle to find out if there are any users that will
be affected by this and decide what to do about it if so.
There is currently one known inconsistency between
the Perl and Rust implementations, as documented in
<https://github.com/NixOS/nixpkgs/issues/312297>; the Rust
implementation has more accurate handling of failed systemd units.
We slightly adjust the semantics of `system.switch.enable{,Ng}` to
not conflict with each other, so that `system.switch.enableNg` is
on by default, but turning off `system.switch.enable` still results
in no `switch-to-configuration` implementation being used. This
won’t break the configuration of anyone who already opted in to
`system.switch.enableNg` and is probably how the option should have
worked to begin with.
Otherwise we get a clash when generating the initrd since the initrd tmpfiles
options create a symlink at /etc/tmpfiles.d/ and any subsequent writes inside
this directory because of initrd.systemd.contents will cause a permission denied
error.
This gives the ability to not write `NTP=` to the `timesyncd.conf` file
(servers = null) as opposed to writing `NTP=` (servers = []) which is
interpreted slightly differently by systemd:
> When the empty string is assigned, the list of NTP servers is reset,
and all prior assignments will have no effect.
When using `lib.optionals`, the return value of both branches of the
condition get set as a value to the option.
When using `lib.mkIf`, only the positive condition gets set as a value
to the option.
This small distinction is important when dealing with precedence. For
example here, we wanted to set a boot.grub.devices default value with
lib.mkDefault, and that was getting overridden with the empty value of
`lib.optional (cfg.device != "") cfg.device`.
See https://github.com/nix-community/srvos/pull/491#discussion_r1738827651
The general conclusion is that using `lib.mkIf` is preferable to
`lib.optional` or `lib.optionals` when setting values in the NixOS
module system.
Use the store directory for the devicetree package containing the
desired DTB when installing to the ESP. This allows for more than one
NixOS generation containing differing DTBs to coexist on the same ESP
(similar to how we can have multiple kernels & initrds). This change
removes the assumption that the filepath passed to `copy_from_file` is a
file that lives at the toplevel of a nix output path (which prior to the
systemd-boot DTB support was the case for the kernel and initrd
derivations).
This should fix errors where /etc is reported to be busy and thus cannot
be unmounted.
Another solution we can consider if this doesn't work out as we expect
is to forcefully unmount /etc.
I've observed that sometimes the overlay mount unit does not get started
when using wantedBy. requiredBy makes this relationship stricter and if
necessary will restart the initrd-fs.target and thus ensure that when
this target is reached /etc has alredy been mounted. This is in line
with the description of initrd-fs.target in systemd.special:
> Thus, once this target is reached the /sysroot/ hierarchy is fully set up
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.
