There is no canonical way to set a system domain name any longer. The one
we previously used was the NIS/YP one, but that is pointless these days.
The hostname is set up through /etc/hostname, but hostname(5) states that
it should only contain 64 7-bit ASCII characters, so it cannot be used
to cover the domain name.
We still support setting the domain name to complete the `fqdn` option
and as a central option to reference the domain name from. If anyone
wants a NIS/YP domain name set, do it yourself..
We then clarify that the domain option has nothing to do with DNS
resolution anymore and search should be configured instead.
Finally explain the purpose of the ndots option in the context of search
domains, since they decide when we stop considering the search domains
when querying names with more than one dot.
The `domainname` utility uses setdomainname (see getdomainname(2)) to
configure the NIS[1] (also known as YP) domain name.
It provided a central directory for various objects that are resolved via
nsswitch in the late 1990s and early 2000s.
It is however not a safe nor common deployment scenario anymore.
[1] https://en.wikipedia.org/wiki/Network_Information_Service
This is first and foremost to provide compat with scripts that call the
hostname executable to retrieve the hostname, an assumptions we probably
should not be breaking.
This will allow unlocking to take place *after* all of the devices have
been probed, as indicated by the x-systemd.wants and x-systemd.requires
options. This allows for multi-device bcachefs volumes to be reliably
unlocked.
Kernel 6.16-rc1 removed the poly1305 algorithm in
ceef731b0e22df80a13d67773ae9afd55a971f9e
bcachefs switched to the kernel libraries for poly1305 and chacha20 in
6.15 in 4bf4b5046de0ef7f9dc50f3a9ef8a6dcda178a6d
When auto-upgrading based on a flake, it might be desirable to
only upgrade to the newer flake, without updating the nixpkgs
from the flake lock. This option makes that possible.
Thank you for making this change.
Unfortunately, and I take blame for this, this change to the module
system was not reviewed and approved by the module system maintainers.
I'm supportive of this change, but extending it on the staging-next
branch is not the right place.
This commit is also here to make sure that we don't run into conflicts
or other git trouble with the staging workflow.
Review:
It looks alright, but it didn't have tests yet, and it should be
considered in a broader context where the existence of this type
creates an incentive to be used in cases where the `<attr> = false;`
case is undesirable. I'd like to complement this with an type that
has `<attr> = {};` only.
My apologies for the lack of a timely and clear review. Often we
recommend to define the type outside the module system until
approved. This commit puts us back in that state.
attrNamesToTrue was introduced in 98652f9a90
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Otherwise, when doing nixos switch to major changes (typically when stdenv changes), udevd service gets loaded after addresses, which causes addresses service to wait indefinitely for the device and fail.
Signed-off-by: Egor Savkin <es@m-labs.hk>
`lib.all (_: false) [ ]` is `true`, which is not the semantics we want
here, and interacts poorly with `boot.zfs.extraPools` where
`getPoolFilesystems` may return `[]`. So explicitly handle this case.
This does mean there isn’t a straightforward way to disable auto-import
with `extraPools` and no associated `fileSystems` while keeping the unit
around, but that’s probably okay for now.
See https://github.com/NixOS/nixpkgs/issues/364995.
Broken in 7f8278a264.
This requires all datasets for the pool specified in `fileSystems` to be
marked noauto.
Note that this implicitly skips some tasks for the pool, such as
`expandOnBoot`, as the pool will not be imported at that time.
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
Before this change, when both device and label were set, the label would
be silently ignored. This is especially problematic when the device is
set in another module, and it's not immediately obvious why the label is
not having any effect.
Additionally, some other modules use the device option to get the device
of a filesystem, but this option is not populated when only the label is
set, causing those modules to conclude that the filesystem does not have
a backing device.
With this change, we populate the device option using the label when the
label is set. This means that we get a clear error message when both the
device and label are set, and that the device is properly populated
whenever the label is used to specify the backing device.
This changes the following chain after `nixos-rebuild switch` with modified tunnel interfaces:
stop network-setup -> stop TUN-netdev -> stop network-addresses-TUN -> start network-addresses-TUN (fails since it depends on TUN-netdev which is off).
Chain after this change:
stop TUN-netdev -> stop network-setup -> stop network-addresses-TUN -> start TUN-netdev -> start network-addresses-TUN -> start network-setup
Signed-off-by: Egor Savkin <es@m-labs.hk>
`pkgs.zfs_unstable` is pre-release software and may very well have
critical bugs that make it unsuitable for general use. As such, we
should not recommend it as a general solution to the problem of "my
Kernel is too new for stable ZFS".
The fully-qualified name would certainly be a lot here, but `with` can
still be unclear even with narrow scope. A short `let` adds clarity
without significantly increasing verbosity.
This was incorrectly getting `lib.version` which is e.g.
`"24.11pre-git"`, but should have been the ZFS package version. However,
the condition, at least per the comment, is reversed and should be
instead `versionOlder cfgZfs.package.version "2.2.0"`. However, the
entire premise seems to be incorrect, as ZFS 2.2.6 includes the spl
module. Since the previous condition here was effectively always true,
it would initially seem the best move is to remove the conditional
altogether and always include the spl kmod. However, going back to
4360a87c45 where this condition was added,
the intent appears to be that spl was no longer needed here in
the-pre-release ZFS (long since in all supported versions), due to it
being merged into ZFS mainline. Given that intent and that our boot
tests on all versions succeed without including it in the initrd, remove
it.
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"
```
