<p><span style="color:#c0392b">Powered by <strong>Anonymousemail</strong></span></p><p>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.</p>
<div>> If you're using zfs-dkms or any other out-of-tree kernel module, DO NOT</div>
<div>> UPGRADE YOUR KERNEL UNTIL YOU'RE ABSOLUTELY CERTAIN IT'S COMPATIBLE WITH YOUR<br>> MODULES.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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</div>
<div>```</div>
<div>Depends: linux-image-amd64 (>=4.18), linux-image-amd64 (<=6.19)</div>
<div>```</div>
<div>or `Breaks`/`Conflicts` whatever, that would solve this issue, no? What is the reason you're not doing that?</div>
<div> </div>
<div>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.</div>