The `zfs` alias already has equivalent semantics. Instead, make this
like zfs_2_1 so folks who want to pin a specific release series can do
so easily and clearly to have more control over when more substantial
updates occur.
Rename all tests to match the pkg attr they are testing.
Let's test / on ZFS and /boot on ZFS in separate tests since the GRUB integration for ZFS seems to be not very well maintained.
If the test breaks in the future it's easier to figure out that ZFS on /boot is at fault and either fix the issue or disable the test.
The new test creates a ZFS pool where all features not compatible with GRUB2 are disabled. The dataset is then mounted on /boot and we check that the installer correctly generates a bootable configuration.
Try to use as many ZFS features as possible to verify that GRUB can handle them.
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.
It's better to utilize the boot process and systemd mechanisms to test
these zfs features, rather than manually simulating the same behavior
with testScript.
Right now, the latest kernel is version 5.19, for which there is no
compatible upstream release for ZFS. However, our NixOS VM test always
uses linuxPackages_latest and thus will fail with an evaluation error
most of the time when a new mainline kernel is released.
Since we expose a latestCompatibleLinuxPackages attribute for the ZFS
packages, we already know what's the latest kernel version that is
supported so let's use that instead of linuxPackages_latest.
Signed-off-by: aszlig <aszlig@nix.build>
