[Rpm-ecosystem] Writing a dnf plugin to better deal with out of tree kernel modules

Hans de Goede hdegoede at redhat.com
Thu Oct 6 09:28:50 UTC 2016

Hi All,

There has been some discussion about giving end users a smoother
nvidia binary driver experience (or a smoother experience with
any out of tree kernel module they depend on really).

The problem with out of tree kernel modules installed via
a repo is that as soon as the Fedora kernel pkg gets updated,
the module needs to be rebuild and typically there will be
some lag between the repo hosting the module doing that
rebuild and the user receiving the kernel update.

akmods, or dkms are 2 solutions to this, but we really do
not want end users to depend on automatically building
stuff from source on their system, this is undesirable
in general, and is esp. problematic since this may
break if the (glue) code needs some minor fix because
of e.g. a kernel function getting an extra argument.

When things break this way, then the user may end up
with an unusable system (e.g. black screen after boot),
and this is something which we ought to fix.

I believe that a possible solution for this updates
problem is a dnf plugin which knows about kernel module
packages and which will consider the following scenario
broken deps and thus will skip the kernel update:

nvidia-kernel-module-4.6.1-1 (requiring kernel-core=4.6.1-1)
nvidia-xorg-driver (requiring nvidia-kernel-module)

available as update:

Currently dnf will happily install the update
and then without dkms / akmod on the next reboot the nvidia
binary driver will not work since there is no
nvidia-kernel-module available for the running kernel,
typically resulting in a black screen, which is a quite
bad user experience. And as said we really want to avoid
dkms / akmod.

So the idea is to have a new dnf-plugin which understands
that if an extra kernel-module is installed that then not
having that module available for a newer kernel should
be treated as that kernel having broken deps causing dnf
to skip the kerel update, unless --best is used in which
case this will be an error.

So 2 questions:

1) Any better ideas to delay a kernel update until
matching extra-module pkgs are available for all
extra-modules the user has installed ?

2) Would it be feasible to write such a dnf plugin?



More information about the Rpm-ecosystem mailing list