I note that trixie-backports currently has version 2.4.2-1~bpo13+1 and that the release notes for 2.4.2 say that it supports Linux kernels up to 7.0.
trixie-backports currently has kernel 7.0.4 so that’s all good. However, just a few days ago I checked and trixie-backports had ZFS 2.4.1 which listed compat up to kernel 6.19 meanwhile trixie-backports at that time did already have kernel 7.0.4. So, at that time technically if getting your kernel from backports as well as your zfs, you would be using an unsupported kernel version,right?
Presumably agiven this is DKMS it probably would have still compiled but may not have operated correctly, since it would be an unsupported configuration.
If choosing to use Debian zfs packages from backports, is it inadvisable to also use the kernel from backports due to periods where the kernel packages are ahead of zfs support? Or is that overly paranoid?
I think that’s a fairly reasonable level of paranoia, honestly. The problem is that stuff in backports is by obvious necessity less well tested with any random extra thing from outside the main repo that you might throw at it, so you can wind up with mismatches there where you would not have had a mismatch between backports and main.
With that said… actual issues from this kind of thing are fairly rare, and in my experience quite minimal. Most commonly, you’ll see something like replication refusing to work until you find and sort out your problem.
So basically, if you really want the backports kernel, I think you can pretty reasonably decide that you’re willing to tolerate an occasional kernel/userland version mismatch issue, if you’re prepared to notice it, recognize it, and if it causes you problems, manually make a change when the problem crops up.
But if you really don’t want to deal with that kind of potential issue, relatively minor and fixavle though it might be, that is also a reasonable proposition, and in that case, no, I would not recommend running both the kernel and the zfs userland out of backports, for exactly the reason you’ve already spotted.
The zfs code prevents compilation for unsupported kernel versions.
No, you can easily stick to the default debian kernel and still use zfs from backports (this is what I do). This works because the stock debian kernel is an old enough LTS kernel.
Sure, that was straightforward. I was just wondering if using both kernel and zfs from backports was something people did, given the periods where the backports kernel package is ahead of what zfs supports.
I’ve had the DKMS modules compile several times for unsupported kernels. I recently installed Linux kernel 7.1, the ZFS modules for ZFS 2.4.2 compiled with no problem.
I use Debian Unstable, so this is something I come across often. There’s usually several kernel versions available, so I usually stick with the most recent that’s officially supported by the version of ZFS available in the repos. I install the kernels by linux-image-{version}-amd64, rather than the linux-image-amd64 metapackage, this way I’m not pulling in possible unsupported kernels automatically.
This PR was merged in Sept. 2024 and released with zfs 2.3.0
You can only compile with an unsupported kernel with compile option --enable-linux-experimental
This option is used for example in the AUR package zfs-dkms-staging-git package. The stable package zfs-dkms does not compile with unsupported kernels. It throws an error like:
checking kernel source version... 7.1
configure: error:
*** Cannot build against kernel version 7.1
*** The maximum supported kernel version is 7.0.
This is only true for the zfs-dkms package in the backports repo. The regular package from trixie/contrib, which is zfs 2.3.2, does not have this compiler option:
If you want to make sure that you never compile zfs for an unsupported kernel I suggest to remove the --enable-linux-experimental option form dkms.conf. I honestly do not know why this option has been added. There is no kernel 7.1 in any debian repo.
Power users who want to compile their own kernel can simply add that option if they need it, but for the regular user I consider this option dangerous if it is applied by default.
Where else did you get zfs 2.4.2 for debian from? If it is debian/experimental I would assume that backports use the same package.
I was not considering any experimental repos. This is only for testing and experimenting and can break at any time.
For an experimental kernel it makes sense to have zfs experimental settings as well. But my point is, for the regular zfs user who wants to use the latest zfs version it does not make sense to have the experimental setting in zfs. Like myself for example. I have a debian server with backports enabled just for zfs. I do not want to have the experimental compile option.
Thats why the regular stable package of zfs-dkms does not have the experimental option.
I use the unstable branch (rarely “unstable” in my experience). I believe backports are based on the next release’s packages.
Package zfs-dkms
bullseye (oldoldstable) (kernel): OpenZFS filesystem kernel modules for Linux [contrib]
2.0.3-9+deb11u2 [security]: all
bookworm (oldstable) (kernel): OpenZFS filesystem kernel modules for Linux [contrib]
2.1.11-1+deb12u1: all
bookworm-backports (kernel): OpenZFS filesystem kernel modules for Linux [contrib]
2.3.2-2~bpo12+2: all
trixie (stable) (kernel): OpenZFS filesystem kernel modules for Linux [contrib]
2.3.2-2: all
trixie-backports (kernel): OpenZFS filesystem kernel modules for Linux [contrib]
2.4.2-1~bpo13+1: all
forky (testing) (kernel): OpenZFS filesystem kernel modules for Linux [contrib]
2.4.2-2: all
sid (unstable) (kernel): OpenZFS filesystem kernel modules for Linux [contrib]
2.4.2-2: all
You’re right. Running packages from experimental should be done with care. I have the experimental repo pinned to a lesser priority than unstable, so experimental packages can’t replace existing packages unless explicitly told to do so. In this case, the experimental kernels install along side existing kernels, and won’t break the system.