dkms is not processing vboxdrv, must do manually

As I recall, under Jaunty, there was a dkms service in /etc/init.d that would automatically recompile kernel modules if you were booting a new kernel. That service is no longer there. Is that a design decision or an oversight as a result of the switch to upstart or a bug? Is it possible to re-enable this behavior? I need dkms for nvidia binary drivers and virtualbox drivers.

Jeff:

That's a design decision. Kernel modules will be built by kernel
postinstall scripts and module package post install scripts.

On Wed, Jul 14, 2010 at 09:48, Jeff Epstein <email address hidden>wrote:

> As I recall, under Jaunty, there was a dkms service in /etc/init.d that
> would automatically recompile kernel modules if you were booting a new
> kernel. That service is no longer there. Is that a design decision or an
> oversight as a result of the switch to upstart or a bug? Is it possible
> to re-enable this behavior? I need dkms for nvidia binary drivers and
> virtualbox drivers.
>
> --
> dkms is not processing vboxdrv must do manually
> https://bugs.launchpad.net/bugs/600517
> You received this bug notification because you are subscribed to dkms in
> ubuntu.
>

--
Mario Limonciello
<email address hidden>

Mario,

Thanks for replying. So, one consequence of this design decision is that if you select a different kernel from the GRUB boot menu, dkms modules will fail to build for that kernel and subsequently won't load. This creates a negative user experience, if the user (like me) expects to be able to switch freely between between kernel versions. This can be especially harmful if (again, as in my case) a new kernel version introduces a regression, and so I try to boot the old version, but now that version doesn't work either due to not loading kernel modules; the result is that no matter what version I select from GRUB, I have a broken system.

So, I would urge you to reconsider that design decision.

In any case, is it possible to re-enable the old behavior of automatically rebuilding kernel modules on boot as necessary?

Jeff:

The modules should have been previously built for that kernel. Why is that not the case for you?

This decision was made in the preference of boot speed. Having a shell script in every boot to check kernel modules slowed it down. You can create your own upstart script to do this (or init script). The DKMS auto installer is in /usr/lib/dkms still.

Mario,

The kernel modules in question (virtualbox and nvidia) weren't already built for me because I installed them after I upgraded to the new kernel. Other users in a similar situation will have the same problem.

Yes, running the following command worked. Thanks.

sudo /usr/lib/dkms/dkms_autoinstaller start `uname -r`

Jeff:

This should be addressed by the module packages themselves. They have the
option to build for all kernels or just the kernel in question, so I would
recommend directing bugs there if you think this is a big deal.

On Wed, Jul 14, 2010 at 11:04, Jeff Epstein <email address hidden>wrote:

> Mario,
>
> The kernel modules in question (virtualbox and nvidia) weren't already
> built for me because I installed them after I upgraded to the new
> kernel. Other users in a similar situation will have the same problem.
>
> Yes, running the following command worked. Thanks.
>
> sudo /usr/lib/dkms/dkms_autoinstaller start `uname -r`
>
> --
> dkms is not processing vboxdrv must do manually
> https://bugs.launchpad.net/bugs/600517
> You received this bug notification because you are subscribed to dkms in
> ubuntu.
>

--
Mario Limonciello
<email address hidden>

The problem is that the module has to be rebuilt at every reboot of the system. The system does not remember the same module of the same kernel.

Real World situation:
Every day that I go to work I need to run a virtual machine on my laptop.
Every day when I start up the laptop I have to rebuild the kernel module (which takes 5-10 minutes).
In previous versions of Ubuntu when I would start the laptop (using the same kernel) the vitual machine would "just work"

Doing this every day has become a major irritator. The kernel module should only have to be built one time, when a kernel has changed... Ubuntu Lucid should keep the kernel module each time, so I don't have to rebuild every day.

I understand the need for speed (10 second from power off to desktop is excellent).
but I don't understand why an already built module is not rememberd by the current kernel

Thus this is still a bug.

Plus that whole 10 seconds boot time is lost, when you spend another 15 minutes configuring your system just so you can start to work with it.

hey Kat, that shouldn't happen, and hasn't been the issue discussed thus far. Once the module is built with dkms, it shouldn't need to be built again.

Having to rerun the build multiple times Is certainly a different bug. I
would say that is important to fix.

Do we have an understanding for what is happening there? When you run
modinfo on the next boot is the module not there? Is something deleting it?

If we were to add an init script or upstart job, that would just be a band
aid to the real problem at hand.

On Jul 15, 2010 3:15 PM, "Kat Amsterdam" <email address hidden> wrote:

The problem is that the module has to be rebuilt at every reboot of the
system. The system does not remember the same module of the same kernel.

Real World situation:
Every day that I go to work I need to run a virtual machine on my laptop.
Every day when I start up the laptop I have to rebuild the kernel module
(which takes 5-10 minutes).
In previous versions of Ubuntu when I would start the laptop (using the same
kernel) the vitual machine would "just work"

Doing this every day has become a major irritator. The kernel module
should only have to be built one time, when a kernel has changed...
Ubuntu Lucid should keep the kernel module each time, so I don't have to
rebuild every day.

I understand the need for speed (10 second from power off to desktop is
excellent).
but I don't understand why an already built module is not rememberd by the
current kernel

Thus this is still a bug.

--
dkms is not processing vboxdrv must do manually
https://bugs.launchpad.net/bugs/600517
You rece...

Mario,

Per your suggestion to address this issue to the individual modules. So far as I can tell, all dkms-using modules in the repositories only contain install scripts to build for the current kernel, and therefore they all suffer this problem. Would you suggest creating a separate bug report for each package that uses dkms?

Yes, the problem is that dkms has to be re-run every day. The module is not remembered across a reboot.

If you re-read the original bug report I stated:

"every day I have to run /etc/init.d/vboxdrv setup because the ubuntu DKMS package is not doing it's job."

"What really happens:
The dkms package does not compile the driver or give access, so every time the machine (HP tx2 1050ed laptop) reboots, the kernel driver has to be compiled manually (at 7 minutes of lost productivity)"

every day
and
every reboot

I thought was enough information. Let me know how I can state this clearer in the future for future bug reports.

Jeff's issue is similar as again the modules are not remembered (deleted is speculation) on reboot across kernels...

But the core bug is... having to run dkms by hand at every reboot.

Jeff:
Your bug is similar but is confusing the issue slightly.

From what I experience the kernel module has to be rebuilt at every reboot no matter which kernel I do it in or when I install the package.

Try to reboot into the same kernel twice and see if you can start nvdia and vboxdrv (although you already applied
sudo /usr/lib/dkms/dkms_autoinstaller start `uname -r` in #6 so may not have an original situation anymore)

If you do not have the issue that you have to rebuild the kernel module at every reboot to the same kernel please file a new bug

I have not applied the suggestion in #6 so that my machine is still available for testing to solve this bug.

I did a modprobe -l vboxdrv after a fresh reboot
and started virtualbox and made a screenshot
This is what I am experiencing.

as you can see the module is there... but it's not loaded.

so this is what I meant by Ubuntu not remembering the module.

Here is the virutal box install log. There are many DKMS errors in it.
May be a help in solving the bug.

I investigated the logging and discovered the dkms.conf file.
It contains everything that the logging is complaining that it doesn't have:

--log error --
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
---------------

---- from dkms.conf --
DEST_MODULE_LOCATION=/kernel/misc
PACKAGE_NAME=vboxdrv
PACKAGE_VERSION=3.2.6
----------------------------

so why is dkms throwing errors when the information it is searching for is clearly available??

fwiw, I installed vbox from the oracle website, and dkms seems to be working as expected, in that the modules build and are available after a reboot.

I'm still experiencing the issue where the vbox modules are only built for the running kernel. Shall I mark my bug un-duped?

oops, forgot to say that I'm running i386 lucid

Daniel:

I am running Lucid x86_64.
And have reproduced this bug this on 3 different machines.

But good to hear that the i386 version is working as expected.

With some experimentation
I was able to start Virutal Box today without recompiling by doing the following:

kat@tabbycat:~$ sudo modprobe vboxdrv
kat@tabbycat:~$ sudo modprobe vboxnetadp
kat@tabbycat:~$ sudo modprobe vboxnetflt

Can anyone enlighten me as to why these three are not being loaded at boot or login even though they have been built by dkms?

does `dkms status` report them as installed?

Here is the result of dkms status... As you can see from my earlier attachment of the dkms.conf file... the file is correct, and the fields it's complaining about are filled.

kat@tabbycat:~$ dkms status
bcmwl, 5.60.48.36+bdcom, 2.6.32-21-generic, x86_64: installed
bcmwl, 5.60.48.36+bdcom, 2.6.32-22-generic, x86_64: installed
bcmwl, 5.60.48.36+bdcom, 2.6.32-23-generic, x86_64: installed
bcmwl, 5.60.48.36+bdcom, 2.6.32-24-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-22-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-23-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxdrv, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxdrv, 3.2.6, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxnetadp, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxnetadp, 3.2.6, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxnetflt, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxnetflt, 3.2.6, 2.6.32-24-generic, x86_64: installed
virtualbox-ose, 3.2.0, 2.6.32-22-generic, x86_64: installed (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!)
virtualbox-ose, 3.2.0, 2.6.32-23-generic, x86_64: installed (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!)
virtualbox-ose, 3.2.0, 2.6.32-24-generic, x86_64: installed (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!)

I noticed I had this package installed

virtualbox-ose-dkms

I removed the package but am still getting the error:

It looks like DKMS is building for the wrong kernel.

kat@tabbycat:~$ dkms status
bcmwl, 5.60.48.36+bdcom, 2.6.32-24-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-22-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-23-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxdrv, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxdrv, 3.2.6, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxnetadp, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxnetadp, 3.2.6, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxnetflt, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxnetflt, 3.2.6, 2.6.32-24-generic, x86_64: installed

As can be read here:
http://ubuntuforums.org/showthread.php?t=1530691&page=4
I am not the only one with this issue.

Out of frustration I've removed all the headers and images for any older kernels on my system.
Including the 2.6.32-22 generic that dkms was holding on to.

I also tried the solution in #6
sudo /usr/lib/dkms/dkms_autoinstaller start `uname -r`

but this was unsuccesful. dkms kept holding on to 2.6.32-22

at@tabbycat:~$ sudo /usr/lib/dkms/dkms_autoinstaller start `uname -r`
[sudo] password for kat:
 * Running DKMS auto installation service for kernel 2.6.32-24-generic * bcmwl (5.60.48.36+bdcom)... [ OK ]
 * fglrx (8.723.1)... [ OK ]
 * vboxdrv (3.2.6)... [ OK ]
 * vboxnetadp (3.2.6)... [ OK ]
 * vboxnetflt (3.2.6)... [ OK ]
                                                                         [ OK ]

Still returns:

kat@tabbycat:~$ dkms status
bcmwl, 5.60.48.36+bdcom, 2.6.32-24-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-22-generic, x86_64: built
fglrx, 8.723.1, 2.6.32-23-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxdrv, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxdrv, 3.2.6, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxnetadp, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxnetadp, 3.2.6, 2.6.32-24-generic, x86_64: installed
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
vboxnetflt, 3.2.4, 2.6.32-22-generic, x86_64: built
vboxnetflt, 3.2.6, 2.6.32-24-generic, x86_64: installed

Here is more of what I've tried:

1608 sudo chmod a-rwx 3.2.4
 1609 ls -l
 1610 cd ../vboxnetadp/
 1611 sudo chmod a-rwx 3.2.4
 1612 cd ../vboxnetflt/
 1613 sudo chmod a-rwx 3.2.4
 1614 dkms status
=== result ===
bcmwl, 5.60.48.36+bdcom, 2.6.32-24-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-22-generic, x86_64: built
fglrx, 8.723.1, 2.6.32-23-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-24-generic, x86_64: installed
vboxdrv, 3.2.4: added
vboxdrv, 3.2.6, 2.6.32-24-generic, x86_64: installed
vboxnetadp, 3.2.4: added
vboxnetadp, 3.2.6, 2.6.32-24-generic, x86_64: installed
vboxnetflt, 3.2.4: added
vboxnetflt, 3.2.6, 2.6.32-24-generic, x86_64: installed
====
 1615 sudo dkms remove -m vboxdrv -v 3.2.4 -k 2.6.32-22-generic

kat@tabbycat:~$ sudo dkms remove -m vboxdrv -v 3.2.4 -k 2.6.32-22-generic
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.

Error! Bad conf file.
File: /var/lib/dkms/vboxdrv/3.2.4/source/dkms.conf does not represent
a valid dkms.conf file.

dkms won't even let me remove the module by hand.

So I worked around the bug the old fashioned way.

Purged dkms completely from my system, then removed the folder /var/lib/dkms
then reinstalled my videocard and wireless network adapter drivers
Then reconfigured virutalbox

1640 sudo aptitude purge dkms
 1641 cd ~
 1642 sudo rm -r /var/lib/dkms
 1643 sudo aptitud install dkms
 1644 sudo aptitude install dkms
 1645 dkms status
 1646 sudo dpkg-reconfigure virtualbox-3.2
 1647 dkms status

bcmwl, 5.60.48.36+bdcom, 2.6.32-24-generic, x86_64: installed
fglrx, 8.723.1, 2.6.32-24-generic, x86_64: installed
vboxdrv, 3.2.6, 2.6.32-24-generic, x86_64: installed
vboxnetadp, 3.2.6, 2.6.32-24-generic, x86_64: installed
vboxnetflt, 3.2.6, 2.6.32-24-generic, x86_64: installed

Question remains. Why does dkms get stuck, holding on to old entries, without cleaning them up?

After a reboot, it still fails.

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing

'/etc/init.d/vboxdrv setup'

(/dev/vboxdrv) does not exist.

This still works as a workaround. :(

kat@tabbycat:~$ sudo modprobe vboxdrv
kat@tabbycat:~$ sudo modprobe vboxnetflt
kat@tabbycat:~$ sudo modprobe vboxnetadp

Status changed to 'Confirmed' because the bug affects multiple users.

Bug still active in Precise!

Every time i install a new kernel, this problem comes up and i have to do an manual setup by:

sudo /etc/init.d/vboxdrv setup

* Stopping VirtualBox kernel modules
                                                                                                                                                                                                 [ OK ]
 * Uninstalling old VirtualBox DKMS kernel modules
                                                                                                                                                                                    [ OK ]
 * Trying to register the VirtualBox kernel modules using DKMS
                                                                                                                                                                        [ OK ]
 * Starting VirtualBox kernel modules
                                                                                                                                                                                                 [ OK ]

Will there be an solution in 201x?
It is a SHAME that those old bug is in an LTS!

Xubuntu 12.04.1
Linux xubuntu3 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

dkms
Versions:
2.2.0.3-1ubuntu3.1 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise-updates_main_binary-amd64_Packages) (/var/lib/dpkg/status)

virtualbox
Versions:
4.1.12-dfsg-2ubuntu0.2 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise-updates_universe_binary-amd64_Packages) (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise-security_universe_binary-amd64_Packages)

hummmmmmmmm I just had to do that with the update to the next kernnel in 12.10 sudo /etc/init.d/vboxdrv setup
I can almost type it in my sleep now that I have done it so many times now

Works for me now since the new kernel 3.5.0-28-generic #48~precise1-Ubuntu

Can please somebody confirm this or are i'm the only one?