[slvd.] ERROR: could not insert 'vboxdrv': Exec format error

[curmudgeon]

Attempted to upgrade virtualbox-bin. Stopped it, did rmmod on all of the kernel modules, and then did the upgrade. I can not load any of the new modules.

Code: Select all

# ls -al /lib/modules/4.4.39-gentoo/misc/
total 496
drwxr-xr-x 2 root root   4096 2020-06-20 15:11:33 ./
drwxr-xr-x 6 root root   4096 2020-06-20 15:11:35 ../
-rw-r--r-- 1 root root 424744 2020-06-20 15:11:29 vboxdrv.ko
-rw-r--r-- 1 root root  10704 2020-06-20 15:11:29 vboxnetadp.ko
-rw-r--r-- 1 root root  28080 2020-06-20 15:11:29 vboxnetflt.ko
-rw-r--r-- 1 root root  26112 2020-06-20 15:11:29 vboxpci.ko

# modprobe vboxdrv
modprobe: ERROR: could not insert 'vboxdrv': Exec format error
# modprobe vboxnetadp
modprobe: ERROR: could not insert 'vboxnetadp': Exec format error
# modprobe vboxnetflt
modprobe: ERROR: could not insert 'vboxnetflt': Exec format error
# modprobe vboxpci
modprobe: ERROR: could not insert 'vboxpci': Exec format error

Any idea what is going on? My searches only found cases where people had built a new kernel, but hadn't rebooted, and that doesn't apply here.

Thank you in advance.

[NeddySeagoon]

curmudgeon,

Is there any more information at the end of dmesg?

[Hu]

Is 4.4.39 the kernel you are running? That is very old (December 2016). Perhaps virtualbox built for a kernel older than the one you are using, in which case it effectively has not built useful modules at all.

[curmudgeon]

Is there any more information at the end of dmesg?

Hadn't checked that before (and I should have). The modprobe command for any of the four modules produces this messages (referring to vboxdrv whichever module I attempt to load):

Code: Select all

kernel: module: vboxdrv: Unknown rela relocation: 4

[NeddySeagoon]

curmudgeon,

What does

Code: Select all

uname -a

return?

[curmudgeon]

What does

Code: Select all

uname -a

return?

Code: Select all

$ uname -a
Linux system 4.4.39-gentoo #1 SMP Sun Nov 5 00:01:15 UTC 2017 x86_64 Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz GenuineIntel GNU/Linux

[curmudgeon]

With the log line from messages, I found this thread:

https://forums.gentoo.org/viewtopic-t-1096172..html

It appears that modules compiled with binutils 2.31 or later simply will not work on a kernel compiled with a binutils before 2.31 (why did no one ever warn us of this?).

That is very old (December 2016). Perhaps virtualbox built for a kernel older than the one you are using, in which case it effectively has not built useful modules at all.

I didn't believe that virtualbox-bin 6.0.x would build modules with 4.4.39, and that a later 6.0.x wouldn't, but I have taken this opportunity to upgrade to a shiny new 4.4.221.

Everything appears to work now. Thank you, again.

[Hu]

It appears that modules compiled with binutils 2.31 or later simply will not work on a kernel compiled with a binutils before 2.31 (why did no one ever warn us of this?).

If I were to guess, I would guess a few things:

1. It only affects a subset of users, most of whom are only impacted because they use out-of-tree modules. Anyone who uses only in-tree modules built at the same time as the kernel itself will use the same binutils for everything. Anyone who uses out-of-tree modules and builds them promptly after building the kernel will also not be impacted. Building an in-tree module well after the rest of the kernel is allowed, but not guaranteed to work, depending on the configuration options involved. Since it is not fully reliable, some people may opt not to expect that to work, and instead do a full clean+build+reboot in that case, which will protect them. Additionally, since late-built in-tree modules are known not to always work, such a user might try building without rebooting, see it fail, and retry with a rebuilt kernel as a standard procedure. This leaves only the people like you, who build out-of-tree modules well after the main kernel, and do not rebuild the kernel at the same time.
2. Anyone who keeps current on their kernel patches will have a relatively low uptime, and if they are impacted at all, it will be automatically fixed within a few weeks when the next stable kernel comes out and they update to that, then rebuild everything for their updated kernel.
3. The problem may not have been escalated to the right people to issue the warning, or those people may have generated the same list I did above, and decided that it was not worth an announcement because too few people would be impacted. (Note: I am not making a value judgment of whether that decision, if it even happened, was the right decision. I am merely speculating that it could have happened and turned out that way, and would lead to not putting out the announcement.)