[Pkg-zfsonlinux-devel] Bug#1120320: Bug#1120320: Please build a linux-image-zfs metapackage that depends on the latest kernel the current zfs-dkms builds with

[Craig Sanders]

On Fri, Nov 07, 2025 at 04:11:19PM +0100, Andras Korn wrote:
> now and again it happens that zfs-dkms doesn't yet support the current
> kernel Debian ships.

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.

> 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.

This is the case not just for zfs-dkms but also for any dkms package or any
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".