On Mon, 2018-02-26 at 12:07 -0500, The Wanderer wrote:
[...]
> I am still running kernel version 4.14.13-1, although the installed
> version of linux-{image,headers}-4.14.0-3-amd64 is 4.14.17-1; I have not
> rebooted since upgrading the kernel package, and IMO it should not be
> expected that upgrading the kernel will be followed swiftly by a reboot.
In the same way that extensions to a library ABI do not require a new
soname, extensions to the kernel module ABI do not require a change to
its ABI name. Newly built modules, including in-tree modules, may
depend on those extensions. Therefore you should not expect to be able
to load new kernel modules between upgrading the kernel and rebooting.
> To the best of my recollection, I have never previously seen it be
> necessary to reboot in order to avoid loss of functionality from a DKMS
> rebuild subsequent to a kernel upgrade.
I think you've just been lucky.
> If the automatic DKMS rebuild is expected to be able to produce modules
> which can work with the running kernel, then clearly the current
> behavior is buggy in some way, and should be addressed.
I don't think that's a reasonable expectation. But I think DKMS should
not automatically rebuild when installing a version of linux-headers-
ABINAME that is newer than the currently *installed* version of linux-
image-ABINAME.
> On the other hand, if rebuilding the modules is expected to result in
> modules which will not load against the running kernel, shouldn't the
> DKMS machinery detect this condition and refrain from automatically
> removing the existing (working) modules, at least without an override
> request of some sort? Or at bare minimum, warn that proceeding with the
> upgrade will result in functionality loss until a reboot can be carried
> out?
If by "removing" you mean unloading a module from the kernel, I agree
that it should not do this.
If you mean replacing the module on disk, I disagree; it should build
modules for the installed kernel version.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
Attachment:
signature.asc
Description: This is a digitally signed message part