Dynamic Kernel Module Support
scaronni Merge pull request #63 from calancha/master
Fix syntactic error when the system shell is zsh
Latest commit 3fe2f07 Oct 8, 2018
Failed to load latest commit information.
debian update URLs Aug 31, 2016
template-dkms-mkdeb Support modules with a _ in their name in mkdeb Jul 12, 2011
test Add a sample test module, to quickly test dkms functionality Mar 27, 2015
.gitignore release new version to v2.5 and add .gitignore file Nov 30, 2017
AUTHORS Add myself to AUTHORS May 25, 2010
COPYING import of v0.22.04 May 17, 2007
Makefile release new dkms version 2.6.1 Apr 25, 2018
README.md Update README.md Nov 30, 2017
TODO Add TODO. Jun 21, 2007
dkms Merge pull request #61 from c0d3z3r0/for-upstream/fix_rmdir Oct 8, 2018
dkms-freshmeat.txt.in Fix version and date in manpage, be consistent with variable replacement Jan 24, 2018
dkms.8 deleting link to the dell's white-paper (not available anymore) Apr 4, 2018
dkms.bash-completion add autoinstall to the bash completion Aug 11, 2010
dkms.service Add systemd service from RHEL repository Sep 22, 2014
dkms.spec Fix RPM build error for merging #45 from dell/issue-41-fix-version-date Apr 25, 2018
dkms_apport.py Include package version in package data Nov 1, 2016
dkms_autoinstaller Fix syntactic error when the system shell is zsh Oct 7, 2018
dkms_common.postinst fix newest kernel calculation Mar 21, 2018
dkms_dbversion import of v2.0.0 May 17, 2007
dkms_find-provides add support for compressed kernel modules Nov 27, 2017
dkms_framework.conf Allow building for all installed kernels in the common postinst Aug 18, 2014
dkms_mkkerneldoth trailing whitespace removal Aug 31, 2007
dkms_upgrade_add_arch_support.sh Use parameter expansion tricks instead of echoing variables through p… May 14, 2010
kernel_postinst.d_dkms Fix the Linux build/ directory from Robert's patch Jul 12, 2011
kernel_prerm.d_dkms Run remove_initrd_backup after rebuilding the initrd Oct 5, 2017
lsb_release add private copy of lsb_release as a fallback; drop RPM dep on lsb Jul 24, 2009
sample-suse-10-mkkmp.spec import of v2.0.9.2 May 17, 2007
sample-suse-9-mkkmp.spec import of v2.0.9.2 May 17, 2007
sample.conf import of v1.02 May 17, 2007
sample.spec Improve message printed when kernel headers are missing. May 24, 2016
template-dkms-mkdsc add a mkdsc target to dkms Jun 16, 2008
template-dkms-mkrpm.spec Fix prefix in emplate-dkms-mkrpm.spec file Sep 22, 2014
template-dkms-redhat-kmod.spec Remove obsolete Red Hat/Fedora code May 19, 2017


Dynamic Kernel Module System (DKMS)

This intention of this README is to explain how a DKMS enabled module RPM functions and also how DKMS can be used in conjunction with tarballs which contain a dkms.conf file within them.

The DKMS project (and any updates) can be found at: https://github.com/dell/dkms

How To Build RPM & DEB Package

If you want to create rpm or deb package,then you can install the dkms package in your system.

  1. Install all the build dependency packages
  2. Runs: '#make rpm' to create rpm package
  3. Runs: '#make debs' to create deb package
  4. You can find the built package in "dkms/dist/"

Installation of DKMS via RPM

To install DKMS itself, you simply install (or upgrade) it like any other RPM:

rpm -ivh dkms-<version>-<release>.noarch.rpm

This is a prerequisite to installing DKMS-enabled module RPMs.

Installation via RPM

To install a DKMS enabled module RPM, you simply install it like any other RPM:

rpm -ivh <module>-<version>-<rpmversion>.noarch.rpm

With a DKMS enabled module RPM, most of the installation work done by the RPM is actually handed off to DKMS within the RPM. Generally it does the following:

  1. Installs module source into /usr/src/<module>-<moduleversion>/
  2. Places a dkms.conf file into /usr/src/<module>-<moduleversion>/
  3. Runs: # dkms add -m <module> -v <version>
  4. Runs: # dkms build -m <module> -v <version>
  5. Runs: # dkms install -m <module> -v <version>

Once the RPM installation is complete, you can use DKMS to understand which module and which moduleversion is installed on which kernels. This can be accomplished via the command:

# dkms status

From here, you can then use the various DKMS commands (eg. add, build, install, uninstall) to load that module onto other kernels.

Installation via DKMS Tarballs

DKMS is not limited to installation via RPM only. In fact, DKMS can also install directly from the following:

  1. Generic module source tarballs which contain a dkms.conf file
  2. Specially created DKMS tarballs with module source, pre-built module binaries and a dkms.conf file
  3. Specially created DKMS tarballs with pre-built module binaries and a dkms.conf file
  4. Manual placement of module source and dkms.conf file into /usr/src/<module>-<moduleversion>/ directory

In order to load any tarball into the DKMS tree, you must use the following command:

# dkms ldtarball /path/to/dkms_enabled.tar.gz

This command will first inspect the tarball to ensure that it contains a dkms.conf configuration file for that module. If it cannot find this file anywhere within the archive, then the ldtarball will fail.

From here, it will place the source in the tarball into /usr/src/<module>-<moduleversion>/. If source already exists in the directory, it will not overwrite it unless the --force option is specified. If the tarball is of type "c" above and does not contain source, it will only continue to load the tarball if existing module source is found in /usr/src/<module>-<moduleversion>/ or if the --force option is specified.

Continuing on, if the tarball is of type "b" or "c" it will then load any pre-built binaries found within the tarball into the dkms tree, but will stop short of installing them. Thus, all pre-built binaries will then be of in the built state when checked from the dkms status command. You can then use the dkms install command to install any of these binaries.

To create a tarball of type "1" above, you need only to take module source and a dkms.conf file for that module and create a tarball from them. Tarballs of type 2 or type 3 are created with the dkms mktarball command. To create a type 3 tarball, you must specify the flag --binaries-only with the mktarball.

Installation on Systems with no Module Source and/or Compiler

If you choose not to load module source on your system or if you choose not to load a compiler such as gcc onto your system, DKMS can still be used to install modules. It does this through use of DKMS binary only tarballs as explained in this README under tarballs of type c.

If your system does not have module source, loading the dkms tarball will fail because of this. To avoid this, use the --force flag, as such:

# dkms ldtarball /path/to/dkms_enabled.tar.gz --force

This will load the pre-built binaries into the dkms tree, and create the directory /usr/src/<module>-<moduleversion>/ which will only contain the module's dkms.conf configuration file. Once the tarball is loaded, you can then use dkms install to install any of the pre-built modules.

Of course, since module source will not be located in your dkms tree, you will not be able to build any modules with DKMS for this package.

Further Documentation

Once DKMS is installed, you can reference its man page for further information on different DKMS options and also to understand the formatting of a module's dkms.conf configuration file.

You may also wish to join the dkms-devel public mailing-list at http://lists.us.dell.com/.

The DKMS project is located at: https://github.com/dell/dkms