2084 lines
49 KiB
HTML
2084 lines
49 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of DKMS</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>DKMS</H1>
|
|
Section: Maintenance Commands (8)<BR>Updated: RELEASE_DATE<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
dkms - Dynamic Kernel Module Support
|
|
<A NAME="lbAC"> </A>
|
|
<H2>SYNOPSIS</H2>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DL COMPACT>
|
|
<DT id="1">
|
|
<B>dkms</B>
|
|
|
|
|
|
|
|
[<B><DD>action</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>options</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>/path/to/source-tree</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>/path/to/tarball.tar</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>/path/to/driver.rpm</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</DL>
|
|
<A NAME="lbAD"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
<B>dkms</B>
|
|
|
|
is a framework which allows kernel modules to be dynamically built
|
|
for each kernel on your system in a simplified and organized fashion.
|
|
<A NAME="lbAE"> </A>
|
|
<H2>ACTIONS</H2>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DL COMPACT>
|
|
<DT id="2">
|
|
<B>add</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>/path/to/source-tree</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>/path/to/tarball.tar</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="3"><DD>
|
|
Adds a module/module-version combination to the tree for builds and installs.
|
|
If module/module-version, -m module/module-version, or -m module -v version are passed as options, this command
|
|
requires source in
|
|
<I>/usr/src/<module>-<module-version>/</I>
|
|
|
|
as well as a properly
|
|
formatted
|
|
<I>dkms.conf</I>
|
|
|
|
file. If
|
|
<I>/path/to/source-tree</I>
|
|
|
|
is passed as an option, and source-tree contains a
|
|
<I>dkms.conf</I>
|
|
|
|
file, it will copy
|
|
<I>/path/to/source-tree</I>
|
|
|
|
to
|
|
<I>/usr/src/module-module-version.</I>
|
|
|
|
If
|
|
<I>/path/to/tarball.tar</I>
|
|
|
|
is passed, this command behaves like the
|
|
<B>ldtarball</B>
|
|
|
|
command.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="4">
|
|
<B>remove</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--all</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="5"><DD>
|
|
Removes a module/version or module/version/kernel/arch combination from the
|
|
tree. If the module is currently installed, it first uninstalls it
|
|
and if applicable, will replace it with its original_module. Use the
|
|
<B>--all</B>
|
|
|
|
option in order to remove all instances for every kernel at once.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="6">
|
|
<B>build</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="7"><DD>
|
|
Builds the specified module/version combo for the specified kernel/arch. If
|
|
the
|
|
<I>-k</I>
|
|
|
|
option is not specified it builds for the currently running kernel and arch.. All builds
|
|
occur in the directory
|
|
<I>/var/lib/dkms/<module>/<module-version>/build/.</I>
|
|
|
|
If the module/module-version combo has not been added, dkms will try to add it, and in that
|
|
case
|
|
<B>build</B>
|
|
|
|
can take the same arguments that
|
|
<B>add</B>
|
|
|
|
can.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="8">
|
|
<B>install</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>/path/to/driver.rpm</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="9"><DD>
|
|
Installs a built module/version combo onto the kernel it was built for. If
|
|
the kernel option is not specified it assumes the currently running kernel.
|
|
If the module has not been built, dkms will try to build it.
|
|
If the module has not been added, dkms will try to add it. In both cases, the
|
|
<B>install</B>
|
|
|
|
command can then take the same arguments as the
|
|
<B>build</B>
|
|
|
|
or
|
|
<B>add</B>
|
|
|
|
commands.
|
|
If you pass a .rpm file, dkms will try to install that file with
|
|
<B>rpm -Uvh</B>
|
|
|
|
, and it will perform an
|
|
<B>autoinstall</B>
|
|
|
|
action to be sure that everything is built for your kernel if the RPM installed successfully.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="10">
|
|
<B>uninstall</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="11"><DD>
|
|
Uninstalls an installed module/module-version combo from the kernel/arch passed in the -k option, or the
|
|
current kernel if the -k option was not passed.
|
|
upon. After uninstall completion, the driver will be left in the built state.
|
|
To completely remove a driver, the remove action should be utilized.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="12">
|
|
<B>match</B>
|
|
|
|
|
|
|
|
[<B>--templatekernel</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="13"><DD>
|
|
<DD>Match installs modules onto the specified kernel by looking at the
|
|
configuration of the specified
|
|
<B>templatekernel.</B>
|
|
|
|
Every module that is installed on the
|
|
<B>templatekernel</B>
|
|
|
|
within
|
|
<B>dkms</B>
|
|
|
|
is then installed on that specified kernel.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="14">
|
|
<B>mkdriverdisk</B>
|
|
|
|
|
|
|
|
[<B>-d</B><I> distro</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-r</B><I> release</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--media</B><I> mediatype</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B><DD>module/version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="15"><DD>
|
|
Creates a floppy driver disk image for use when updated drivers are needed
|
|
to install an OS. Currently, the supported distributions are redhat, suse
|
|
and UnitedLinux. For Red Hat driver disks, necessary driver disk files are
|
|
looked for in the redhat_driver_disk
|
|
subdirectory of your module source directory. You
|
|
must specify the distro while using this action. Driver disks can be made
|
|
for single kernels or can be made to support multiple kernels. To create
|
|
a driver disk image with modules for multiple kernels, just specify multiple
|
|
-k parameters on the command line (-k kernel1/arch1 -k kernel2/arch2).
|
|
<P>
|
|
Red Hat introduced DDv3 starting with RHEL6. To create Red Hat DDv3, specify
|
|
<B>-d redhat3</B>
|
|
|
|
and specify the specfile to use with
|
|
<I>--spec=specfile.</I>
|
|
|
|
If no specfile is specified, DKMS will use
|
|
<I>/etc/dkms/template-dkms-redhat-kmod.spec</I>
|
|
|
|
<P>
|
|
For suse/UnitedLinux driver disks, /usr/share/YaST2/modules/Vendor.ycp
|
|
will also be copied to the driver disk; no other files are needed.
|
|
However, for these distros, you must specify a -r release. For
|
|
SuSE 9.1, it would be -d suse -r 9.1. For SLES9, it would be -d suse -r sles9.
|
|
<P>
|
|
By default the disk image it creates is 1440 (k) in size. This can be
|
|
overridden by specifying a different
|
|
<B>--size ####</B>
|
|
|
|
which should should be given as a number in kilobytes divisible by 20.
|
|
<P>
|
|
You may have more content than will fit on a floppy. Therefore, DKMS
|
|
can now generate image files of different types.
|
|
<B>--media floppy (default)</B>
|
|
|
|
to generate a floppy disk image, or
|
|
<B>--media iso</B>
|
|
|
|
to generate a CD-ROM ISO file, or
|
|
<B>--media tar</B>
|
|
|
|
to generate a tar file.
|
|
<P>
|
|
You may copy the floppy or ISO image file to a USB key to be used with
|
|
OS installer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="16">
|
|
<B>mktarball</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--archive</B><I> /path/to/tarball.tar</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--source-only</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--binaries-only</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="17"><DD>
|
|
Creates a tarball archive for the specified module/version of all files
|
|
in the DKMS tree for that module/version combination. This includes
|
|
the source and any built modules for kernels in the tree (as specified).
|
|
Otherwise, you can specify
|
|
a singular kernel to archive only, or multiple kernels to archive
|
|
(-k kernel1/arch1 -k kernel2/arch2). Optionally, you can use
|
|
<B>--archive</B>
|
|
|
|
to specify the file that you would like to save this
|
|
tarball to. You can also specify
|
|
<B>--binaries-only</B>
|
|
|
|
if you want the resultant tarball not to include the module source. Likewise,
|
|
<B>--source-only</B>
|
|
|
|
can be used to specify that no prebuilt binaries should be included in the tarball.
|
|
In general,
|
|
<B>mktarball</B>
|
|
|
|
is great for systems management purposes as you can build your driver
|
|
on just one system and then use
|
|
<B>ldtarball</B>
|
|
|
|
on all of your other systems to get the same built modules loaded
|
|
without having to wait for anything to compile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="18">
|
|
<B>ldtarball</B>
|
|
|
|
|
|
|
|
[<B>/path/to/tarball.tar</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--force</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="19"><DD>
|
|
<DD>This takes a tarball made from the
|
|
<B>mktarball</B>
|
|
|
|
command and loads it into your DKMS tree. This will leave any
|
|
newly added modules in the built state and
|
|
<B>dkms install</B>
|
|
|
|
should then be called to install any of them. If files already
|
|
exist where
|
|
<B>ldtarball</B>
|
|
|
|
is attempting to place them, it will warn and not copy over them. The
|
|
<B>--force</B>
|
|
|
|
option should be used to override this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="20">
|
|
<B>mkrpm</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--source-only</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--binaries-only</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="21"><DD>
|
|
This action allows you to create an RPM package for a specified module / version.
|
|
It uses a template .spec file found in
|
|
<I>/etc/dkms/template-dkms-mkrpm.spec</I>
|
|
|
|
as the basis for the RPM. Alternatively, if DKMS finds a file called
|
|
<I>/usr/src/<module>-<module-version>/<module>-dkms-mkrpm.spec</I>
|
|
|
|
it will use that .spec file instead. In general, a DKMS tarball is placed inside
|
|
the contents of this RPM, and the RPM itself calls various DKMS commands to
|
|
load this tarball, build and install modules on the end user's system. If you do
|
|
not want your RPM to contain any prebuilt binaries, be sure to specify
|
|
<B>--source-only</B>
|
|
|
|
in the mkrpm command.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="22">
|
|
<B>mkdeb</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="23"><DD>
|
|
This action allows you to create a debian binary package for a specified module / version.
|
|
It uses a template debian directory found in
|
|
<I>/etc/dkms/template-dkms-mkdeb</I>
|
|
|
|
as the basis for the package. Alternatively, if DKMS finds a file called
|
|
<I>/usr/src/<module>-<module-version>/<module>-dkms-mkdeb</I>
|
|
|
|
it will use that folder instead. In general, a DKMS tarball is placed inside the
|
|
contents of this package, and the package itself calls various DKMS commands to
|
|
load this tarball, build and install modules on the end user's system.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="24">
|
|
<B>mkbmdeb</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="25"><DD>
|
|
Creates a Debian binary package containing just the binary modules in the /lib/modules
|
|
installation path. This package does not depend on dkms and does not require a toolchain
|
|
to be installed on the target host. Useful if you want to have a package to install on
|
|
hosts identical to the build system without installing the full toolchain on them.
|
|
It uses a template debian directory found in
|
|
<I>/etc/dkms/template-dkms-mkbmdeb</I>
|
|
|
|
as the basis for the package.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="26">
|
|
<B>mkdsc</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="27"><DD>
|
|
This action allows you to create a debian source package for a specified module / version.
|
|
It will create a .tar.gz, and a .dsc. All options supported by
|
|
<B>mkdeb</B>
|
|
|
|
are supported by it. The main difference in it's usage is that it will look in
|
|
<I>/etc/dkms/template-dkms-mkdsc</I>
|
|
|
|
as the basis for the package. Alternatively, if DKMS finds a file called
|
|
<I>/usr/src/<module>-<module-version>/<module>-dkms-mkdsc</I>
|
|
|
|
it will use that folder instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="28">
|
|
<B>mkkmp</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>--spec</B><I> specfile</I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="29"><DD>
|
|
This action allows you to create an Kernel Module Package source RPM for a specified module / version.
|
|
It uses the .spec file specified by
|
|
<I>--spec=specfile</I>
|
|
|
|
else
|
|
<I>$module-kmp.spec</I>
|
|
|
|
as the basis for the RPM. The generated source RPM may then be built using SuSE's build.rpm or
|
|
Fedora/RHEL's mock chroot environments. See <A HREF="http://kerneldrivers.org/">http://kerneldrivers.org/</A> for
|
|
more details on KMPs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="30">
|
|
<B>status</B>
|
|
|
|
|
|
|
|
[<B><DD>module/module-version</B><I> </I>]
|
|
|
|
|
|
|
|
|
|
|
|
[<B>-k</B><I> kernel/arch</I>]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="31"><DD>
|
|
Returns the current status of modules, versions and kernels within
|
|
the tree as well as whether they have been added, built or installed.
|
|
Status can be shown for just a certain module, a certain kernel,
|
|
a module/version combination or a module/version/kernel combination.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="32">
|
|
<B>autoinstall</B>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="33"><DD>
|
|
<DD>Attempt to install the latest revision of all modules that have been installed for other kernel revisions.
|
|
dkms_autoinstaller is a stub that uses this action to perform its work.
|
|
</DL>
|
|
<A NAME="lbAF"> </A>
|
|
<H2>OPTIONS</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="34"><B>-m <module>/<module-version></B>
|
|
|
|
<DD>
|
|
The name of the module and module version you want to operate on. The
|
|
<B>-m</B>
|
|
|
|
part of this option is optional, and can be omitted in virtually all circumstances.
|
|
<DT id="35"><B>-v <module-version></B>
|
|
|
|
<DD>
|
|
The version of the module to execute the specified action upon. This option only has to be specified
|
|
if you pass a
|
|
<B>-m</B>
|
|
|
|
option without a <module-version> component of its own.
|
|
<DT id="36"><B>-k <kernel-version>/<arch></B>
|
|
|
|
<DD>
|
|
The kernel and arch to perform the action upon. You can specify multiple kernel version/arch pairs
|
|
on the command line by repeating the -k argument with a different kernel version and arch.
|
|
However, not all actions support multiple kernel versions (it will error out
|
|
in this case).
|
|
The arch part can be omitted, and DKMS will assume you want it to be the arch of the currently running
|
|
system.
|
|
<DT id="37"><B>-a, --arch</B>
|
|
|
|
<DD>
|
|
The system architecture to perform the action upon. It is optional if you pass it as part of the
|
|
<B>-k</B>
|
|
|
|
option. If not specified, it assumes
|
|
the arch of the currently running system (`uname -m`). You can specify multiple
|
|
arch parameters on the same command line by repeating the -a argument with a
|
|
different arch name. When multiple architectures are specified, there must
|
|
be a 1:1 relationship between -k arguments to -a arguments. DKMS will then
|
|
assume the first -a argument aligns with the first -k kernel and so on for the
|
|
second, third, etc.
|
|
<P>
|
|
For example, if you were to specify: -k kernel1 -k kernel2 -a i386 -k kernel3 -a i686 -a x86_64,
|
|
DKMS would process this as: kernel1-i386, kernel2-i686, kernel3-x86_64.
|
|
<DT id="38"><B>-q, --quiet</B>
|
|
|
|
<DD>
|
|
Quiet.
|
|
<DT id="39"><B>-V, --version</B>
|
|
|
|
<DD>
|
|
Prints the currently installed version of dkms and exits.
|
|
<DT id="40"><B>-c <dkms.conf-location></B>
|
|
|
|
<DD>
|
|
The location of the
|
|
<I>dkms.conf</I>
|
|
|
|
file. This is needed for the add action and if not specified,
|
|
it is assumed to be located in
|
|
<I>/usr/src/<module>-<module-version>/.</I>
|
|
|
|
See below for more information on the format of
|
|
<I>dkms.conf.</I>
|
|
|
|
<DT id="41"><B>-d, --distro</B>
|
|
|
|
<DD>
|
|
The distribution being used. This is only currently needed for
|
|
<B>mkdriverdisk.</B>
|
|
|
|
The supported distros are
|
|
<B>redhat,</B>
|
|
|
|
<B>suse</B>
|
|
|
|
and
|
|
<B>UnitedLinux.</B>
|
|
|
|
See the sections on
|
|
<B>mkdriverdisk</B>
|
|
|
|
and
|
|
<B>mkkmp</B>
|
|
|
|
for more information.
|
|
<DT id="42"><B>-r, --release</B>
|
|
|
|
<DD>
|
|
The release being used. This is only currently used for
|
|
<B>mkdriverdisk</B>
|
|
|
|
and is only used for suse or UnitedLinux distros (eg. -r 9.1). It is
|
|
used in the internal makeup of the driverdisk.
|
|
<DT id="43"><B>--size</B>
|
|
|
|
<DD>
|
|
The size of the driver disk image to be created. By default, this value is set
|
|
at 1440. Any different size should be given as an integer value only, should
|
|
be divisible by 20 and should represent the number of kilobytes of the image
|
|
size you desire.
|
|
<DT id="44"><B>--config <kernel-.config-location></B>
|
|
|
|
<DD>
|
|
During a
|
|
<B>build</B>
|
|
|
|
this option is used to specify an alternate location for the kernel .config
|
|
file which was used to compile that kernel. Normally,
|
|
<B>dkms</B>
|
|
|
|
uses the Red Hat standard location and config filenames located in
|
|
<I>/usr/src/linux-<kernel>/configs/.</I>
|
|
|
|
If the config for the kernel that you
|
|
are building a module for is not located here or does not have the expected
|
|
name in this location, you will need to tell
|
|
<B>dkms</B>
|
|
|
|
where the necessary .config can be found so that your kernel can be properly
|
|
prepared for the module build.
|
|
<DT id="45"><B>--archive <tarball-location></B>
|
|
|
|
<DD>
|
|
This option is used during a
|
|
<B>ldtarball</B>
|
|
|
|
action to specify the location of the tarball you wish to load into
|
|
your DKMS tree. You only have to specify the
|
|
<B>--archive</B>
|
|
|
|
part of this option if <tarball-location> does not already exist as a file.
|
|
<DT id="46"><B>--templatekernel <kernel-version></B>
|
|
|
|
<DD>
|
|
This option is required for the action:
|
|
<B>match.</B>
|
|
|
|
Match will look at the
|
|
templatekernel specified and install all of the same module/version
|
|
combinations on the other kernel.
|
|
<DT id="47"><B>--force</B>
|
|
|
|
<DD>
|
|
This option can be used in conjunction with
|
|
<B>ldtarball</B>
|
|
|
|
to force copying over of extant files.
|
|
<DT id="48"><B>--binaries-only</B>
|
|
|
|
<DD>
|
|
This option can be used in conjunction with
|
|
<B>mktarball</B>
|
|
|
|
in order to create a DKMS tarball which does not contain the source for the
|
|
module within it. This can be helpful in reducing the size of the tarball
|
|
if you know that the system which this tarball will be loaded upon already
|
|
has the source installed. In order to load a tarball made as binaries-only
|
|
<B>you must</B>
|
|
|
|
have the module source in that systems DKMS tree. If you do not, DKMS
|
|
<B>will refuse</B>
|
|
|
|
to load a binaries-only tarball.
|
|
<DT id="49"><B>--source-only</B>
|
|
|
|
<DD>
|
|
This option can be used in conjunction with
|
|
<B>mktarball</B>
|
|
|
|
or
|
|
<B>mkrpm</B>
|
|
|
|
or
|
|
<B>mkdeb</B>
|
|
|
|
in order to create a DKMS tarball which does not contain any prebuilt
|
|
kernel module binaries within it. This is helpful if you simply want
|
|
to easily tar up your source but don't want anything prebuilt within
|
|
it. Likewise, if you are using
|
|
<B>mkrpm</B>
|
|
|
|
but do not want the RPM you create to have any prebuilt modules within it,
|
|
passing this option will keep its internal DKMS tarball from containing any
|
|
prebuilt modules.
|
|
<DT id="50"><B>--all</B>
|
|
|
|
<DD>
|
|
This option can be used to automatically specify all relevant kernels/arches
|
|
for a module/module-version. This is useful for things like
|
|
<B>remove</B>
|
|
|
|
,
|
|
<B>mktarball</B>
|
|
|
|
, etc. This saves the trouble of having to actually specify -k kernel1 -a
|
|
arch1 -k kernel2 -a arch2 for every kernel you have built your module for.
|
|
<DT id="51"><B>--no-prepare-kernel</B>
|
|
|
|
<DD>
|
|
This option keeps DKMS from first preparing your kernel before building
|
|
a module for it. Generally, this option should not be used so as to
|
|
ensure that modules are compiled correctly.
|
|
<DT id="52"><B>--no-clean-kernel</B>
|
|
|
|
<DD>
|
|
This option keeps DKMS from cleaning your kernel source tree after a
|
|
build.
|
|
<DT id="53"><B>--no-depmod</B>
|
|
|
|
<DD>
|
|
This option prevents DKMS from running the depmod command during
|
|
<B>install</B>
|
|
|
|
and
|
|
<B>uninstall</B>
|
|
|
|
which will avoid (re)calculating module dependencies and thereby save time.
|
|
<DT id="54"><B>--kernelsourcedir <kernel-source-directory-location></B>
|
|
|
|
<DD>
|
|
Using this option you can specify the location of your kernel source
|
|
directory. Most likely you will not need to set this if your kernel
|
|
source is accessible via
|
|
<I>/lib/modules/$kernel_version/build.</I>
|
|
|
|
<DT id="55"><B>--directive <cli-directive=cli-value></B>
|
|
|
|
<DD>
|
|
Using this option, you can specify additional directives from the command
|
|
line. The
|
|
<B>--directive</B>
|
|
|
|
option can be used multiple times on the same command-line to specify
|
|
multiple additional command line directives.
|
|
<DT id="56"><B>--rpm_safe_upgrade</B>
|
|
|
|
<DD>
|
|
This flag should be used when packaging DKMS enabled modules in RPMs. It should
|
|
be specified during both the
|
|
<B>add</B>
|
|
|
|
and
|
|
<B>remove</B>
|
|
|
|
actions in the RPM spec to ensure that DKMS and RPM behave correctly in all
|
|
scenarios when upgrading between various versions of a dkms enabled module
|
|
RPM package. See the sample.spec file for an example or read more in the section
|
|
below on Creating RPMs Which Utilize DKMS.
|
|
<DT id="57"><B>--spec specfile</B>
|
|
|
|
<DD>
|
|
This option is used by the
|
|
<B>mkkmp</B>
|
|
|
|
action to specify which RPM spec file to use when generating the KMP.
|
|
<I>specfile</I>
|
|
|
|
will be sought in the module source directory.
|
|
<DT id="58"><B>--dkmstree path/to/place</B>
|
|
|
|
<DD>
|
|
Provides a destination tree for building and installing modules to. Useful in
|
|
cases that you don't want to contaminate a system when using solely for building.
|
|
<DT id="59"><B>--sourcetree path/to/place</B>
|
|
|
|
<DD>
|
|
Provides a location to build a DKMS package from. Useful for systems that you may
|
|
not have root access, but would still like to be able to build DKMS packages.
|
|
<DT id="60"><B>--installtree path/to/place</B>
|
|
|
|
<DD>
|
|
Provides a location to place modules when a
|
|
<I>dkms install</I>
|
|
|
|
command is issued.
|
|
<DT id="61"><B>--legacy-postinst=[0|1]</B>
|
|
|
|
<DD>
|
|
Includes a legacy postinstall script so that a DEB or RPM built by DKMS can be used on versions
|
|
prior than DKMS 2.1. This option currently defaults to 1.
|
|
<DT id="62"><B>--dkmsframework path/to/file</B>
|
|
|
|
<DD>
|
|
A supplemental configuration file to the system-wide dkms framework, typically located
|
|
in /etc/dkms/framework.conf. All option that are normally provided on a command line
|
|
can be provided in this file.
|
|
<DT id="63"><B>-j number</B>
|
|
|
|
<DD>
|
|
Run no more than
|
|
<I>number</I>
|
|
|
|
jobs in parallel; see the -j option of
|
|
<I><A HREF="/cgi-bin/man/man2html?1+make">make</A>(1).</I>
|
|
|
|
Defaults to the number of CPUs in the system, detected by
|
|
<I><A HREF="/cgi-bin/man/man2html?1+nproc">nproc</A>(1).</I>
|
|
|
|
Specify 0 to impose no limit on the number of parallel jobs.
|
|
</DL>
|
|
<A NAME="lbAG"> </A>
|
|
<H2>ORIGINAL MODULES</H2>
|
|
|
|
During the first install of a module for a <kernelversion>,
|
|
<B>dkms</B>
|
|
|
|
will search
|
|
<I>/lib/modules/<kernelversion></I>
|
|
|
|
for a pre-existing module of the same name. If one is found, it will automatically
|
|
be saved as an "original_module" so that if the newer module is later removed,
|
|
<B>dkms</B>
|
|
|
|
will put the original module back in its place. Currently, DKMS searches
|
|
for these original modules with first preference going to modules located in
|
|
<I>/lib/modules/<kernelversion>/updates/</I>
|
|
|
|
followed by
|
|
<B>$DEST_MODULE_LOCATION</B>
|
|
|
|
(as specified in
|
|
<I>dkms.conf</I>
|
|
|
|
). If one cannot be found in either location, a find will be used to locate one for
|
|
that kernel.
|
|
If none are found, then during a later uninstall, your kernel will not have that module
|
|
replaced.
|
|
<P>
|
|
If more than one is found, then the first one located (by preference indicated
|
|
above) will be considered the "original_module". As well, all copies of the same-named
|
|
module will be removed from your kernel tree and placed into
|
|
<I>/var/lib/dkms/<module>/original_module/$kernelver/collisions</I>
|
|
|
|
so that they can be *manually* accessible later. DKMS will never actually do anything
|
|
with the modules found underneath the /collisions directory, and they will be stored there
|
|
until you manually delete them.
|
|
<A NAME="lbAH"> </A>
|
|
<H2>DKMS.CONF</H2>
|
|
|
|
When performing an
|
|
<B>add</B>
|
|
|
|
, a proper
|
|
<I>dkms.conf</I>
|
|
|
|
file must be found. A properly formatted conf file is essential
|
|
for communicating to
|
|
<B>dkms</B>
|
|
|
|
how and where the module should be installed. While not all the directives
|
|
are required, providing as many as possible helps to limit any ambiguity. Note
|
|
that the
|
|
<I>dkms.conf</I>
|
|
|
|
is really only a shell-script of variable definitions which are then sourced in
|
|
by the
|
|
<B>dkms</B>
|
|
|
|
executable (of the format, DIRECTIVE="directive text goes here"). As well, the
|
|
directives are case-sensitive and should be given in
|
|
<B>ALL CAPS.</B>
|
|
|
|
<P>
|
|
It is important to understand that many of the DKMS directives are arrays whose index
|
|
values are tied together. These array associations can be considered families, and there
|
|
are currently four such families of directive arrays. MAKE[#] and MAKE_MATCH[#] make up
|
|
one family. PATCH[#] and PATCH_MATCH[#] make up the second family. The third and
|
|
largest family consists of BUILT_MODULE_NAME[#], BUILT_MODULE_LOCATION[#], DEST_MODULE_NAME[#],
|
|
DEST_MODULE_LOCATION[#], MODULES_CONF_ALIAS_TYPE[#], MODULES_CONF_OBSOLETES[#],
|
|
MODULES_CONF_OBSOLETE_ONLY[#] and STRIP[#]. The fourth
|
|
family is made up of only MODULES_CONF[#]. When indexing these arrays when creating your
|
|
dkms.conf, each family should start at index value 0.
|
|
<DL COMPACT>
|
|
<DT id="64"><B>MAKE[#]=</B>
|
|
|
|
<DD>
|
|
The MAKE directive array tells DKMS which make command should be used for building your module. The default make command
|
|
should be put into
|
|
<B>MAKE[0].</B>
|
|
|
|
Other entries in the MAKE array will only be used if their corresponding entry in
|
|
<B>MAKE_MATCH[#]</B>
|
|
|
|
matches, as a regular expression (using egrep), the kernel that the module is being built for.
|
|
Note that if no value is placed in
|
|
<B>MAKE_MATCH[#]</B>
|
|
|
|
for any
|
|
<B>MAKE[#]</B>
|
|
|
|
where # > 0, then that
|
|
<B>MAKE</B>
|
|
|
|
directive is ignored.
|
|
<B>MAKE_MATCH[0]</B>
|
|
|
|
is optional and if it is populated, it will be used to determine
|
|
if MAKE[0] should be used to build the module for that kernel. If multiple
|
|
<B>MAKE_MATCH</B>
|
|
|
|
directives match against the kernel being built for, the last matching
|
|
<B>MAKE[#]</B>
|
|
|
|
will be used to build your module. If no MAKE directive is specified or if no
|
|
MAKE_MATCH matches the kernel being built for, DKMS
|
|
will attempt to use a generic MAKE command to build your module.
|
|
<P>
|
|
KERNELRELEASE will be automatically appended to MAKE[#]. If you want to
|
|
suppress this behavior, you can quote the make command: 'make'.
|
|
<DT id="65"><B>MAKE_MATCH[#]=</B>
|
|
|
|
<DD>
|
|
See the above entry on
|
|
<B>MAKE[#]</B>
|
|
|
|
directives. This array should be populated with regular expressions which, when matched
|
|
against the kernel being built for, will tell
|
|
<B>DKMS</B>
|
|
|
|
to use the corresponding make command in the
|
|
<B>MAKE[#]</B>
|
|
|
|
directive array to build your module.
|
|
<DT id="66"><B>BUILT_MODULE_NAME[#]=</B>
|
|
|
|
<DD>
|
|
This directive gives the name of the module just after it is built. If your DKMS module
|
|
package contains more than one module to install, this is a
|
|
<B>required</B>
|
|
|
|
directive for all of the modules. This directive should explicitly not contain any
|
|
trailing ".o" or ".ko".
|
|
Note that for each module within a dkms package, the numeric value of
|
|
<B>#</B>
|
|
|
|
must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and
|
|
DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. BUILT_MODULE_NAME[0]="qla2200"
|
|
BUILT_MODULE_NAME[1]="qla2300").
|
|
<DT id="67"><B>BUILT_MODULE_LOCATION[#]=</B>
|
|
|
|
<DD>
|
|
This directive tells DKMS where to find your built module after it has been built. This
|
|
pathname should be given relative to the root directory of your source files (where your
|
|
dkms.conf file can be found). If unset, DKMS expects to find your
|
|
<B>BUILT_MODULE_NAME[#]</B>
|
|
|
|
in the root directory of your source files.
|
|
Note that for each module within a dkms package, the numeric value of
|
|
<B>#</B>
|
|
|
|
must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and
|
|
DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. BUILT_MODULE_LOCATION[0]="some/dir/"
|
|
BUILT_MODULE_LOCATION[1]="other/dir/").
|
|
<DT id="68"><B>DEST_MODULE_NAME[#]=</B>
|
|
|
|
<DD>
|
|
This directive can be used to specify the name of the module as it should be installed. This
|
|
will rename the module from
|
|
<B>BUILT_MODULE_NAME[#]</B>
|
|
|
|
to
|
|
<B>DEST_MODULE_NAME[#].</B>
|
|
|
|
This directive should explicitly not contain any trailing ".o" or ".ko". If unset, it is
|
|
assumed to be the same value as
|
|
<B>BUILT_MODULE_NAME[#].</B>
|
|
|
|
Note that for each module within a dkms package, the numeric value of
|
|
<B>#</B>
|
|
|
|
must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and
|
|
DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. DEST_MODULE_NAME[0]="qla2200_6x"
|
|
DEST_MODULE_NAME[1]="qla2300_6x").
|
|
<DT id="69"><B>DEST_MODULE_LOCATION[#]=</B>
|
|
|
|
<DD>
|
|
This directive specifies the destination where a module should be installed to, once compiled. It also
|
|
is used for finding original_modules. This is a
|
|
<B>required</B>
|
|
|
|
directive, except as noted below. This directive must start with the text "/kernel" which is in reference to
|
|
/lib/modules/<kernelversion>/kernel.
|
|
Note that for each module within a dkms package, the numeric value of
|
|
<B>#</B>
|
|
|
|
must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and
|
|
DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. DEST_MODULE_LOCATION[0]="/kernel/drivers/something/"
|
|
DEST_MODULE_LOCATION[1]="/kernel/drivers/other/").
|
|
<P>
|
|
DEST_MODULE_LOCATION is ignored on Fedora and Red Hat Enterprise Linux, Novell SuSE Linux Enterprise Server 10
|
|
and higher, Novell SuSE Linux 10.0 and higher, and Ubuntu. Instead, the proper distribution-specific directory is used.
|
|
<DT id="70"><B>MODULES_CONF_ALIAS_TYPE[#]=</B>
|
|
|
|
<DD>
|
|
This directive array specifies how your modules should be aliased in
|
|
<I>/etc/modules.conf</I>
|
|
|
|
when your module is installed. This is done in an intelligent fashion so if DKMS
|
|
detects an already existing reference in modules.conf, it won't add a new line. If
|
|
it is not detected, it will add it to the modules.conf as the last alias number for
|
|
that alias type (eg. if MODULES_CONF_ALIAS_TYPE="scsi_hostadapter", no alias
|
|
currently exists for that module and the last scsi_hostadapter reference is 6, then
|
|
your module will be added as "scsi_hostadapter7"). Common values for this directive
|
|
include:
|
|
<B>scsi_hostadapter</B>
|
|
|
|
,
|
|
<B>sound-slot-</B>
|
|
|
|
and
|
|
<B>eth.</B>
|
|
|
|
Note that the numeric value of
|
|
<B>#</B>
|
|
|
|
is tied to the index of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME
|
|
and DEST_MODULE_LOCATION. The index is also tied to MODULES_CONF_OBSOLETES.
|
|
<DT id="71"><B>MODULES_CONF_OBSOLETES[#]=</B>
|
|
|
|
<DD>
|
|
This directive array tells DKMS what modules.conf alias references are obsoleted by the
|
|
module you are installing. If your module obsoletes more than one module, this directive
|
|
should be a comma-delimited list of those modules that are obsoleted (eg. for megaraid2,
|
|
MODULES_CONF_OBSOLETES[0]="megaraid,megaraid_2002"). When you are installing your module,
|
|
DKMS ensures that any entries in
|
|
<I>/etc/modules.conf</I>
|
|
|
|
with the same
|
|
<B>MODULES_CONF_ALIAS_TYPE</B>
|
|
|
|
are changed over to the new module name. When you are uninstalling
|
|
your module, depending on the modules in your
|
|
<I>/lib/modules</I>
|
|
|
|
tree, DKMS will take different actions.
|
|
If you kernel has an original_module, then modules.conf will not be touched and the non-obsolete
|
|
reference will remain. If the kernel does not have an original_module but does have one
|
|
of the obsolete modules, it will replace those references with the first obsolete module name in
|
|
the comma-delimited list that is also in that kernel (thus, your obsolete list should be prioritized
|
|
from left to right). If no original_module or obsolete modules are found within the kernel, the alias
|
|
entry is removed all-together. Note that the numeric value of
|
|
<B>#</B>
|
|
|
|
is tied to the index of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME
|
|
and DEST_MODULE_LOCATION. The index is also tied to MODULES_CONF_ALIAS_TYPE.
|
|
<DT id="72"><B>MODULES_CONF_OBSOLETE_ONLY[#]=</B>
|
|
|
|
<DD>
|
|
If set to
|
|
<B>yes</B>
|
|
|
|
, this directive will tell DKMS to only modify
|
|
<I>/etc/modules.conf</I>
|
|
|
|
if it finds within it an obsolete reference as specified in the corresponding value of
|
|
<B>MODULES_CONF_OBSOLETES[#]</B>
|
|
|
|
array directive.
|
|
<DT id="73"><B>STRIP[#]=</B>
|
|
|
|
<DD>
|
|
By default strip is considered to be "yes". If set to "no", DKMS will not
|
|
run strip -g against your built module to remove debug symbols from it.
|
|
STRIP[0] is used as the default for any unset entries in the STRIP array.
|
|
<DT id="74"><B>PACKAGE_NAME=</B>
|
|
|
|
<DD>
|
|
This directive is used to give the name associated with the entire package of modules. This is the same
|
|
name that is used with the
|
|
<B>-m</B>
|
|
|
|
option when building, adding, etc. and may not necessarily be the same as the MODULE_NAME. This
|
|
directive must be present in every dkms.conf.
|
|
<DT id="75"><B>PACKAGE_VERSION=</B>
|
|
|
|
<DD>
|
|
This directive is used to give the version associated with the entire package of modules being installed within that dkms
|
|
package. This directive must be present in every dkms.conf.
|
|
<DT id="76"><B>CLEAN=</B>
|
|
|
|
<DD>
|
|
CLEAN specifies the make clean command to be used to clean up both before and after building the
|
|
module. If unset, it is assumed to be "make clean".
|
|
<DT id="77"><B>REMAKE_INITRD=</B>
|
|
|
|
<DD>
|
|
This directive specifies whether your initrd should be remade after the module is installed
|
|
onto the kernel. Any text after the first character is ignored and if the first character
|
|
is not a "y" or a "Y", it is assumed that REMAKE_INITRD="no".
|
|
<DT id="78"><B>MODULES_CONF[#]=</B>
|
|
|
|
<DD>
|
|
This directive array specifies what static configuration text
|
|
lines need to be added into
|
|
<I>/etc/modules.conf</I>
|
|
|
|
for your module. See the section on MODULES.CONF CHANGES for more information regarding the
|
|
implications of modifying
|
|
<I>/etc/modules.conf</I>
|
|
|
|
<DT id="79"><B>OBSOLETE_BY=</B>
|
|
|
|
<DD>
|
|
This directive allows you to specify a kernel version that obsoletes the necessity for this
|
|
particular DKMS module. This can be specified as a particular upstream kernel or an ABI
|
|
bump of a kernel. For example, "2.6.24" would be an upstream kernel and "2.6.24-16" would
|
|
represent an ABI bump for a kernel. Both are valid in this area.
|
|
<P>
|
|
Please avoid the use of
|
|
<B>OBSOLETE_BY</B>
|
|
|
|
wherever possible. It's use indicates a lack of proper module
|
|
versioning using
|
|
<B>MODULE_VERSION()</B>
|
|
|
|
tags in the module source itself. It is better to fix the
|
|
<B>MODULE_VERSION()</B>
|
|
|
|
tags than use
|
|
<B>OBSOLETE_BY.</B>
|
|
|
|
This also introduces a implicit distribution/version dependency on the
|
|
package, as the value of
|
|
<B>OBSOLETE_BY</B>
|
|
|
|
is meaningful only in the context of a single distribution/version.
|
|
<P>
|
|
If you feel you must use it, please use as such in dkms.conf:
|
|
<P>
|
|
<BR> ubuntu_804="Ubuntu
|
|
<BR> 8.04"
|
|
<BR> if [ -x /usr/bin/lsb_release ]; then
|
|
<BR> if [ "$(/usr/bin/lsb_release -sir)" == "${ubuntu_804}" ]; then
|
|
<BR> OBSOLETE_BY="2.6.25"
|
|
<BR> fi
|
|
<BR> fi
|
|
<P>
|
|
<DT id="80"><B>PATCH[#]=</B>
|
|
|
|
<DD>
|
|
Use the PATCH directive array to specify patches which should be applied to your source before a build occurs.
|
|
All patches are expected to be in -p1 format and are applied with the patch -p1 command.
|
|
Each directive should specify the filename of the patch to apply, and all patches must
|
|
be located in the patches subdirectory of your source directory (
|
|
<I>/usr/src/<module>-<module-version>/patches/</I>
|
|
|
|
). If any patch fails to apply, the build will be halted and the rejections can be
|
|
inspected in
|
|
<I>/var/lib/dkms/<module>/<module-version>/build/.</I>
|
|
|
|
If a PATCH should only be applied conditionally, the
|
|
<B>PATCH_MATCH[#]</B>
|
|
|
|
array should be used, and a corresponding regular expression should be placed in
|
|
<B>PATCH_MATCH[#]</B>
|
|
|
|
which will alert dkms to only use that
|
|
<B>PATCH[#]</B>
|
|
|
|
if the regular expression matches the kernel which the module is currently being built for.
|
|
<DT id="81"><B>PATCH_MATCH[#]=</B>
|
|
|
|
<DD>
|
|
See the above description for
|
|
<B>PATCH[#]</B>
|
|
|
|
directives. If you only want a patch applied in certain scenarios, the
|
|
<B>PATCH_MATCH</B>
|
|
|
|
array should be utilized by giving a regular expression which matches
|
|
the kernels you intend the corresponding
|
|
<B>PATCH[#]</B>
|
|
|
|
to be applied to before building that module.
|
|
<DT id="82"><B>AUTOINSTALL=</B>
|
|
|
|
<DD>
|
|
If this directive is set to
|
|
<B>yes</B>
|
|
|
|
then the service
|
|
<I>/etc/rc.d/init.d/dkms_autoinstaller</I>
|
|
|
|
will automatically try to install this module on any kernel you boot into. See the section
|
|
on
|
|
<B>dkms_autoinstaller</B>
|
|
|
|
for more information.
|
|
<DT id="83"><B>BUILD_DEPENDS[#]=</B>
|
|
|
|
<DD>
|
|
This optional directive is an array that allows you to specify other modules as
|
|
dependencies for your module. Each array element should be the
|
|
<B>PACKAGE_NAME</B>
|
|
|
|
of another module that is managed by dkms. Do not specify a version or
|
|
architecture in the dependency. Note that this directive is only advisory;
|
|
missing or broken dependencies cause non-fatal warnings.
|
|
<DT id="84"><B>BUILD_EXCLUSIVE_KERNEL=</B>
|
|
|
|
<DD>
|
|
This optional directive allows you to specify a regular expression which defines
|
|
the subset of kernels which DKMS is allowed to build your module for. If the kernel
|
|
being built for does not match against this regular expression, the dkms build
|
|
will error out. For example, if you set it as ="^2.4.*", your module would not be
|
|
built for 2.6 kernels.
|
|
<DT id="85"><B>BUILD_EXCLUSIVE_ARCH=</B>
|
|
|
|
<DD>
|
|
This optional directive functions very similarly to
|
|
<B>BUILD_EXCLUSIVE_KERNEL</B>
|
|
|
|
except that it matches against the kernel architecture. For example, if you set
|
|
it to ="i.86", your module would not be built for ia32e, x86_64, amd64, s390, etc.
|
|
<DT id="86"><B>POST_ADD=</B>
|
|
|
|
<DD>
|
|
The name of the script to be run after an
|
|
<B>add</B>
|
|
|
|
is performed. The path should be given relative to the root directory of your source.
|
|
<DT id="87"><B>POST_BUILD=</B>
|
|
|
|
<DD>
|
|
The name of the script to be run after a
|
|
<B>build</B>
|
|
|
|
is performed. The path should be given relative to the root directory of your source.
|
|
<DT id="88"><B>POST_INSTALL=</B>
|
|
|
|
<DD>
|
|
The name of the script to be run after an
|
|
<B>install</B>
|
|
|
|
is performed. The path should be given relative to the root directory of your source.
|
|
<DT id="89"><B>POST_REMOVE=</B>
|
|
|
|
<DD>
|
|
The name of the script to be run after a
|
|
<B>remove</B>
|
|
|
|
is performed. The path should be given relative to the root directory of your source.
|
|
<DT id="90"><B>PRE_BUILD=</B>
|
|
|
|
<DD>
|
|
The name of the script to be run before a
|
|
<B>build</B>
|
|
|
|
is performed. The path should be given relative to the root directory of your source.
|
|
<DT id="91"><B>PRE_INSTALL=</B>
|
|
|
|
<DD>
|
|
The name of the script to be run before an
|
|
<B>install</B>
|
|
|
|
is performed. The path should be given relative to the root directory
|
|
of your source. If the script exits with a non-zero value, the
|
|
install will be aborted. This is typically used to perform a custom
|
|
version comparison.
|
|
<DT id="92"><B>SIGN_TOOL=</B>
|
|
|
|
<DD>
|
|
The module signing tool to be run at a
|
|
<B>build.</B>
|
|
|
|
Two arguments will be passed to the signing tool. The first argument is the
|
|
target kernel version, the second is the module file path. If the tool exits
|
|
with a non-zero value, the build will be aborted.
|
|
<DT id="93"></DL>
|
|
<A NAME="lbAI"> </A>
|
|
<H2>DKMS.CONF VARIABLES</H2>
|
|
|
|
<DD>
|
|
Within your
|
|
<I>dkms.conf</I>
|
|
|
|
file, you can use certain variables which will be replaced at run-time with their
|
|
values.
|
|
<DL COMPACT>
|
|
<DT id="94"><B>$kernelver</B>
|
|
|
|
<DD>
|
|
This variable can be used within a directive definition and during use, the actual kernel
|
|
version in question will be substituted in its place. This is especially useful in MAKE
|
|
commands when specifying which INCLUDE statements should be used when compiling your
|
|
module (eg. MAKE="make all INCLUDEDIR=/lib/modules/${kernelver}/build/include").
|
|
<DT id="95"><B>$dkms_tree</B>
|
|
|
|
<DD>
|
|
See the section on /etc/dkms/framework.conf for more information. This variable represents
|
|
the location of the DKMS tree on the local system. By default this is
|
|
<I>/var/lib/dkms</I>
|
|
|
|
, but this value should not be hard-coded into a dkms.conf in the event that the local user
|
|
has changed it on their system.
|
|
<DT id="96"><B>$source_tree</B>
|
|
|
|
<DD>
|
|
See the section on /etc/dkms/framework.conf for more information. This variable represents
|
|
the location where DKMS keeps source on the local system. By default this is
|
|
<I>/usr/src</I>
|
|
|
|
, but this value should not be hard-coded into a dkms.conf in the event that the local user
|
|
has changed it on their system.
|
|
<DT id="97"><B>$kernel_source_dir</B>
|
|
|
|
<DD>
|
|
This variable holds the value of the location of your kernel source directory. Usually, this
|
|
will be
|
|
<I>/lib/modules/$kernelver/build</I>
|
|
|
|
, unless otherwise specified with the
|
|
<B>--kernelsourcedir</B>
|
|
|
|
option.
|
|
</DL>
|
|
<A NAME="lbAJ"> </A>
|
|
<H2>DKMS.CONF OVERRIDES</H2>
|
|
|
|
You can override the module-provided
|
|
<I>dkms.conf</I>
|
|
|
|
files. Every time after a dkms.conf file is read, dkms will look for and read the following files in order:
|
|
<P>
|
|
|
|
<I>/etc/dkms/<module>.conf</I>
|
|
|
|
<BR>
|
|
|
|
<I>/etc/dkms/<module>-<module-version>.conf</I>
|
|
|
|
<BR>
|
|
|
|
<I>/etc/dkms/<module>-<module-version>-<kernel>.conf</I>
|
|
|
|
<BR>
|
|
|
|
<I>/etc/dkms/<module>-<module-version>-<kernel>-<arch>.conf</I>
|
|
|
|
<P>
|
|
|
|
You can use these files to override settings in the module-provided dkms.conf files.
|
|
<A NAME="lbAK"> </A>
|
|
<H2>/etc/dkms/framework.conf</H2>
|
|
|
|
This configuration file controls how the overall DKMS framework handles. It is sourced
|
|
in every time the dkms command is run. Mainly it can currently be used to set different
|
|
default values for the variables.
|
|
<B>$dkms_tree</B>
|
|
|
|
,
|
|
<B>$source_tree</B>
|
|
|
|
and
|
|
<B>$install_tree</B>
|
|
|
|
which control where DKMS looks for its framework. The
|
|
<B>$symlink_modules</B>
|
|
|
|
variable controls whether binary modules are copied to /lib/modules or if only symlinks are
|
|
created there. Note that these variables can also
|
|
be manipulated on the command line with --dkmstree, --sourcetree, --installtree
|
|
and --symlink-modules options.
|
|
<P>
|
|
The
|
|
<B>$autoinstall_all_kernels</B>
|
|
|
|
variable is used by the common postinst for DKMS modules. It controls if the build should be done
|
|
for all installed kernels or only for the current and latest installed kernel. It has no command
|
|
line equivalent.
|
|
<A NAME="lbAL"> </A>
|
|
<H2>dkms_autoinstaller</H2>
|
|
|
|
This boot-time service automatically installs any module which has
|
|
<B>AUTOINSTALL=yes</B>
|
|
|
|
set in its
|
|
<B>dkms.conf</B>
|
|
|
|
file. The service works quite simply and if multiple versions of a module are in
|
|
your system's DKMS tree, it will not do anything and instead explain that manual
|
|
intervention is required.
|
|
<A NAME="lbAM"> </A>
|
|
<H2>MODULES.CONF / MODPROBE.CONF CHANGES</H2>
|
|
|
|
Changes that your module will make to
|
|
<I>/etc/modules.conf</I>
|
|
|
|
or
|
|
<I>/etc/modprobe.conf</I>
|
|
|
|
should be specified with the
|
|
<B>MODULES_CONF_ALIAS_TYPE[#]</B>
|
|
|
|
, the
|
|
<B>MODULES_CONF_OBSOLETES[#]</B>
|
|
|
|
and the
|
|
<B>MODULES_CONF[#]</B>
|
|
|
|
directive arrays. These arrays should also be used even if your distro uses
|
|
<I>/etc/sysconfig/kernel</I>
|
|
|
|
to track kernel modules.
|
|
<P>
|
|
When the first module is installed upon the first kernel within the user's system,
|
|
these entries in
|
|
<B>MODULES_CONF[#]</B>
|
|
|
|
are automatically added to
|
|
<I>/etc/modules.conf</I>
|
|
|
|
and if
|
|
<B>REMAKE_INITRD</B>
|
|
|
|
is specified, then the user's initrd is then remade. Subsequently, as your modules are then
|
|
later removed from the user's system, until the final module/version combination is removed
|
|
from the final kernel version, those references in
|
|
<I>modules.conf</I>
|
|
|
|
will remain. Once the last module/version combination is removed, those references are then
|
|
removed.
|
|
<P>
|
|
As modules/versions are removed and initrds are remade, one of three things will happen if you
|
|
have specified a
|
|
<B>MODULES_CONF_ALIAS_TYPE.</B>
|
|
|
|
If no original_module exists for that kernel, and no
|
|
<B>MODULES_CONF_OBSOLETES</B>
|
|
|
|
modules are found in that kernel too, the
|
|
<I>modules.conf</I>
|
|
|
|
alias references will temporarily be removed so that the initrd will successfully
|
|
remake. Once the initrd is remade, however; those references are then automatically put
|
|
back into
|
|
<I>modules.conf</I>
|
|
|
|
(unless you are removing the last instance of the module on the last kernel).
|
|
However, if no original_module exists, but there is an OBSOLETE module
|
|
found within that kernel, the alias reference is temporarily shifted to point to the
|
|
OBSOLETE module so that the initrd can be remade. After it is remade, it then automatically
|
|
puts back the alias reference (unless you are removing the last instance of the module
|
|
on the last kernel). Lastly, if an original_module does exist for the kernel
|
|
version, then
|
|
<I>modules.conf</I>
|
|
|
|
is not touched and all references persist (even if you are removing the last instance of the
|
|
module on the last kernel).
|
|
<P>
|
|
Certain module installations might not only require adding references to
|
|
<I>modules.conf</I>
|
|
|
|
but also require removing conflicting references that might exist in the user's system. If this
|
|
is the case, the
|
|
<B>MODULES_CONF_OBSOLETES[#]</B>
|
|
|
|
directive should be utilized to remove these references. More information about this directive
|
|
can be found in the
|
|
<B>DKMS.CONF</B>
|
|
|
|
section of this man page.
|
|
<P>
|
|
Note that the end state of your modules.conf file very much depends on what kernel modules exist
|
|
in the final kernel you remove your DKMS module from. This is an imperfect system caused by the
|
|
fact that there is only one modules.conf file for every kernel on your system even though various
|
|
kernels use different modules. In a perfect world, there would be one modules.conf file for
|
|
every kernel (just like System.map).
|
|
<A NAME="lbAN"> </A>
|
|
<H2>CREATING RPMS WHICH UTILIZE DKMS</H2>
|
|
|
|
See the
|
|
<I>sample.spec</I>
|
|
|
|
file packaged with
|
|
<B>DKMS</B>
|
|
|
|
as an example for what your RPM spec file might look like.
|
|
Creating RPMs which utilize
|
|
<B>dkms</B>
|
|
|
|
is a fairly straight-forward process. The RPM need only to install the source into
|
|
<I>/usr/src/<module>-<module-version>/</I>
|
|
|
|
and then employ
|
|
<B>dkms</B>
|
|
|
|
itself to do all the work of installation. As such, the RPM should first untar the source into
|
|
this directory. From here, within the RPM
|
|
<I>.spec</I>
|
|
|
|
file, a
|
|
<B>dkms add</B>
|
|
|
|
should be called (remember to use the --rpm_safe_upgrade flag during the add) followed by a
|
|
<B>dkms build</B>
|
|
|
|
followed by a
|
|
<B>dkms install.</B>
|
|
|
|
Your
|
|
<I>dkms.conf</I>
|
|
|
|
file should be placed within the
|
|
<I>/usr/src/<module>-<module-version>/</I>
|
|
|
|
directory.
|
|
<P>
|
|
Under the removal parts of the
|
|
<I>.spec</I>
|
|
|
|
file, all that needs to be called is a: dkms remove -m <module> -v <module-version> --all --rpm_safe_upgrade.
|
|
Use of the
|
|
<B>--rpm_safe_upgrade</B>
|
|
|
|
flag is imperative for making sure DKMS and RPM play nicely together in all scenarios of using
|
|
the -Uvh flag with RPM to upgrade dkms enabled packages. It will only function if used during
|
|
both the add
|
|
<B>and</B>
|
|
|
|
remove actions within the same RPM spec file. Its use makes sure that when upgrading between different
|
|
releases of an RPM for the same <module-version>, DKMS does not do anything dumb (eg. it ensures
|
|
a smooth upgrade from megaraid-2.09-5.noarch.rpm to megaraid-2.09-6.noarch.rpm).
|
|
<P>
|
|
It should be noted that a binary RPM which contains source is not a traditional practice.
|
|
However, given the benefits of
|
|
<B>dkms</B>
|
|
|
|
it hopefully will become so. As the RPM created which utilizes
|
|
<B>dkms</B>
|
|
|
|
is not architecture specific,
|
|
<B>BuildArch: noarch</B>
|
|
|
|
should be specified in the
|
|
<I>.spec</I>
|
|
|
|
file to indicate that the package can work regardless of the system architecture. Also
|
|
note that DKMS RPM upgrades (-U option) will automatically work because of the structure
|
|
of the
|
|
<B>dkms</B>
|
|
|
|
tree.
|
|
<P>
|
|
Lastly, as a matter of convention, you should name your RPM:
|
|
<package>-<version>-<rpm-version>dkms.noarch.rpm. The word
|
|
<B>dkms</B>
|
|
|
|
as part of the rpm-version signifies that the RPM
|
|
works within the DKMS framework.
|
|
<A NAME="lbAO"> </A>
|
|
<H2>AUTHOR</H2>
|
|
|
|
Gary Lerhaupt
|
|
<A NAME="lbAP"> </A>
|
|
<H2>WEBPAGE</H2>
|
|
|
|
<I><A HREF="https://github.com/dell/dkms">https://github.com/dell/dkms</A></I>
|
|
|
|
<A NAME="lbAQ"> </A>
|
|
<H2>WHITE-PAPERS</H2>
|
|
|
|
<I><A HREF="http://www.dell.com/downloads/global/power/1q04-ler.pdf">http://www.dell.com/downloads/global/power/1q04-ler.pdf</A></I>
|
|
|
|
<P>
|
|
<I><A HREF="http://www.linuxjournal.com/article.php?sid=6896">http://www.linuxjournal.com/article.php?sid=6896</A></I>
|
|
|
|
<A NAME="lbAR"> </A>
|
|
<H2>MAILING-LIST</H2>
|
|
|
|
<A HREF="mailto:dkms-devel@dell.com">dkms-devel@dell.com</A>
|
|
<I><A HREF="http://lists.us.dell.com/mailman/listinfo/dkms-devel">http://lists.us.dell.com/mailman/listinfo/dkms-devel</A></I>
|
|
|
|
<A NAME="lbAS"> </A>
|
|
<H2>REFERENCES</H2>
|
|
|
|
Kernel Module Packages
|
|
<I><A HREF="http://kerneldrivers.org">http://kerneldrivers.org</A></I>
|
|
|
|
<P>
|
|
Novell Kernel Module Packages
|
|
<I><A HREF="http://www.suse.de/~agruen/KMPM">http://www.suse.de/~agruen/KMPM</A></I>
|
|
|
|
<P>
|
|
Fedora Kernel Module Packages
|
|
<I><A HREF="http://fedoraproject.org/wiki/Extras/KernelModuleProposal">http://fedoraproject.org/wiki/Extras/KernelModuleProposal</A></I>
|
|
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="98"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="99"><A HREF="#lbAC">SYNOPSIS</A><DD>
|
|
<DT id="100"><A HREF="#lbAD">DESCRIPTION</A><DD>
|
|
<DT id="101"><A HREF="#lbAE">ACTIONS</A><DD>
|
|
<DT id="102"><A HREF="#lbAF">OPTIONS</A><DD>
|
|
<DT id="103"><A HREF="#lbAG">ORIGINAL MODULES</A><DD>
|
|
<DT id="104"><A HREF="#lbAH">DKMS.CONF</A><DD>
|
|
<DT id="105"><A HREF="#lbAI">DKMS.CONF VARIABLES</A><DD>
|
|
<DT id="106"><A HREF="#lbAJ">DKMS.CONF OVERRIDES</A><DD>
|
|
<DT id="107"><A HREF="#lbAK">/etc/dkms/framework.conf</A><DD>
|
|
<DT id="108"><A HREF="#lbAL">dkms_autoinstaller</A><DD>
|
|
<DT id="109"><A HREF="#lbAM">MODULES.CONF / MODPROBE.CONF CHANGES</A><DD>
|
|
<DT id="110"><A HREF="#lbAN">CREATING RPMS WHICH UTILIZE DKMS</A><DD>
|
|
<DT id="111"><A HREF="#lbAO">AUTHOR</A><DD>
|
|
<DT id="112"><A HREF="#lbAP">WEBPAGE</A><DD>
|
|
<DT id="113"><A HREF="#lbAQ">WHITE-PAPERS</A><DD>
|
|
<DT id="114"><A HREF="#lbAR">MAILING-LIST</A><DD>
|
|
<DT id="115"><A HREF="#lbAS">REFERENCES</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:11 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|