When `config.boot.zfs.enableUnstable` is set to true, grub was built with the `zfs` package even though the rest of the system uses the `zfsUnstable` package.
The effect of this can only be seen when `zfs` and `zfsUnstable` actually differ (which is not currently the case), for example when overriding one of them locally.
This simplifies the setup to receive emails from the ZFS Event Daemon
by relying on the sendmail wrapper defined by other modules such as
msmtp or Postfix.
This is more similar to how other modules like smartd deal with email
configuration.
The user is no longer required to define and rebuild their own ZFS
package to add email support.
GitHub: closes https://github.com/NixOS/nixpkgs/issues/132464
In 759ec111 the ping setuid wrapper was removed in favour of giving
permissions to perform ICMP echo requests to all users.
The problem is that the systemd file that was supposed to change the
`net.ipv4.ping_group_range` sysctl is not always installed, specifically
only if systemd.coredump.enable.
In that case the range is "0 1", which is effectively restricts ping to
only root.
This change explicitely sets the range to "0 2^31-1", as systemd does.
I don't use this tool but saw it in the top level and that's not where it should
live.
This could arguably also be seen as a RAID; it's a bit of an in-between.
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).
