When the option list is empty, the fstab generator does not
automatically add "defaults" and generates a non-working fstab (since it
just emits two spaces around where the options would have been which is
only technically one fstab separator).
According to a ZFS issue about hibernation causing data corruption:
https://github.com/openzfs/zfs/issues/12842
The way this happens is if the system force imports a pool that was
suspended during hibernation. I've had this happen twice on NixOS and
I'd like to avoid having this happen again, to me or others.
To do this I've added an assertion that makes sure you can't have
`forceImportRoot` or `forceImportAll` enabled with `allowHibernation`.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Version 251.6 of systemd introduced a small change[1] that now checks
whether the fsck command is available in *addition* to the filesystem
specific fsck.$fsname executable.
When bumping systemd to version 251.7 on our side[2], we introduced that
change. This subsequently caused our "fsck" test to fail and it looks
like this was an oversight during the pull request[3] introducing the
bump.
Since the fsck wrapper binary is in util-linux, I decided to address
this by adding util-linux to fsPackages because util-linux is already
part of the closure of any NixOS system so the impact should be pretty
low.
[1]: 73db7d9932
[2]: 844a08cc06
[3]: https://github.com/NixOS/nixpkgs/pull/199618
Signed-off-by: aszlig <aszlig@nix.build>
This change fixes this system journal warning for
`fileSystems.<name>.fsType = "nfs4"` configurations:
systemd-fstab-generator[714]: Checking was requested for "192.168.0.6:/data", but it is not a device.
Some mount options might include path names and those often contain spaces and
therefore must be escaped. An example which prompted me to make this change is
the path of a btrfs subvolume.
most of these are hidden because they're either part of a submodule that
doesn't have its type rendered (eg because the submodule type is used in
an either type) or because they are explicitly hidden. some of them are
merely hidden from nix-doc-munge by how their option is put together.
conversions were done using https://github.com/pennae/nix-doc-munge
using (probably) rev f34e145 running
nix-doc-munge nixos/**/*.nix
nix-doc-munge --import nixos/**/*.nix
the tool ensures that only changes that could affect the generated
manual *but don't* are committed, other changes require manual review
and are discarded.
While it might seem odd, 0.0.0.0/0 or ::/0 gateways are valid and
commonly used on point-to-point links (e.g. a wireguard tunnel) to
indicate that all traffic needs to be sent to a given interface.
systemd-networkd actually documents this as a valid configuration in its
man pages [1].
Tested to do the right thing in one of my NixOS containers using
a Wireguard tunnel as its default route.
[1] https://www.freedesktop.org/software/systemd/man/systemd.network.html#DefaultRouteOnDevice=
...if cfgExpandOnBoot == "all", otherwise it fails during runtime:
```
Aug 06 19:38:05 nixos zpool-expand-pools-start[981]: /nix/store/ka3vivdray82mi9dql12yf258gkw643l-unit-script-zpool-expand-pools-start/bin/zpool-expand-pools-start: line 3: zpool: command not found
```
This commit prevents warning messages like
```
systemd-fstab-generator: Checking was requested for "/path/to/device", but it is not a device.
```
in `dmesg` when one of the filesystems 9p, cifs, prl_fs or vmhgfs is added to the list of `fileSystems`.
This happens because the generated /etc/fstab entry contains a non-zero fsck pass number, which doesn't make sense for these filesystems.
now nix-doc-munge will not introduce whitespace changes when it replaces
manpage references with the MD equivalent.
no change to the manpage, changes to the HTML manual are whitespace only.
