SnapRAID has a feature where you can specify "split" parity files. This
is useful when you're using 16tb or bigger ext4-formatted disks for
parity. ext4 doesn't support files bigger than 16tb so this "split
parity file" can be used to specify two parity files on a single parity
disk and SnapRAID will automatically use the subsequent file when the current
cannot grow anymore (hits 16TB). You specify these split parity files by
separating them with commas in the "parity" config option. This
mostly already works except when it comes to the scheduled systemd sync
job where it specifies ReadWritePaths. If you specify a parity with
multiple files you'll get an error when the systemd job runs: Failed to
set up mount namespacing:
/run/systemd/unit-root/mnt/parity1/snapraid1.parity,/mnt/parity1/snapraid2.parity: No such file or directory
Essentially, when the parity file paths are passed into ReadWritePaths,
they're always treated as a single path. This change makes sure to
split the paths if they contain a comma.
The big concern for this change is if it would break users who have
commas in their actual parity file paths. This won't be an issue because SnapRAID
itself blindly splits on commas for parity files, so legitimate commas in a parity
file path wouldn't work in SnapRAID anyway. See here:
978d812153/cmdline/state.c (L692)
SnapRAID doc for split parity files: https://www.snapraid.it/manual#7.1
This re-introduces the old stable ZFS version we had in the past following
the many predicted issues of ZFS 2.2.x series, that is much more stable
than any further ZFS version at the moment.
I am also removing myself from maintenance of any further ZFS versions as I am
planning to quit ZFS maintenance at some point.
In the meantime, for users like me who depend on ZFS for critical operations, here is a ZFS version
that is known to work for LTS kernels.
When using iproute2's ip binary, you can omit the dev parameter, e.g. ip link set up eth0 instead of ip link set up dev eth0.
This breaks if for some reason your device is named e.g. he, hel, … because it is interpreted as ip link set up help.
I just encountered this bug using networking.bridges trying to create an interface named he.
I used a grep on nixpkgs to try to find iproute2 invocations using variables without the dev keyword, and found a few, and fixed them by providing the dev keyword.
I merely fixed what I found, but the use of abbreviated commands makes it a bit hard to be sure everything has been found (e.g. ip l set … up instead of ip link set … up).
The networkd backend logic for setting DHCP= on an interface is bugged
and inconsistent with the scripted logic. Consider this simple NixOS
configuration:
{
networking.useNetworkd = true;
networking.interfaces.eth0.wakeOnLan.enable = true;
}
The default value of networking.useDHCP is true, so we expect our eth0
interface to have DHCP enabled. With the scripted backend, this works.
But the networkd backend generates the following 40-eth0.network file:
[Match]
Name=eth0
[Network]
DHCP=no
IPv6PrivacyExtensions=kernel
This is happening because the wakeOnLan configuration creates a key in
networking.interfaces, and the networkd backend erroneously checks that
instead of for explicitly configured IP addresses as in the scripted
backend. The documentation is also inconsistent across various options.
This change aligns the networkd backend and option documentation to the
actual behavior of the scripted backend, and updates a test to account
for this behavior for both backends.
WakeOnLan= was configured when using the scripted backend but not the
networkd backend. The other link options are set in the .network file
when using networkd, but WakeOnLan= is only available in a .link file.
The logic for configuring a gateway without an interface specified adds
a route with Gateway= to *every interface* configured by NixOS for
networkd. This leads to nonsensical configurations like the following:
[Network]
DHCP=no
Address=192.168.0.1/24
[Route]
Gateway=10.0.0.1
GatewayOnLink=false
We remove this logic and make defaultGateway.interface required to
configure a default gateway when using networkd.
We can ignore the removal of GatewayOnLink because systemd defaults it
to "no" anyway.
When interface and address are both specified, we can set Gateway= on
the named interface. The existing logic assumes interface is not set
(since it's guarded by assertion) so we now disable it when interface
has a value.
As a bonus, we now support the defaultGateway.metric option when
interface is set.
A further bug to our strange multi-user.target depending on
network-online.target issue is that systemd recently changed the
behaviour of systemd-networkd-wait-online to no longer consider the
absence of interfaces with RequiredForOnline to be sufficient to be
online: https://github.com/systemd/systemd/pull/27825
On the advice of the systemd developers
(https://github.com/systemd/systemd/issues/29388), this commit changes
the configuration of systemd-networkd-wait-online to pass --any by
default, and lets the default DHCP interfaces be RequiredForOnline
as they would be by default if the option is omitted.
It is plausible that systemd-networkd-wait-online may still fail if
there are no interfaces at all. However, that probably cannot be
avoided.
systemd.network(5) describes Domains= as a "list of domains which should
be resolved using the DNS servers on this link." This setting is read by
systemd-resolved.service, and it's used to configure both search domains
and DNS query routing.
Adding the search domains from `networking.search` is unnecessary
because these are already configured globally in `resolved.conf` through
the default value of `services.resolved.domains`.
Adding the system's `networking.domain` to each network is unexpected
and probably incorrect. A user may not expect that the domain is in
effect automatically added to the search domains even if not specified
in `networking.search`.
Both of these network-level assignments are problematic in cases where
the NixOS networkd module is not managing every interface on the system.
In that scenario, the managed interfaces will have Domains= set while
the others do not. That will cause systemd-resolved to route DNS queries
for the search domains and the system domain to only those managed
interfaces.
Adds an option to configure a custom WakeOnLan policy instead of the
hard-coded "magic" policy. To ensure compatibility with current
behavior, "magic" is kept as default.
From systemd 243 release note[1]:
This release enables unprivileged programs (i.e. requiring neither
setuid nor file capabilities) to send ICMP Echo (i.e. ping) requests
by turning on the "net.ipv4.ping_group_range" sysctl of the Linux
kernel for the whole UNIX group range, i.e. all processes.
So this wrapper is not needed any more.
See also [2] and [3].
This patch also removes:
- apparmor profiles in NixOS for ping itself and the wrapped one
- other references for the wrapped ping
[1]: 8e2d9d40b3/NEWS (L6457-L6464)
[2]: https://github.com/systemd/systemd/pull/13141
[3]: https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
The default just recently changed in 23.11. Users that had
swraid enabled implicitly by NixOS in previous releases got surprised
by warnings even though they do not actually use software RAID.
Fixes #254807
My system does not use `bcache` and I sould prever my `systemPackages`
not to have bcache tools.
The change does not change the default but proviced usual `enable` knob.
This change includes some stuff (e.g. reading of the `.real` file,
execution of the wrapper's target) that belongs to the apparmor policy
of the wrapper. This necessitates making them distinct for each wrapper.
The main reason for this change is as a preparation for making each
wrapper be a distinct binary.
Being wanted by and ordered before local-fs.target isn't strictly
correct. And in systemd initrd, it's very incorrect because
local-fs.target is for the initrd file system, not the real root file
system.
swraid support will now only be enabled by default if stateVersion is
older than 23.11. nixos-generate-config will now generate explicit
config for enabling support if needed.
Only trigger the privacy address override for a given interface when
that interface is added. Without restricting the rule to the
interface, this command would be run when any interface is added.
a zfs fileSystems entry with an absolute (e.g. device) path rather than
a zfs dataser is parsed as an empty pool name, causing a doomed-to-fail
import job to be created as a boot dependency. Catch this as an assertion
There is apparently a bug in the parser of iproute2 where the command
`ip link show <devname>` will not show the device but list all
interfaces (equivalent to `ip link show`) if devname is equal to one of
the flags of `ip-address(8)`. For example, `home`, or `optimistic`.
This bug causes a false positive in the clean up command of the
<devname>-netdev.service, the service fails and the interface is never
configured.
To avoid the bug we can simply use `ip link show dev <devname>`.
it is now possible to supply a stratis pool uuid
for every filesystem, and if that filesystem
is required for boot, the relevant pool will be
started in the initramfs.
Currently systemd-ask-passwd times out after 1m30s. After 3 tries this
causees systemd to enter the emergency shell and basically lead to an
unbootable system requiring a reboot to be able to try to unlock again.
Also if a pool is imported but not unlocked, the unlock step will no
longer be skipped.
