[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknown symbol __x86_indirect_thunk_r15 (err 0)wn symbol __x86_indirect_thunk_r15 (err 0)



I encountered this error today on upgrade of virtualbox-dkms, I think
from version 5.2.6-dfsg-2 to 5.2.6-dfsg-5. To the best of my knowledge,
I have not carried out any downgrade, either of the kernel or of the
DKMS package.

In my experience, upgrading a DKMS package triggers an automatic rebuild
of the relevant module(s) against installed headers; more specifically,
on removal of the pre-upgrade version the old modules are removed, and
on install of the post-upgrade version the new modules are automatically
built. (The messages printed during this process seem to imply that the
DKMS machinery has the ability to have multiple installed module
versions per kernel, and simply set one or another as active, but I have
never seen this functionality be used.)

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

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.

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?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: