Hi,

now and again it happens that zfs-dkms doesn't yet support the current kernel Debian ships.

If you have linux-image-amd64 installed, a dist-upgrade will try to install the latest kernel, which will then fail to configure (and, if your root is on zfs, the next reboot with the latest kernel will fail).

To avoid this, it would nice to have a metapackage just like linux-image-amd64 (and one like linux-headers-amd64) that doesn't depend on the latest Debian kernel, but instead the latest Debian kernel zfs-dkms works with.

Us zfs users could then install that metapackage instead of linux-{image,headers}-amd64.

Thanks!

András

Yes, that happens. And the solution is to wait.

It usually doesn't take more than a few days, or at most a few weeks, for a
ZFS update to be released and packaged.

You have chosen to use an out-of-treee filesystem driver.  That's not a bad
thing, ZFS offers many features that make it worthwhile.  And it's not even
difficult these days with the zfs-dkms package, far easier than running ZFS
with Debian used to be when I first started using ZFS on Linux about 15 years
ago.  These days, it's trivially easy.

However, when doing "non-standard" stuff, it's up to you to manage your system
so that it doesn't break (actually, that's true in any case).  In particular,
that means being wary of automatic upgrades.  Most things are reasonably safe
to just upgrade automatically, but many things are not.
other driver module that's not in the mainline kernel.  Even some daemons and
end-user apps can depend on specific kernel versions.

The solution is not to add multiple linux-{image,headers}-foo packages, one
for each dkms package, but to learn how to use the tools you already have.
i.e. `apt-mark hold`.

1. Hold the linux-image-amd64 and linux-headers-amd64 packages

    apt-mark hold linux-image-amd64 linux-headers-amd64

These packages should be kept in a held state almost all the time and should
never be automatically upgraded if you use any dkms packages or anything else
which is sensitive to the exact installed version of the kernel image/header
packages.

2. Test all kernel upgrades in a VM before installing them on your main
system.  If zfs-dkms (or nvidia-kernel-dkms or whatever) doesn't compile with
the new kernel then **don't install it on the main system**.

Instead, wait for the -dkms module to be updated to work with the new kernel.

I have a VM called "ztest" which I use for this - it's a fairly minimal Debian
"sid" install, not much more than the base system.  I use it not only for
testing kernel and zfs-dkms upgrades, but also to practice and experiment
with various ZFS-related things on dummy pools before trying them on my real
systems.  And it's on a ZVOL, so it's easy to rollback if I happen to break
it too badly.


3. If/when it does compile and the VM boots OK with the new kernel then update
the kernel packages and remember to hold them again afterwards:

    apt-get -u install linux-image-amd64 linux-headers-amd64 ; apt-mark hold linux-image-amd64 linux-headers-amd64


You can put that in a script or, as I do, just rely on it being in bash's
history...I run it often enough and have a big enough $HISTSIZE that it's
always there.


BTW, kernel packages aren't the only ones that it's a good idea to only
upgrade manually.  For example, I also hold:

 * zfs-dkms and other zfs-related packages, and other dkms packages,

 * some server package which are crucial to my needs, including asterisk,
apache, and squid - things that could break my system and my network if
upgraded without due care, and

 * several apps on desktop machines including web browsers, libre office,
calibre - generally things which dynamically load libraries or other code that
could crash or, worse, just behave weirdly if the dynamically loaded stuff
gets changed underneath the running apps


craig

PS: if it was up to me, I'd just close this as it's not a real bug or a good
thing to wishlist. Better yet, leave it open but tag it as "wontfix".

On Sat, Nov 08, 2025 at 05:26:07PM +1100, Craig Sanders wrote:

Hi,

That's _a_ solution that scales for a very small number of systems, yes, if
you do it manually.

No argument there. (I also started in the zfs-fuse days; and I'm also a
small-time openzfs contributor.)

I know. I filed a wishlist request because this is an instance when it could
be made safe with what I imagine would be a relatively low effort.

I'd willing to help if a Debian developer were willing to accept it and ship
the metapackage in Debian. (I can write shell scripts and have a basic
understanding of building Debian packages. I belive I probably could build
the metapackage I have in mind, but I can't make it part of Debian.)

Yes; and if any of them are required to boot successfully, the same kind of
metapackage would be useful in their case as well. (If several such
metapackages were to materialize, a clever way of having several installed
at the same time and working as intended would be needed.)

(I don't think I did anything to deserve this condescending tone, fwiw. I'm
going to assume it wasn't intentional.)

I know I can do this, but I don't want to. I have a few dozen systems that I
normally want to keep up to date at current sid, including always installing
the latest kernel and automatically rebooting.

I disagree with this view. The kernel can (and often does) contain security
vulnerabilities. I think automatically upgrading to the latest one as soon
as possible when it is safe is a good idea. (I know sid has no formal
security support. However, I've gone out of my way to find instances of
"stable" receiving security fixes much sooner than "unstable" and came up
empty; so the "no security support" argument, while technically true,
doesn't carry as much weight as one might think.)

Having the metapackage I envisioned would help make the "is it safe?"
decision automatically. (It would certainly provide a data point.)

There isn't "*a* main system".

We're talking about systems that can take a few minutes of downtime for a
reboot occasionally, and where it's fine if one thing or another breaks due
to an upgrade and needs to be fixed; but all of them failing to boot more or
less simultaneously and needing manual steps, involving console access, to
fix them doesn't scale.

(No, this hasn't happened yet, because I've been careful -- but I'd like to
avoid having to be this careful this manually, if possible.)

That's what I'd like to do -- automatically.

It's not a "bug"; it's a wishlist item. An idea that would improve the life
of some number of people, if it were realized.

If it gets closed or tagged as "wontfix", I'll just have to build my own
metapackage. That's also an option, but then it'll only benefit me, not
other zfs users.

András

Hi,

I created such a package; probably not 100% correctly, but it seems to work well enough.

My control file is:

Source: linux-kernel-zfs
Section: admin
Priority: important
Maintainer: ...
Build-Depends: debhelper-compat (= 13)
Standards-Version: 4.7.0
Rules-Requires-Root: no

Package: linux-kernel-zfs
Architecture: all
Enhances: zfs-dkms
Depends: linux-image-amd64 (>= 6.8) | linux-image-arm64 (>= 6.8) | linux-image-armmp (>= 6.8) | linux-image-686-pae (>= 6.8) | linux-image-ppc64el (>= 6.8) | linux-image-s390x (>= 6.8) | linux-headers-amd64 (>= 6.8) | linux-headers-arm64 (>= 6.8) | linux-headers-armmp (>= 6.8) | linux-headers-686-pae (>= 6.8) | linux-headers-ppc64el (>= 6.8) | linux-headers-s390x (>= 6.8), zfs-dkms (>= 2.3.5)
Conflicts: linux-image-amd64 (>= 6.18),
           linux-image-arm64 (>= 6.18),
           linux-image-armmp (>= 6.18),
           linux-image-686-pae (>= 6.18),
           linux-image-ppc64el (>= 6.18),
           linux-image-s390x (>= 6.18)
Description: Metapackage to ensure a recent kernel supported by OpenZFS is installed
 This package depends on linux-image and linux-headers, but conflicts with
 versions that are not supported by zfs-dkms yet, preventing accidental
 upgrades to such versions (and the subsequent failure to boot).



One thing that I'm sure could be improved is that it doesn't actually make
sure a linux-headers package matching the latest linux-image package is
installed; but I'm not sure how to do that, other than have a hard versioned
dependency on a specific linux-image and linux-headers package.

András