[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

[Andras Korn]

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

Hi,

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

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

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

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

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

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

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

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

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

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

> 1. Hold the linux-image-amd64 and linux-headers-amd64 packages
> 
>     apt-mark hold linux-image-amd64 linux-headers-amd64

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.

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

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

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

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

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

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

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

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

-- 
              Web 2.0: you make the content, they make the money.