zfsUnstable: 2.2.6 -> 2.3.0-rc2

[Mic92]

Using this since rc1 on my systems.

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.

[Mic92]

https://github.com/openzfs/zfs/releases/tag/zfs-2.3.0-rc2

[MangoIV]

Would be nice to get this merged since the latest kernel version that is not EOL that you can use with NixOS and ZFS right now is 6.6.

[Mic92]

We usually also backport zfs updates anyway because of kernel churn.

[MangoIV]

I don't know if this is the correct place to ask ~ but why is it that the EOL kernel versions get "removed" while the kernel versions that use an old ZFS get marked as broken? It seems like weird UI for me to "suggest" a broken kernel to a user instead of staying on an EOL kernel for until the next stable kernel has zfs support again. It would be nice if I could add the old kernel to my allowed insecure packages instead of risking a broken system / having to roll back to an old kernel that caused me issues.

[Mic92]

@ctheune had similar complaints about removing old k3s version, that a user also need to upgrade to the next version. I think the misconception that we have in nixpkgs w.r.t. security is that it's often considered a binary state (secure/insecure). However in practice security is a gradient / process that cannot be decided automatically and depends on the context. Something that would be an unacceptable security vulnerability for one person, is perfectly fine for another person that uses the software in a different context.

[ctheune]

Right. If you take it to the extreme then we have to shut everything down to be "perfectly" secure. I fondly remember the security practices that become asinine and counter-productive even for their primary goals: where everyone keeps working against the security practices because nobody can get their job done (and go home on a Friday afternoon).

I'm adding this discussion to my list of examples where we can do better.

A big differentiator that I see is dealing with unstable and stable. Unstable can be more aggressive removing things but does need to take care to let people have a path forward from stable to stable+1.

[adamcstephens]

I’m surprised this built without fixing the substitutions. Though it looks like no ofborg builds occurred.