Linux 2.6.32 + VBox + dkms doesn't work => Fixed in SVN

[pico_c_nickel]

Hello,

I have the following errors in dmesg after a kernel update:

vboxnetflt: no symbol version for RTSemFastMutexCreate
vboxnetflt: Unknown symbol RTSemFastMutexCreate
vboxnetflt: no symbol version for RTR0Init
vboxnetflt: Unknown symbol RTR0Init
vboxnetflt: no symbol version for SUPDrvLinuxIDC
vboxnetflt: Unknown symbol SUPDrvLinuxIDC
vboxnetflt: no symbol version for RTSpinlockRelease
vboxnetflt: Unknown symbol RTSpinlockRelease
vboxnetflt: no symbol version for RTSemEventDestroy
vboxnetflt: Unknown symbol RTSemEventDestroy
vboxnetflt: no symbol version for RTUuidFromStr
vboxnetflt: Unknown symbol RTUuidFromStr
vboxnetflt: no symbol version for RTSemEventSignal
vboxnetflt: Unknown symbol RTSemEventSignal
vboxnetflt: no symbol version for RTErrConvertFromErrno
vboxnetflt: Unknown symbol RTErrConvertFromErrno
vboxnetflt: no symbol version for RTSemEventWait
vboxnetflt: Unknown symbol RTSemEventWait
vboxnetflt: no symbol version for RTMemAllocZ
vboxnetflt: Unknown symbol RTMemAllocZ
vboxnetflt: no symbol version for RTErrConvertToErrno
vboxnetflt: Unknown symbol RTErrConvertToErrno
vboxnetflt: no symbol version for RTSemFastMutexRequest
vboxnetflt: Unknown symbol RTSemFastMutexRequest
vboxnetflt: no symbol version for RTSpinlockCreate
vboxnetflt: Unknown symbol RTSpinlockCreate
vboxnetflt: no symbol version for RTLogRelDefaultInstance
vboxnetflt: Unknown symbol RTLogRelDefaultInstance
vboxnetflt: no symbol version for RTMemFree
vboxnetflt: Unknown symbol RTMemFree
vboxnetflt: no symbol version for RTSemFastMutexRelease
vboxnetflt: Unknown symbol RTSemFastMutexRelease
vboxnetflt: no symbol version for RTTimeNanoTS
vboxnetflt: Unknown symbol RTTimeNanoTS
vboxnetflt: no symbol version for RTSpinlockDestroy
vboxnetflt: Unknown symbol RTSpinlockDestroy
vboxnetflt: no symbol version for RTSemEventCreate
vboxnetflt: Unknown symbol RTSemEventCreate
vboxnetflt: no symbol version for RTSpinlockAcquire
vboxnetflt: Unknown symbol RTSpinlockAcquire
vboxnetflt: no symbol version for RTR0Term
vboxnetflt: Unknown symbol RTR0Term
vboxnetflt: no symbol version for RTUuidCompareStr
vboxnetflt: Unknown symbol RTUuidCompareStr
vboxnetflt: no symbol version for RTSemFastMutexDestroy
vboxnetflt: Unknown symbol RTSemFastMutexDestroy

Those errors appear after automatic module building by dkms during boot after kernel update. DKMS displays that building of vboxnetadp, vboxnetflt and vboxdrv is done but loading the modules during boot fails. Manually building by invoking /etc/init.d/vboxdrv setup and manually loading by invoking /etc/init.d/vboxdrv start works without problems!

I'm using Virtualbox 3.1.2 and dkms 2.1.1.0 on a 32-Bit Debian unstable with kernel 2.6.32.2 This happens with VBox 3.1.0 and the kernels 2.6.32.1 and 2.6.32.0, too.

Thanks in advance.

[pico_c_nickel]

It happens with Linux Kernel 2.6.32.3, too!

[Frank Mehnert]

Well, if you invoke /etc/init.d/vboxdrv setup, the modules are built using DKMS as well which should be visible in the file /var/log/vbox-install.log. Maybe there is a problem with DKMS on current Debian unstable.

[pico_c_nickel]

I made a Bug-Report for dkms on Debian: ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567460

[pico_c_nickel]

Hello,

after just updating my kernel, I searched for log-files again and I found one in /var/lib/dkms/vboxnetflt/kernel-2.6.32-7.slh.3-sidux-686-i686/log/make.log:

DKMS make.log for vboxnetflt-3.1.4_BETA1 for kernel 2.6.32-7.slh.3-sidux-686 (i686) Do 4. Feb 00:00:25 CET 2010 make: Entering directory `/usr/src/linux-headers-2.6.32-7.slh.3-sidux-686'

LD /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/built-in.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/linux/VBoxNetFlt-linux.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/VBoxNetFlt.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/SUPR0IdcClient.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/SUPR0IdcClientComponent.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/SUPR0IdcClient-linux.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/divdi3.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/moddi3.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/qdivrem.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/udivdi3.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/umoddi3.o LD [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.o Building modules, stage 2. MODPOST 1 modules

WARNING: "RTSemFastMutexDestroy" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTUuidCompareStr" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTR0Term" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSpinlockAcquire" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSemEventCreate" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSpinlockDestroy" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTTimeNanoTS" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSemFastMutexRelease" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTMemFree" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTLogRelDefaultInstance" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSpinlockCreate" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSemFastMutexRequest" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTErrConvertToErrno" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTMemAllocZ" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSemEventWait" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTErrConvertFromErrno" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSemEventSignal" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTUuidFromStr" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSemEventDestroy" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSpinlockRelease" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "SUPDrvLinuxIDC" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTR0Init" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined! WARNING: "RTSemFastMutexCreate" var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko undefined!

CC /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.mod.o LD [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko

make: Leaving directory `/usr/src/linux-headers-2.6.32-7.slh.3-sidux-686'

This log is right after the automatic module build during the kernel update!

The next one is right after rebooting and manually invoking /etc/init.d/vboxdrv setup

DKMS make.log for vboxnetflt-3.1.4_BETA1 for kernel 2.6.32-7.slh.3-sidux-686 (i686) Do 4. Feb 00:17:45 CET 2010 make: Entering directory `/usr/src/linux-headers-2.6.32-7.slh.3-sidux-686'

LD /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/built-in.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/linux/VBoxNetFlt-linux.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/VBoxNetFlt.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/SUPR0IdcClient.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/SUPR0IdcClientComponent.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/SUPR0IdcClient-linux.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/divdi3.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/moddi3.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/qdivrem.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/udivdi3.o CC [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/math/gcc/umoddi3.o LD [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.o Building modules, stage 2. MODPOST 1 modules CC /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.mod.o LD [M] /var/lib/dkms/vboxnetflt/3.1.4_BETA1/build/vboxnetflt.ko

make: Leaving directory `/usr/src/linux-headers-2.6.32-7.slh.3-sidux-686'

As you can see there are no more errors and the kernel module loads without any error!

Hope this helps!?

[pico_c_nickel]

*sorry for the above confusing post including the log-files...overlooked the attachment-button. *can be deleted

Hello,

after just updating my kernel, I searched for log-files again and I found one in /var/lib/dkms/vboxnetflt/kernel-2.6.32-7.slh.3-sidux-686-i686/log/make.log

during_kernel_update.txt

This log is right after the automatic module build during the kernel update!

The next one is right after rebooting and manually invoking /etc/init.d/vboxdrv setup

manually_building_after_reboot.txt

As you can see there are no more errors and the kernel module loads without any error!

Hope this helps!?

[Frank Mehnert]

The problem is that apparently only the vboxnetflt modules is compiled but each time, all three modules (vboxdrv, vboxnetflt, vboxnetadp) should be compiled using this order. Could you post the output of

dkms status

?

[pico_c_nickel2]

Output of dkms status

vboxnetadp, 3.1.4_BETA2, 2.6.32-7.slh.7-sidux-686, i686: installed
vboxnetadp, 3.1.4_BETA2, 2.6.32-7.slh.5-sidux-686, i686: installed
vboxnetflt, 3.1.4_BETA2, 2.6.32-7.slh.7-sidux-686, i686: installed
vboxnetflt, 3.1.4_BETA2, 2.6.32-7.slh.5-sidux-686, i686: installed
vboxdrv, 3.1.4_BETA2, 2.6.32-7.slh.7-sidux-686, i686: installed
vboxdrv, 3.1.4_BETA2, 2.6.32-7.slh.5-sidux-686, i686: installed

Afterwards I'll add the log-files of all three modules. According to the timecodes contained in the log-files the order of compiling is vboxnetadp, vboxnetflt, vboxdrv which is wrong, right?

[Frank Mehnert]

The question is where this order comes from. The correct order would be vboxdrv, vboxnetflt, vboxnetadp. I have to investigate why DKMS chooses a different order on your system. Yes, I'm aware that this is a hack but I'm not aware of a way to solve module dependencies properly with DKMS.

[pico_c_nickel]

Thanks for looking into it. I asked the Debian Maintainer of dkms for looking into it, too. No response by now, though...

[pico_c_nickel]

The Debian maintainer of dkms can't reproduce it with virtualbox-ose-dkms package. Perhaps you can look into that package to investigate the differences between OSE and PUEL? If you need more information I'll try to do so.

[pico_c_nickel]

Hello Frank,

sorry for asking but, were you able to find out anything by now?

[pico_c_nickel]

I found out that the order comes from the command 'find' in the dkms_autoinstaller script. Appending the command sort seems to solve my issue, since the modules are built in alphabetical order. But it's still only a workaround. Do you have any idea for a better solution?

[Frank Mehnert]

I have still no idea, especially because I'm not aware of any other such report. You could still try to completely uninstall + install VirtualBox. And perhaps make sure that you don't have LC_COLLATE set on your host.

[pico_c_nickel]

A complete uninstall and fresh install doesn't solve the problem, I tried that many many times. LC_COLLATE is not set on my host. I'm still waiting for upstream to respond to my assumption that the wrong order comes from the call of "find".

[Martin Kalén]

I think this can be solved by re-structuring the DKMS modules into one. Currently VirtualBox uses three different DKMS modules. Each DKMS module contains one kernel module.

The dkms.conf format allows an array of commands to be specified so that one DKMS module can contain multiple kernel modules (if I understand the format correctly).

Eg:

PACKAGE_NAME="vbox"
PACKAGE_VERSION="3.1.6"

MAKE[0]=(make command to build vboxdrv)
BUILT_MODULE_NAME[0]=vboxdrv
DEST_MODULE_LOCATION[0]=/kernel/misc

MAKE[1]=(make command to build vboxnetflt)
BUILT_MODULE_NAME[1]=vboxnetflt
DEST_MODULE_LOCATION[1]=/kernel/misc

MAKE[2]=(make command to build vboxnetadp)
BUILT_MODULE_NAME[2]=vboxnetadp
DEST_MODULE_LOCATION[2]=/kernel/misc

I don't know if you have to use as many MAKE as BUILT_MODULE_NAME/DEST_MODULE_LOCATION, prefferrably you could now package the DKMS module in one source tree and build all three modules at the same time.

[pico_c_nickel]

Hello mkalen,

thanks for your post, seems to be a simple solution. Frank, what do you think about it?

[ddehnhard]

I want to report that for VB 3.2.4 PUEL and an up-to-date Ubuntu Lucid (the same on a Debian Lenny host) the kernel modules are compiled fine, but only for the running kernel.

This means that after a kernel update via aptitude, the modules are compiled for the running (not the new) kernel and after a reboot with the new kernel VB complains about missing modules and proposes to run /etc/init.d/vboxdrv setup. This will compile the modules for that kernel and VB works then, but it also removes the previously compiled modules. So on booting with the old kernel the same happens again (VB complains, calling vboxdrv compiles only for running kernel and removes the others). virtualbox-ose from the Ubuntu Lucid repositories (3.1.6) works well with dkms and compiles for and runs with all installed kernels. In both cases running 'dkms status' shows the compiled and installed modules as I described.

I looked at launchpad and found a change the maintainers did there: ​https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/497149. Maybe implementing that changes solves this or at least leads to the solution...

P.S. I think this problem fits well into this ticket, but tell me if a seperate ticket is preferred.

[pico_c_nickel]

Hello Frank,

I would like to ask, if there is some progress with my problem? Do you have time to look into it respectively do you still plan to find a fix for that? What do you think about the above posted solution by mkalen?

Thanks in advance.

[pico_c_nickel]

As you can see in the following bug report, I'm not the only one with that problem:

​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586725

Message #18 in that bug report is a possible solution which is used by the officially packaged OSE version of virtualbox in debian. What do you think about that solution? Please address this annoying bug...it seems to me that it is easy to solve...if not, please tell me the reason for that.

[Frank Mehnert]

Just reading through this bug report, can you tell me the exact message which you think is the fix? At least not message 18 ...

[pico_c_nickel]

Message 18 says: ...as of at least 3.2.8 they now only have one dkms directory, and i assume they've set that up in a way that installs modules in the correct order:

$ ls /var/lib/dkms dkms_dbversion virtualbox-ose ...

I think the following file is responsible for that (should be the file dkms.conf which is in /usr/src/vbox*/): ​http://git.debian.org/?p=pkg-virtualbox/virtualbox-ose.git;a=blob;f=debian/virtualbox-ose-dkms.dkms;h=6df12f77303e3ea97211676ace61b9ba9e93375c;hb=HEAD

The build order of the modules is fixed and instead of using 3 individual dkms-modules they aggregate the 3 vbox-modules in one dkms-module I think.

[Martin Kalén]

virtualbox-ose seems to use the same method as I have suggested previously in this bug report (see comment from 2010-05-10 19:17:32). I think the array based dkms.conf format is definitely worth checking out as you can get a well-defined compile order between the "sub-modules".

[Ian MacDonald]

In Ubuntu Lucid 10.04 I encountered this upgrading between 2.6.32-22-generic and 2.6.32-25-generic. It only occurred on of my two systems which I apt-get upgraded today, a couple of weeks behind the other.

Running /etc/init.d/vboxdrv setup resolved the issue, but the problem still remains.

[pico_c_nickel]

Anything new on this? @Frank What do you think about the proposed solution?

[Frank Mehnert]

The next release will contain a fix which should ensure the correct order when compiling the host modules under DKMS. Similar to the OSE version (obj-m += vboxdrv/ vboxnetflt/ vboxnetadp/). The code is already in SVN.

[pico_c_nickel]

Thank you, Frank! I'll wait for the upcoming release and I'll report if the problem is solved for me.

[pico_c_nickel]

Hello Frank,

could you please tell me an estimated date for a new release or new beta release so I can test if it the problem is fixed for me?

Last release was two months ago, seems to me that there is coming something really big...

[pico_c_nickel]

The problem is fixed now! Thanks!