Bug#1135579: zfs-dkms does not compile with Linux 7.0
So... my account creation got rejected for whatever reason. Is anyone at Debian going to step up and implement my suggestion (one line change, no additional maintenance) or are we gonna leave it in this "hopefully it works" kinda state?
Bug#1135579: zfs-dkms does not compile with Linux 7.0
Does this bug still need to be open as RC? https://tracker.debian.org/news/1751813/accepted-zfs-linux-242-1-source-into-unstable/ seems to fix it. If you wanted to keep it open for the discussion about adding Conflicts or Breaks or whatever, that could be non-RC. Thanks, -- Colin Watson (he/him) [[email protected]]
Bug#1135579: zfs-dkms does not compile with Linux 7.0
> please implement I'm waiting for my account registration to go thorugh. But honestly, why don't you do it yourself? It's literally a one line change. Just add ``` dh_gencontrol -- -Vlinux:Depends="linux-image-amd64 (<< $(LINUX_NEXT)~) | linux-image-arm64 (<< $(LINUX_NEXT)~) | linux-image-armmp (<< $(LINUX_NEXT)~) | linux-image-rpi (<< $(LINUX_NEXT)~) | linux-image-powerpc64le (<< $(LINUX_NEXT)~) | linux-image-s390x (<< $(LINUX_NEXT)~) | linux-image-riscv6 (<< $(LINUX_NEXT)~), linux-image-amd64 (>= $(LINUX_MIN)~) | linux-image-arm64 (>= $(LINUX_MIN)~) | linux-image-armmp (>= $(LINUX_MIN)~) | linux-image-rpi (>= $(LINUX_MIN)~) | linux-image-powerpc64le (>= $(LINUX_MIN)~) | linux-image-s390x (>= $(LINUX_MIN)~) | linux-image-riscv6 (>= $(LINUX_MIN)~)," ``` here: https://salsa.debian.org/zfsonlinux-team/zfs/-/blob/1511025e6fed3fe510bd1da7db5a966a3d0b7fcd/contrib/debian/rules#L71 I'm sure you could do this better (e.g. by detecting the relevant arch) but it's quite literally *that* simple. I don't understand how this has been a bug for over 7 years.
Bug#1135579: zfs-dkms does not compile with Linux 7.0
> kernels aren't numbered in a suitable way. On Debian for example,
packages like linux-image-amd64 are versioned with the full kernel version
- eg: 6.12.73-1, or 7.0.4-1~bpo13+1.
I really don't understand this argument. What's stopping you from simply
incrementing the minor? After all, if ZFS only supports up to 6.19, and you
specify <6.20, then it doesn't matter if 6.20 exists, it's still less than
7.0. You're literally already using it in `Recommends` ("linux-libc-dev (<<
6.20~)"), I don't understand why you couldn't also use it in `Depends`.
> I maintain a local package "zfs-linux-image-amd64" which strictly depends
on specific kernel and zfs-dkms | zfs-modules versions
I don't like this. I specifically chose Debian because I don't want to
touch my server *at all*. So anyway, I wrote a little hook
(`DPkg::Pre-Install-Pkgs`) that does what I want:
```bash
#!/usr/bin/bash
cat | while read p; do
[[ $p == */zfs-dkms_* ]] || continue
t=/tmp/$(basename $p .deb)
dpkg-deb -R $p $t
sed -i "/^Depends:/{/linux-image-amd64/!s/$/, linux-image-amd64 (<<
$(awk '/^Linux-Maximum:/{split($2,v,".");print v[1]"."v[2]+1}'
$t/usr/src/*/META)~)/};/^Version:/s/$/+/" $t/DEBIAN/control
dpkg-deb -b $t $p
rm -r $t
done
```
(I had to also increase the version otherwise it would reinstall the same
version over and over again)
Bug#1135579: [Pkg-zfsonlinux-devel] Bug#1135579: zfs-dkms does not compile with Linux 7.0
On Tue, May 12, 2026, at 16:48, Ulrich Wexler wrote: > But what I don't understand is why you guys don't mark the kernel as > incompatible? TL;DR: kernels aren't numbered in a suitable way. On Debian for example, packages like linux-image-amd64 are versioned with the full kernel version - eg: 6.12.73-1, or 7.0.4-1~bpo13+1. Getting the conflicts or depends correct under all circumstances is nontrivial, as you can't wildcard them. (Yes, it's *possible* with hacks like "< 6.19.999", but one needs to consider the tradeoffs between this kind of dependency and the possibility of edge case breakage when something unexpected happens upstream.) > I'm actually thinking about writing a pre-install hook which intercepts > `zfs-dkms`, unpacks the `control` and `/META`, adds the appropriate max > kernel version, repacks and then installs that instead. An easier approach, for what it's worth, is what I do - instead of installing linux-image-amd64, I maintain a local package "zfs-linux-image-amd64" which strictly depends on specific kernel and zfs-dkms | zfs-modules versions. This is pulled in from my local repository, and ensures that no upgrades happen until I've validated that they work. Colm -- Colm Buckley / [email protected]
Bug#1135579: zfs-dkms does not compile with Linux 7.0
Powered by Anonymousemail
This is the first time I got hit by this "bug" because I usually stay on the
stable kernel, but this time I had to upgrade to stable-backports because of
some HW requirements.
> If you're using zfs-dkms or any other out-of-tree kernel module, DO NOT
> UPGRADE YOUR KERNEL UNTIL YOU'RE ABSOLUTELY CERTAIN IT'S COMPATIBLE WITH YOUR
> MODULES.
To me this was outside of my control. In my case `unattended-upgrades` upgraded
my kernel to 7.0, which then broke ZFS. I got an email every day because the
kernel was unconfigured. I had to manually downgrade and hold the packages.
But what I don't understand is why you guys don't mark the kernel as
incompatible? The info is right there! It's quite literally the first thing you
see in the [changelog](https://github.com/openzfs/zfs/releases/tag/zfs-2.4.1)
("Linux: compatible with 4.18 - 6.19 kernels"). There's also the
[`/META`](https://github.com/openzfs/zfs/blob/zfs-2.4.1/META) file
("Linux-Maximum: 6.19"). If you could just do a
```
Depends: linux-image-amd64 (>=4.18), linux-image-amd64 (<=6.19)
```
or `Breaks`/`Conflicts` whatever, that would solve this issue, no? What is the
reason you're not doing that?
I'm actually thinking about writing a pre-install hook which intercepts
`zfs-dkms`, unpacks the `control` and `/META`, adds the appropriate max kernel
version, repacks and then installs that instead.
Bug#1135579: zfs-dkms does not compile with Linux 7.0
This is the first time I got hit by this "bug" because I usually stay on
the stable kernel, but this time I had to upgrade to stable-backports
because of some HW requirements.
> If you're using zfs-dkms or any other out-of-tree kernel module, DO NOT
> UPGRADE YOUR KERNEL UNTIL YOU'RE ABSOLUTELY CERTAIN IT'S COMPATIBLE WITH
YOUR
> MODULES.
To me this was outside of my control. In my case `unattended-upgrades`
upgraded my kernel to 7.0, which then broke ZFS. I got an email every day
because the kernel was unconfigured. I had to manually downgrade and hold
the packages.
But what I don't understand is why you guys don't mark the kernel as
incompatible? The info is right there! It's quite literally the first thing
you see in the [changelog](
https://github.com/openzfs/zfs/releases/tag/zfs-2.4.1) ("Linux: compatible
with 4.18 - 6.19 kernels"). There's also the [`/META`](
https://github.com/openzfs/zfs/blob/zfs-2.4.1/META) file ("Linux-Maximum:
6.19"). If you could just do a
```
Depends: linux-image-amd64 (>=4.18), linux-image-amd64 (<=6.19)
```
or `Breaks`/`Conflicts` whatever, that would solve this issue, no? What is
the reason you're not doing that?
I'm actually thinking about writing a pre-install hook which intercepts
`zfs-dkms`, unpacks the `control` and `/META`, adds the appropriate max
kernel version, repacks and then installs that instead.
Bug#1135579: [Pkg-zfsonlinux-devel] Bug#1135579: Bug#1135579: zfs-dkms does not compile with Linux 7.0
On Sat, May 09, 2026 at 08:04:13AM +0200, Paul Gevers wrote: > Yes, but the next standard kernel was incoming. Can't this package be ready > ahead of time? Yes, that would be ideal but it seems a bit unreasonable to expect debian's ZFS packaging team to be capable of time travel. Mostly zfs-dkms works fine, but occasionally a kernel update is released which breaks compatibility with ZFS and other out-of-tree modules. They have no control over when an incompatible new kernel is released, or when that kernel is packaged for debian, or when the upstream ZFS project patches ZFS to work with the new kernel (and this is not helped by the fact that some of the linux kernel devs are hostile to zfs and tag it as "proprietary" even though it's open source). They can only react to these events AFTER they happen. This is not just a packaging issue. Significant changes have been made to the kernel which break compatibility with ZFS, so significant changes have to be made to ZFS to make it compatible again. This takes time to code and to test. And nobody thinks this is ideal, it's been an ongoing problem for almost 2 decades and everyone involved is sick and tired of it but it's probably never going to change, it's just a PITA you have to be resigned to. The only real solution is for Oracle to re-release ZFS under the BSD (**NOT** GPL) license, which is extremely unlikely to ever happen (read as "never"). And then the OpenZFS devs would have to do the same with their derivative which they forked long ago. And then it could go in the mainline kernel. But none of this will ever happen. Which leaves us with pragmatic solutions like "Don't upgrade your kernel until you're sure it's compatible with any modules you need". craig PS: one thing I forgot to mention in my "guide" in Step 3 was that you need to upgrade zfs-dkms **before** upgrading the kernel. Kind of obvious, but sometimes it's best to state the obvious to avoid confusion. Also, I wrote "Even when a new zfs-dkms module is **installed** [...]" when I meant "Even when a new zfs-dkms module is **released**". PPS: yes, the CDDL does kind of suck and it is incompatible with the GPL. But a) that incompatibility only hinders *distribution* of combined binaries, not what end-users do on their own systems (hence the existence of zfs-dkms) and b) it IS open source, not proprietary. Most ex-Sun people involved with writing the CDDL claim that incompatibilty with the GPL was not a deliberate goal, but I find that impossible to believe - the incompatibliity was obvious, and they weren't clueless enough not to have seen it (and people were pointing it out and loudly complaining that it had the same problems as the MPL), and Linux was seen by Sun Microsystems as an existential threat at the time (and, rightly so - Linux **did** eat their lunch). If ZFS weren't so good, nobody would care by now. It would just be another piece of software doomed to irrelevancy, nothing more than a historical curiosity.
Bug#1135579: [Pkg-zfsonlinux-devel] Bug#1135579: zfs-dkms does not compile with Linux 7.0
Control: severity -1 serious Hi, On Sun, 3 May 2026 22:03:53 +1000 Craig Sanders wrote: A variant of this issue comes up every time there's a major new kernel release or major changes to the kernel APIs, and the solution is the same every time: If you're using zfs-dkms or any other out-of-tree kernel module, DO NOT UPGRADE YOUR KERNEL UNTIL YOU'RE ABSOLUTELY CERTAIN IT'S COMPATIBLE WITH YOUR MODULES. Yes. But the new linux kernel has now landed in unstable and this failure is blocking its migration because the autopkgtest of this package fails. As a release manager I have to look at this *every time*. You're using a non-standard kernel module. You have to accept that things can and will go wrong from time to time. That means there will be extra work involved and it's up to YOU to do the essential systems administration tasks so that your system doesn't break. Yes, but the next standard kernel was incoming. Can't this package be ready ahead of time? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1135579: [Pkg-zfsonlinux-devel] Bug#1135579: zfs-dkms does not compile with Linux 7.0
On Sun, May 03, 2026 at 02:04:53AM +0200, Linus Lüssing wrote: > Updating to linux-image-7.0.3+deb14-amd64 conflicts with this zfs-dkms > package: > > ``` > $ apt update && apt dist-upgrade > [...] > Autoinstall of module zfs/2.4.1 for kernel 7.0.3+deb14-amd64 (x86_64) > Running the pre_build script..(bad exit status: 1) > Failed command: > cd /var/lib/dkms/zfs/2.4.1/build/ && /var/lib/dkms/zfs/2.4.1/build/configure > --disable-dependency-tracking --prefix=/usr --with-config=kernel > --with-linux=/lib/modules/7.0.3+deb14-amd64/source > --with-linux-obj=/lib/modules/7.0.3+deb14-amd64/build --with-qat= --host= > --enable-linux-experimental > Consult /var/lib/dkms/zfs/2.4.1/build/make.log for more information. > [...] A variant of this issue comes up every time there's a major new kernel release or major changes to the kernel APIs, and the solution is the same every time: If you're using zfs-dkms or any other out-of-tree kernel module, DO NOT UPGRADE YOUR KERNEL UNTIL YOU'RE ABSOLUTELY CERTAIN IT'S COMPATIBLE WITH YOUR MODULES. BTW, this issue is not specific to ZFS, it's the same for every out-of-tree kernel module including those packaged for debian (e.g. nvidia-kernel-dkms) and those you might have downloaded from github or a manufacturer's web site or wherever. And the solution is the same for all of them - don't try to upgrade your kernel when you need out-of-tree modules that haven't been proven to compile against the new kernel. You're using a non-standard kernel module. You have to accept that things can and will go wrong from time to time. That means there will be extra work involved and it's up to YOU to do the essential systems administration tasks so that your system doesn't break. Here's an easy to follow guide on how to do that: 1. HOLD Use `apt-mark` to hold your kernel packages. e.g. on amd64, run: apt-mark hold linux-image-amd64 linux-headers-amd64 linux-base-amd64 Run this NOW and after every time you upgrade the kernel. This will stop the debian kernel packages from being automatically upgraded. I've been running ZFS on my debian systems since around 2010 and the only times I ever have a problem upgrading to new kernels is when I forget to hold them again after an upgrade. Same with the proprietary nvidia driver on my systems with nvidia cards, and same with the drivers for sensor chipsets (temp, voltage, etc) on some of my systems. And other non-standard drivers I've needed over the years. 2. WAIT, AND HAVE SOME PATIENCE. Do not try to upgrade your kernel until you know for sure that the zfs-dkms package has been updated to work with the kernel you are trying to install. It might take a few days or a few weeks or even months, but eventually a new zfs-dkms package will be released that compiles against the new kernel. Unless you're part of the development or debugging effort, there is no point in trying to upgrade your kernel until the new, compatible, module package is released. 3. WAIT SOME MORE Even when a new zfs-dkms module is installed, DON'T INSTALL IT ONTO YOUR REAL SYSTEM IMMEDIATELY. Set up a VM just for testing kernel upgrades and make sure that both the new zfs-dkms AND the new kernel will install. It's not 100% necessary, but it's useful to have a few zfs pools on the testing VM so you can make sure that the kernel & zfs not only compiled and install but that it actually works. You do not want to risk the filesystem on your real/production systems (and all your important files) with untested new versions. If all seems fine, then, AND ONLY THEN, should you attempt to upgrade zfs and the kernel on your real system(s). A testing VM like this is also useful for practising the steps to fix the problems you caused by being over-eager to upgrade (e.g. step 5 below). 4. INSTALL AND HOLD AGAIN Whenever you do upgrade the kernel, remember to hold the packages again (same as in step 1) after the upgrade completes. I usually do it like so: apt-get -u install linux-image-amd64 linux-headers-amd64 linux-base-amd64 apt-mark hold linux-image-amd64 linux-headers-amd64 linux-base-amd64 If you don't want to rely on your bash history for that, I suggest you put those commands into a shell script and call it something like /usr/local/bin/upgrade-kernel.sh And if you have dlocate installed, maybe add the following to the script. They'll prevent old kernel images from being auto-uninstalled before you're ready to uninstall them yourself. update-dlocatedb apt-mark manual $(dlocate -k | grep -v linux-doc) 5. REPAIRING A FAILED KERNEL UPGRADE While you're waiting for the new zfs-dkms package, to stop apt from complaining about failed kernel upgrades, you'll need to downgrade linux-image-amd64, linux-headers-amd64, and linux-base-amd64 back to the previous working version. You might find the
Bug#1135579: zfs-dkms does not compile with Linux 7.0
Package: zfs-dkms Version: 2.4.1-1 Severity: important X-Debbugs-Cc: [email protected] Dear Maintainer, Updating to linux-image-7.0.3+deb14-amd64 conflicts with this zfs-dkms package: ``` $ apt update && apt dist-upgrade [...] Autoinstall of module zfs/2.4.1 for kernel 7.0.3+deb14-amd64 (x86_64) Running the pre_build script..(bad exit status: 1) Failed command: cd /var/lib/dkms/zfs/2.4.1/build/ && /var/lib/dkms/zfs/2.4.1/build/configure --disable-dependency-tracking --prefix=/usr --with-config=kernel --with-linux=/lib/modules/7.0.3+deb14-amd64/source --with-linux-obj=/lib/modules/7.0.3+deb14-amd64/build --with-qat= --host= --enable-linux-experimental Consult /var/lib/dkms/zfs/2.4.1/build/make.log for more information. [...] ``` /var/lib/dkms/zfs/2.4.1/build/make.log says: ``` DKMS (dkms-3.2.2) make.log for zfs/2.4.1 for kernel 7.0.3+deb14-amd64 (x86_64) Sun May 3 01:32:17 AM CEST 2026 [...] checking whether truncate_setsize() is available... yes checking whether security_inode_init_security wants callback... yes checking whether fst->mount() exists... configure: error: *** None of the expected "fst->mount()" interfaces were detected. *** This may be because your kernel version is newer than what is *** supported, or you are using a patched custom kernel with *** incompatible modifications. *** *** ZFS Version: zfs-2.4.1-1 *** Compatible Kernels: 4.18 - 6.19 # exit code: 1 # elapsed time: 00:00:35 ``` Regards, Linus PS: Also, if the supported kernel versions are known in advance, wouldn't it be possible and nicer to add the kernel version requirements to the Debian package definition? So that one would get an error before trying to update and not after? And one wouldn't be left with a system that would potentially not boot anymore? -- System Information: Debian Release: forky/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i686, i386, armhf, arm64 Kernel: Linux 6.19.14+deb14-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zfs-dkms depends on: ii debconf [debconf-2.0] 1.5.92 ii dkms 3.2.2-1 ii file 1:5.46-5+b2 ii libc6-dev [libc-dev] 2.42-15 ii libpython3-stdlib 3.13.9-3+b1 ii lsb-release12.1-2 Versions of packages zfs-dkms recommends: ii linux-libc-dev 6.19.14-1 ii zfs-zed 2.4.1-1 ii zfsutils-linux 2.4.1-1 Versions of packages zfs-dkms suggests: ii debhelper 13.31 -- debconf information: zfs-dkms/stop-build-for-unknown-kernel: true zfs-dkms/stop-build-for-32bit-kernel: true * zfs-dkms/note-incompatible-licenses:
