It's common practice to deliver Linux kernel drivers (kernel objects KOs) in the source code, and build and install them on the target computer. For example Nvidia display drivers, Oracle VirtualBox guest add-on drivers are installed this way. It is also common to receive new version of kernel (with appropriate headers) through system update. This requires the KO to be re-built and re-installed, otherwise the device will stop working after update.

In our product installation startup script we want to add the step to make and install the KO on every boot. User may choose to opt-out, and would have to build and install the KO manually. The device driver communicates with a USB device. Pertinent Details: 1. The Actual re-build will happen only once when the new kernel is installed, because make will not try to re-build the file that is already there and up-to date. 2. It takes about 2 seconds to rebuild the driver, and milliseconds to skip the build during the normal boot (not after kernel update) 3. In the unlikely event that build will fail, it should not crash the system or make it unstable, however our hardware device will not work. 4. Some distributions may allow to register hooks, to do actions on certain events, like kernel update. However, we are trying to implement something that will work on the most of the distributions in the uniform way. Our installer is script+tar or script+rpm. Unfortunately for this release we do not have bandwidth to prepare native packages for all the distributions (for example debian style).

Questions: 1. Is this an acceptable solution? If not, why? 2. What are the potential risks associated with this approach? 3. What the correct/preferred place to run make during startup? rc.local or script under init.d or other? The goal is to make it work on the most of the distributions using the same method (if at all possible).


1) yes, but you should add a clear howto describing the way we can run your script manually so we can make sure the script will return normally. In the case of virtualbox in centos they add a script in /etc/init.d called vboxdrv

Usage: /etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}

This is clear, we can start/stop the script and get it's status, so the risk of getting problems at reboot is minimal as long as we can check the script on a new kernel before deploying it. You cannot have more standard than this, for me it's perfect.

2) systematical failure of the compile process and no module available. Is it this tragic ? I don't think so. As long as your script doesn't hang the machine and you give a comlpete log of the compile failure in /var/log/mymodule, you cannot do better than that.

3) see 1) On centos/RHEL/fedora) the vboxdrv runs from /etc/init.d/vboxdrv and checks the distribution name, then source some scripts accordingly. /etc/init.d is the first place I check when I want more informations about a daemon. It's fine with me.

  • This answer pretty much answers my question and looks like Sun/Oracle may be doing the same thing for /etc/init.d/vboxdrv. Basically we should create /etc/init.d/usbdpfpdrv One very useful additional comment: need to write build log into /var/log/usbdpfpdrv-install.log – Randalli Oct 28 '10 at 23:32

It is going to depend on what your hardware is.

If you do this, be absolutely sure that your script times out in a few seconds, otherwise you're likely to have a lot of admins wondering why some machine in a colocation facility on the other side of the country didn't come back up after the kernel upgrade.

If your hardware is critical to the boot process (perhaps a network dongle or usb drive) then it'll need to be done earlier (probably before the new kernel is booted). Otherwise you'd want to get it done as late as possible to make sure any network-mounted filesystems that might be needed for the compiler are in place. That will also help make sure a MTA is running so your build process can send root an email if the module couldn't be built for some reason.


The Dynamic Kernel Module Support(DKMS), detailed here, allows you to pre-build the driver before you reboot. The Linux Journal has an article, "Exploring DKMS" that goes into a lot of detail about how to use and configure DKMS.

If you can rebuild before the reboot, your confidence will go up that a reboot will happen correctly and quickly.

  • Interesting and relevant post. If one looks at the vboxdrv scripts, it can be seen that they check if dkms is installed and if so they use it. We may have time to do something similar. – Randalli Oct 29 '10 at 22:13

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.