zfs: revamp and test compatible Kernel versions

[amarshall]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[adamcstephens]

@ofborg build zfs_2_1 zfs_unstable

[amarshall]

Rebased, resolved conflicts, reformatted, re-ran tests. I also removed amarshall@bc6f676 from this for now, as I’m not really sure it’s necessary anymore (and easy enough add back or PR later).

[amarshall]

@adamcstephens Thoughts here? Would really like this to be able to reduce how much one has to proactively think about Kernel versions when doing ZFS package updates.

[adamcstephens]

I’ll take a look at the few pending PRs this weekend. Sorry for the delay.

[adamcstephens]

Could we make this a boolean instead? something like ignoreKernelCompatibility

[amarshall]

We could, but I suppose it’s useful to be able to mark as broken when it fails to build at all on newer Kernel versions, even on zfs_unstable. At least, this is what the previous kernelCompatible meant for zfs_unstable.

[amarshall]

Any additional thoughts? Also rebased, resolved conflicts, and re-ran tests.

[adamcstephens]

Where should we document overriding this, to allow building outside the limits?

[amarshall]

My initial thought is that it’s just for zfs_unstable (as we’ve implicitly had this in the past, but now with this the “…MaxSupported…` is verified against the code, so isn’t sufficient). But I’m also fine with adding it to the wiki, along with the other unsupported-or-not-recommended-but-doable stuff.

[amarshall]

Rebased and resolved merge conflicts.

[adamcstephens]

FYI, upstream is now hard failing on incompatible versions during configure.

openzfs/zfs@410287f

[amarshall]

I think the only thing that changes is that now this needs to set --enable-linux-experimental for zfs_unstable? Or I guess whenever kernelMaxBuildableMajorMinor != kernelMaxSupportedMajorMinor, or something else? I don’t think it changes wanting these changes in general, since it does make testing the Nix-side compat specification of meta.broken any easier (as far as I can tell anyway). Does that match your thinking?

[amarshall]

Updated for upstream changes with the flag. Since upstream now explicitly prevents building by default with unsupported Kernel versions and we also don’t support doing so, this is opt-in only and not even zfs_unstable will have it (after all, the flag has been needed to build against unsupported Kernels for several months and we haven’t had it and no one has complained afaik).

[wolfgangwalther]

Re-running CI due to a odd failure fixed in #416448

[georgewhewell]

Updated for upstream changes with the flag. Since upstream now explicitly prevents building by default with unsupported Kernel versions and we also don’t support doing so, this is opt-in only and not even zfs_unstable will have it (after all, the flag has been needed to build against unsupported Kernels for several months and we haven’t had it and no one has complained afaik).

fwiw i've many times had to force nixos to build zfs on unsupported kernel to support new hardware or apply patches and i imagine i will do again. +1 for making this easier- maybe even worth adding documentation how to do this

[adamcstephens]

I think we should merge this, but the conflict will need to be resolved first.

[amarshall]

Resolved conflicts.

[akirak]

@amarshall This PR has dropped support for ZFS on Linux 6.15, which had been previously working. OpenZFS officially supports 6.15:

https://endoflife.date/openzfs

I think the value of kernelMaxSupportedMajorMinor should have been 6.16 here:

https://github.com/amarshall/nixpkgs/blob/5d2750268b5a9464354645382d5a9d63ac0ec09f/pkgs/os-specific/linux/zfs/unstable.nix#L13

[amarshall]

This PR has dropped support for ZFS on Linux 6.15

What makes you think that? nix-instantiate --eval -A linuxKernel.packages.linux_6_15.zfs_2_3.meta.broken shows
false on current master.

I think the value of kernelMaxSupportedMajorMinor should have been 6.16 here:

No, it should be 6.15. The attr is now the actual max supported version (≤) not the next biggest (<).

[adamcstephens]

The latest kernel is now 6.16, perhaps that's the issue?

On master:

𑁱 nom build -f . linuxKernel.packages.linux_6_15.zfs_2_3 --print-out-paths
Finished at 14:12:37 after 6s
/nix/store/h3wqx846byvzijr9922wq068gx48alqa-zfs-kernel-2.3.3-6.15.9

𑁱 nom build -f . linuxPackages_latest.zfs_2_3 --print-out-paths
error:
<SNIP>
       error: Package ‘zfs-kernel-2.3.3-6.16’ in /home/adam/git/nixpkgs/pkgs/os-specific/linux/zfs/generic.nix:324 is marked as broken, refusing to evaluate.

[akirak]

The latest kernel is now 6.16, perhaps that's the issue?

You are right. After updating nixpkgs, the system fails to build.

What makes you think that? nix-instantiate --eval -A linuxKernel.packages.linux_6_15.zfs_2_3.meta.broken shows
false on current master.

Sorry about my confusion. Somehow I was unable to find out this method.