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.
