Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #60256 > unrolled thread

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)

Back to article view | Back to linux.debian.kernel

Contents

  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) Evgeny Kapun <abacabadabacaba@gmail.com> - 2018-02-21 13:50 +0100
    Bug#890999: marked as done (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)) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-02-21 14:40 +0100
    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) The Wanderer <wanderer@fastmail.fm> - 2018-02-26 18:10 +0100
      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) The Wanderer <wanderer@fastmail.fm> - 2018-02-26 18:40 +0100
      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) Ben Hutchings <ben@decadent.org.uk> - 2018-02-26 21:00 +0100
        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) The Wanderer <wanderer@fastmail.fm> - 2018-02-26 22:30 +0100

#60256 — 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)

Package: linux-headers-4.14.0-3-amd64
Version: 4.14.17-1

When I build VirtualBox kernel modules using linux-headers-4.14.0-3-amd64 version 4.14.17-1, the resulting modules can't be loaded using linux-image-4.14.0-3-amd64 version 4.14.13-1. When I build the same modules using headers version 4.14.13-1, they load successfully.

Here are some error messages:

systemd[1]: Starting LSB: VirtualBox Linux kernel module...
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r15 (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rax (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rdx (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r14 (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rbx (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r13 (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r10 (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rcx (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rsi (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r9 (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r12 (err 0)
kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r8 (err 0)
virtualbox[6834]: Loading VirtualBox kernel modules...modprobe vboxdrv failed. Please use 'dmesg' to find out why ... failed!
virtualbox[6834]:  failed!

[toc] | [next] | [standalone]

#60257 — Bug#890999: marked as done (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))

[Multipart message — attachments visible in raw view] — view raw

Your message dated Wed, 21 Feb 2018 14:30:56 +0100
with message-id <1519219856.2388.7.camel@debian.org>
and subject line Re: 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)
has caused the Debian Bug report #890999,
regarding 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)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
890999: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890999
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#60365 — 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)

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#60367 — 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)

[Multipart message — attachments visible in raw view] — view raw

Or in other words: the unexpected behavior here is on the part of DKMS,
in removing working modules when the ones which will be put in as their
replacements do not work, not on the part of the kernel headers (et
cetera) themselves.

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

[toc] | [prev] | [next] | [standalone]

#60369 — 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)

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#60372 — 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)

[Multipart message — attachments visible in raw view] — view raw

On 2018-02-26 at 14:55, Ben Hutchings wrote:

> On Mon, 2018-02-26 at 12:07 -0500, The Wanderer wrote:

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

It's possible that it actually doesn't. I believe the rebuild that
triggered the problem, for me, was triggered not by an upgrade of
linux-headers-ABINAME but by an upgrade of virtualbox-dkms; the
linux-headers-* package was upgraded much earlier, I believe on January
21st. (And IIRC the matching linux-image-* package was upgraded at the
same time.)

Off the top of my head, I don't see any potential way for DKMS to know
whether it's being asked to build against the sources of the running
kernel, vs. simply the sources of the currently installed kernel - and
I'm fairly sure that making the correct decision about whether or not to
rebuild when upgrading non-kernel packages would require knowing that.

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

The idea of not unloading the module at upgrade time had in fact not
occurred to me. It's an interesting one, and if viable would seem to
offer a way out of the problem, but I'm not sure how viable it would be
in practice.

The upgrade process appears to consist basically of an uninstall
followed by an install. As such, all three of those scenarios would need
to be considered.


As far as I can tell without deeper investigation than I'm currently set
up for, what DKMS currently does at upgrade is to delete the old
modules, build the new ones, unload the old ones, and then load the new
ones. (I'm basing this on the output messages during the upgrade; I've
dug for the place where the underlying commands get run and the messages
get generated, but I haven't found anything I'm confident is the right
place.)

If there's a way to load the new module without unloading the other
first - if, e.g., the kernel will detect the collision and automatically
unload the old one after validating the new - it should be possible to
have DKMS do that, and skip the unload entirely. However, I don't
remember seeing any indication that such a way exists.

If there's a way to detect whether the newly-built modules will be
compatible with the currently-running kernel before trying to load them,
it might be possible to have DKMS skip the unload and subsequent load if
the latter would fail. Again, however, I don't know of any such way.

If neither of those things is possible, then the choices would seem to
be to either never unload (meaning that the old module would remain in
use until sysadmin intervention), or always unload (basically the
current situation).


What DKMS currently does at uninstall time I don't know. Clearly,
however, it would need to unload the module, as otherwise the uninstall
could not be considered complete. However, it's not clear to me that
there's any way for it to be able to tell a "permanent uninstall"
removal from an "upgrade" removal.


At install time, plainly DKMS needs to load the just-built module, but
again it's not clear to me that there's any way for it to tell a "clean
install" build from an "upgrade" build.


(That said, I've also seen my entire system hardlock when upgrading
VirtualBox packages while a VirtualBox VM was running, and it seems very
plausible that the lockup was because a module which was in use by
VirtualBox got automatically unloaded by DKMS. If it's possible to
design so as to avoid that automatic unload, without unacceptable
tradeoffs, that would make managing my upgrades easier.)

> If you mean replacing the module on disk, I disagree; it should
> build modules for the installed kernel version.

Certainly it should, and if there's no way to do that without removing
the existing modules from the disk, then that's what it should do -
possibly with a warning message or even an "are you sure?" prompt, but
still.

I had thought that the DKMS upgrade-time messages about "module was
ACTIVE" and "module version" and "original module" carried the
implication that it was possible to have DKMS managing multiple versions
of a given module for a given kernel at once, but digging deeper seems
to indicate that this functionality is intended for cases where you're
building a replacement for a shipped module, not when building a new
module not provided by the shipped kernel. So the idea of simply
switching the in-use module to "not ACTIVE" and leaving it on the
system, so that the sysadmin can switch back to it if something goes
wrong with the built replacement, doesn't look viable on closer
examination.

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web