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

Re: Re: virtualbox fails to compile module on 3.10

Dear Ralf, dear Hugo,

I'm stuck with the same problem as Kent. I'm running on Wheezy with the
3.10-0.bpo.3-amd64 kernel (backports).

The problem is actually that the virtualbox versions (esp. the OSE one)
from the repositories do not work with new kernels (newer than 3.2 as
far as I checked). It is clear that we can install the Oracle version,
however it is not optimal.

I installed the virtualbox-ose-dkms package and all dependencies
obviously. Virtualbox version is 4.1.18. During install it returns the
following:

Stopping VirtualBox kernel modules.
Starting VirtualBox kernel modulesNo suitable module for running kernel
found ... failed!
 failed!
invoke-rc.d: initscript virtualbox, action "restart" failed.
Setting up virtualbox-qt (4.1.18-dfsg-2+deb7u1) ...
Setting up virtualbox-ose-dkms (4.1.18-dfsg-2+deb7u1) ...
Processing triggers for menu ...


Then I tried to rebuild using dkms with the following result:

dkms build virtualbox/4.1.18 -k 3.10-0.bpo.3-amd64/amd64

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area....
make KERNELRELEASE=3.10-0.bpo.3-amd64 -C
/lib/modules/3.10-0.bpo.3-amd64/build
M=/var/lib/dkms/virtualbox/4.1.18/build.....(bad exit status: 2)
Error! Bad return status for module build on kernel: 3.10-0.bpo.3-amd64
(amd64)
Consult /var/lib/dkms/virtualbox/4.1.18/build/make.log for more information.


And after that the log looks like this:

cat /var/lib/dkms/virtualbox/4.1.18/build/make.log
DKMS make.log for virtualbox-4.1.18 for kernel 3.10-0.bpo.3-amd64 (amd64)
Sun Oct 13 11:06:00 CEST 2013
make: Entering directory `/usr/src/linux-headers-3.10-0.bpo.3-amd64'
  LD      /var/lib/dkms/virtualbox/4.1.18/build/built-in.o
  LD      /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/built-in.o
  CC [M]  /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/SUPDrv.o
  CC [M]  /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/SUPDrvSem.o
  CC [M]  /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/alloc-r0drv.o
  CC [M]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/initterm-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/memobj-r0drv.o
  CC [M]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/mpnotification-r0drv.o
  CC [M]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/powernotification-r0drv.o
  CC [M]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/assert-r0drv-linux.o
  CC [M]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o
  CC [M]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/initterm-r0drv-linux.o
  CC [M]
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:
In function ‘rtR0MemObjNativeMapUser’:
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1451:38:
error: ‘VM_RESERVED’ undeclared (first use in this function)
/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1451:38:
note: each undeclared identifier is reported only once for each function
it appears in
make[4]: ***
[/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o]
Error 1
make[3]: *** [/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv] Error 2
make[2]: *** [_module_/var/lib/dkms/virtualbox/4.1.18/build] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-headers-3.10-0.bpo.3-amd64'



I suppose, that it is not intended for it to be that way, unfortunately
I have neither an idea how to fix it nor resources for doing it. It
would be great however, if someone were able to update the repositories
(something such as here:
http://www.preining.info/blog/2013/08/debian-virtualbox-kernel/) for the
combination Wheezy, backport 3.10 kernel and the repository version of
virtualbox. I know it is probably a lot to ask, but it will make our
life easier by not having to go outside of the APT concept. I hope, that
the provided logs here can help any enthusiast, who is planning on
tackling this problem.

Kind Regards,
Nickolay
Reply to: