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.
Enable using an erofs filesystem as one of the filesystems needed to
boot the system. This is useful for example in image based deployments
where the Nix store is mounted read only.
[erofs](https://docs.kernel.org/filesystems/erofs.html) offers multiple
benefits over older filesystems like squashfs. Skip fsck.erofs because
it is still experimental.
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.
