{ "content": [ { "type": "text", "text": "# dkms (man)\n\n## NAME\n\ndkms - Dynamic Kernel Module Support\n\n## SYNOPSIS\n\ndkms [action] [options] [module/module-version] [/path/to/source-tree] [/path/to/tarball.tar]\n[/path/to/driver.rpm]\n\n## DESCRIPTION\n\ndkms is a framework which allows kernel modules to be dynamically built for each kernel on\nyour system in a simplified and organized fashion.\n\n## TLDR\n\n> A framework that allows for dynamic building of kernel modules.\n\n- List currently installed modules:\n `dkms status`\n- Rebuild all modules for the currently running kernel:\n `sudo dkms autoinstall`\n- Install version 1.2.1 of the acpi_call module for the currently running kernel:\n `sudo dkms install -m {{acpi_call}} -v {{1.2.1}}`\n- Remove version 1.2.1 of the acpi_call module from all kernels:\n `sudo dkms remove -m {{acpi_call}} -v {{1.2.1}} --all`\n\n*Source: tldr-pages*\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **ACTIONS** (1 subsections)\n- **OPTIONS** (27 subsections)\n- **ORIGINAL MODULES** (8 subsections)\n- **CREATING RPMS WHICH UTILIZE DKMS**\n- **AUTHOR**\n- **WEBPAGE**\n- **MAILING-LIST**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "dkms", "section": "", "mode": "man", "summary": "dkms - Dynamic Kernel Module Support", "synopsis": "dkms [action] [options] [module/module-version] [/path/to/source-tree] [/path/to/tarball.tar]\n[/path/to/driver.rpm]", "tldr_summary": "A framework that allows for dynamic building of kernel modules.", "tldr_examples": [ { "description": "List currently installed modules", "command": "dkms status" }, { "description": "Rebuild all modules for the currently running kernel", "command": "sudo dkms autoinstall" }, { "description": "Install version 1.2.1 of the acpi_call module for the currently running kernel", "command": "sudo dkms install -m {{acpi_call}} -v {{1.2.1}}" }, { "description": "Remove version 1.2.1 of the acpi_call module from all kernels", "command": "sudo dkms remove -m {{acpi_call}} -v {{1.2.1}} --all" } ], "tldr_source": "official", "flags": [ { "flag": "-m", "long": null, "arg": null, "description": "The name of the module and module version you want to operate on. The -m part of this option is optional, and can be omitted in virtually all circumstances." }, { "flag": "-v", "long": null, "arg": "", "description": "The version of the module to execute the specified action upon. This option only has to be specified if you pass a -m option without a component of its own." }, { "flag": "-k", "long": null, "arg": null, "description": "The kernel and arch to perform the action upon. You can specify multiple kernel ver‐ sion/arch pairs on the command line by repeating the -k argument with a different ker‐ nel 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." }, { "flag": "-a", "long": "--arch", "arg": null, "description": "The system architecture to perform the action upon. It is optional if you pass it as part of the -k 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 architec‐ tures are specified, there must be a 1:1 relationship between -k arguments to -a argu‐ ments. DKMS will then assume the first -a argument aligns with the first -k kernel and so on for the second, third, etc. For example, if you were to specify: -k kernel1 -k kernel2 -a i386 -k kernel3 -a i686 -a x8664, DKMS would process this as: kernel1-i386, kernel2-i686, kernel3-x8664." }, { "flag": "-q", "long": "--quiet", "arg": null, "description": "Quiet." }, { "flag": "-V", "long": "--version", "arg": null, "description": "Prints the currently installed version of dkms and exits." }, { "flag": "-c", "long": null, "arg": "", "description": "The location of the dkms.conf file. This is needed for the add action and if not specified, it is assumed to be located in /usr/src/-/. See below for more information on the format of dkms.conf." }, { "flag": "-d", "long": "--distro", "arg": null, "description": "The distribution being used. This is only currently needed for mkdriverdisk. The supported distros are redhat, suse and UnitedLinux. See the sections on mkdriverdisk and mkkmp for more information." }, { "flag": "-r", "long": "--release", "arg": null, "description": "The release being used. This is only currently used for mkdriverdisk and is only used for suse or UnitedLinux distros (eg. -r 9.1). It is used in the internal makeup of the driverdisk. --size 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 divisi‐ ble by 20 and should represent the number of kilobytes of the image size you desire." }, { "flag": "", "long": "--config", "arg": "", "description": "During a build this option is used to specify an alternate location for the kernel .config file which was used to compile that kernel. Normally, dkms uses the Red Hat standard location and config filenames located in /usr/src/linux-/configs/. 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 dkms where the necessary .config can be found so that your kernel can be properly prepared for the module build." }, { "flag": "", "long": "--archive", "arg": "", "description": "This option is used during a ldtarball action to specify the location of the tarball you wish to load into your DKMS tree. You only have to specify the --archive part of this option if does not already exist as a file." }, { "flag": "", "long": "--templatekernel", "arg": "", "description": "This option is required for the action: match. Match will look at the templatekernel specified and install all of the same module/version combinations on the other kernel." }, { "flag": "", "long": "--force", "arg": null, "description": "This option can be used in conjunction with ldtarball to force copying over of extant files." }, { "flag": "", "long": "--binaries-only", "arg": null, "description": "This option can be used in conjunction with mktarball in order to create a DKMS tar‐ ball 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 you must have the module source in that systems DKMS tree. If you do not, DKMS will refuse to load a binaries-only tarball." }, { "flag": "", "long": "--source-only", "arg": null, "description": "This option can be used in conjunction with mktarball or mkrpm or mkdeb 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 mkrpm 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. --all This option can be used to automatically specify all relevant kernels/arches for a module/module-version. This is useful for things like remove , mktarball , 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." }, { "flag": "", "long": "--no-prepare-kernel", "arg": null, "description": "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 com‐ piled correctly." }, { "flag": "", "long": "--no-clean-kernel", "arg": null, "description": "This option keeps DKMS from cleaning your kernel source tree after a build." }, { "flag": "", "long": "--no-depmod", "arg": null, "description": "This option prevents DKMS from running the depmod command during install and uninstall which will avoid (re)calculating module dependencies and thereby save time." }, { "flag": "", "long": "--kernelsourcedir", "arg": "", "description": "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 /lib/mod‐ ules/$kernelversion/build." }, { "flag": "", "long": "--directive", "arg": "<\"cli-directive=cli-value\">", "description": "Using this option, you can specify additional directives from the command line. The --directive option can be used multiple times on the same command-line to specify mul‐ tiple additional command line directives. --rpmsafeupgrade This flag should be used when packaging DKMS enabled modules in RPMs. It should be specified during both the add and remove 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." }, { "flag": "", "long": "--spec", "arg": null, "description": "This option is used by the mkkmp action to specify which RPM spec file to use when generating the KMP. specfile will be sought in the module source directory." }, { "flag": "", "long": "--dkmstree", "arg": null, "description": "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." }, { "flag": "", "long": "--sourcetree", "arg": null, "description": "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." }, { "flag": "", "long": "--installtree", "arg": null, "description": "Provides a location to place modules when a dkms install command is issued." }, { "flag": "", "long": "--legacy-postinst", "arg": "[0|1", "description": "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." }, { "flag": "", "long": "--dkmsframework", "arg": null, "description": "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." }, { "flag": "-j", "long": null, "arg": null, "description": "Run no more than number jobs in parallel; see the -j option of make(1). Defaults to the number of CPUs in the system, detected by nproc(1). Specify 0 to impose no limit on the number of parallel jobs." } ], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 3, "subsections": [] }, { "name": "DESCRIPTION", "lines": 3, "subsections": [] }, { "name": "ACTIONS", "lines": 160, "subsections": [ { "name": "autoinstall", "lines": 4 } ] }, { "name": "OPTIONS", "lines": 1, "subsections": [ { "name": "-m /", "lines": 3, "flag": "-m" }, { "name": "-v ", "lines": 4, "flag": "-v", "arg": "" }, { "name": "-k /", "lines": 6, "flag": "-k" }, { "name": "-a, --arch", "lines": 11, "flag": "-a", "long": "--arch" }, { "name": "-q, --quiet", "lines": 2, "flag": "-q", "long": "--quiet" }, { "name": "-V, --version", "lines": 2, "flag": "-V", "long": "--version" }, { "name": "-c ", "lines": 4, "flag": "-c", "arg": "" }, { "name": "-d, --distro", "lines": 4, "flag": "-d", "long": "--distro" }, { "name": "-r, --release", "lines": 8, "flag": "-r", "long": "--release" }, { "name": "--config ", "lines": 8, "long": "--config", "arg": "" }, { "name": "--archive ", "lines": 4, "long": "--archive", "arg": "" }, { "name": "--templatekernel ", "lines": 3, "long": "--templatekernel", "arg": "" }, { "name": "--force", "lines": 3, "long": "--force" }, { "name": "--binaries-only", "lines": 7, "long": "--binaries-only" }, { "name": "--source-only", "lines": 12, "long": "--source-only" }, { "name": "--no-prepare-kernel", "lines": 4, "long": "--no-prepare-kernel" }, { "name": "--no-clean-kernel", "lines": 2, "long": "--no-clean-kernel" }, { "name": "--no-depmod", "lines": 3, "long": "--no-depmod" }, { "name": "--kernelsourcedir ", "lines": 4, "long": "--kernelsourcedir", "arg": "" }, { "name": "--directive <\"cli-directive=cli-value\">", "lines": 11, "long": "--directive", "arg": "<\"cli-directive=cli-value\">" }, { "name": "--spec specfile", "lines": 3, "long": "--spec" }, { "name": "--dkmstree path/to/place", "lines": 3, "long": "--dkmstree" }, { "name": "--sourcetree path/to/place", "lines": 3, "long": "--sourcetree" }, { "name": "--installtree path/to/place", "lines": 2, "long": "--installtree" }, { "name": "--legacy-postinst=[0|1]", "lines": 3, "long": "--legacy-postinst", "arg": "[0|1]" }, { "name": "--dkmsframework path/to/file", "lines": 4, "long": "--dkmsframework" }, { "name": "-j number", "lines": 4, "flag": "-j" } ] }, { "name": "ORIGINAL MODULES", "lines": 33, "subsections": [ { "name": "MAKE[#]=", "lines": 111 }, { "name": "STRIP[#]=", "lines": 51 }, { "name": "PATCH[#]=", "lines": 18 }, { "name": "AUTOINSTALL=", "lines": 50 }, { "name": "DKMS.CONF VARIABLES", "lines": 3 }, { "name": "$kernelver", "lines": 23 }, { "name": "DKMS.CONF OVERRIDES", "lines": 39 }, { "name": "MODULES.CONF / MODPROBE.CONF CHANGES", "lines": 37 } ] }, { "name": "CREATING RPMS WHICH UTILIZE DKMS", "lines": 29, "subsections": [] }, { "name": "AUTHOR", "lines": 2, "subsections": [] }, { "name": "WEBPAGE", "lines": 2, "subsections": [] }, { "name": "MAILING-LIST", "lines": 5, "subsections": [] } ], "sections": { "NAME": { "content": "dkms - Dynamic Kernel Module Support\n", "subsections": [] }, "SYNOPSIS": { "content": "dkms [action] [options] [module/module-version] [/path/to/source-tree] [/path/to/tarball.tar]\n[/path/to/driver.rpm]\n", "subsections": [] }, "DESCRIPTION": { "content": "dkms is a framework which allows kernel modules to be dynamically built for each kernel on\nyour system in a simplified and organized fashion.\n", "subsections": [] }, "ACTIONS": { "content": "add [module/module-version] [/path/to/source-tree] [/path/to/tarball.tar]\n\nAdds a module/module-version combination to the tree for builds and installs. If mod‐\nule/module-version, -m module/module-version, or -m module -v version are passed as op‐\ntions, this command requires source in /usr/src/-/ as well as a\nproperly formatted dkms.conf file. If /path/to/source-tree is passed as an option, and\nsource-tree contains a dkms.conf file, it will copy /path/to/source-tree to /usr/src/mod‐\nule-module-version. If /path/to/tarball.tar is passed, this command behaves like the ld‐‐\ntarball command.\n\nremove [module/module-version] [-k kernel/arch] [--all]\n\nRemoves a module/version or module/version/kernel/arch combination from the tree. If the\nmodule is currently installed, it first uninstalls it and if applicable, will replace it\nwith its originalmodule. Use the --all option in order to remove all instances for ev‐\nery kernel at once.\n\nbuild [module/module-version] [-k kernel/arch]\n\nBuilds the specified module/version combo for the specified kernel/arch. If the -k option\nis not specified it builds for the currently running kernel and arch.. All builds occur\nin the directory /var/lib/dkms///build/. If the module/mod‐\nule-version combo has not been added, dkms will try to add it, and in that case build can\ntake the same arguments that add can.\n\nunbuild [module/module-version] [-k kernel/arch] [--all]\n\nUndoes the build for a module/version or module/version/kernel/arch combination from the\ntree. If the module is currently installed, it first uninstalls it and if applicable,\nwill replace it with its originalmodule. Finally all binary kernel modules are removed.\nUse the --all option in order to remove all instances for every kernel at once.\n\ninstall [module/module-version] [-k kernel/arch] [/path/to/driver.rpm]\n\nInstalls a built module/version combo onto the kernel it was built for. If the kernel op‐\ntion is not specified it assumes the currently running kernel. If the module has not\nbeen built, dkms will try to build it. If the module has not been added, dkms will try\nto add it. In both cases, the install command can then take the same arguments as the\nbuild or add commands. If you pass a .rpm file, dkms will try to install that file with\nrpm -Uvh , and it will perform an autoinstall action to be sure that everything is built\nfor your kernel if the RPM installed successfully.\n\nuninstall [module/module-version] [-k kernel/arch] [--all]\n\nUninstalls an installed module/module-version combo from the kernel/arch passed in the -k\noption, or the current kernel if the -k option was not passed. Use the --all option in\norder to uninstall all instances for every kernel at once. After uninstall completion,\nthe driver will be left in the built state. To completely remove a driver, the remove\naction should be utilized.\n\nmatch [--templatekernel kernel/arch] [-k kernel/arch]\n\nMatch installs modules onto the specified kernel by looking at the configuration of the\nspecified templatekernel. Every module that is installed on the templatekernel within\ndkms is then installed on that specified kernel.\n\nmkdriverdisk [-d distro] [-r release] [--media mediatype] [-k kernel/arch] [module/version]\n\nCreates a floppy driver disk image for use when updated drivers are needed to install an\nOS. Currently, the supported distributions are redhat, suse and UnitedLinux. For Red Hat\ndriver disks, necessary driver disk files are looked for in the redhatdriverdisk subdi‐\nrectory of your module source directory. You must specify the distro while using this\naction. Driver disks can be made for single kernels or can be made to support multiple\nkernels. To create a driver disk image with modules for multiple kernels, just specify\nmultiple -k parameters on the command line (-k kernel1/arch1 -k kernel2/arch2).\n\nRed Hat introduced DDv3 starting with RHEL6. To create Red Hat DDv3, specify -d redhat3\nand specify the specfile to use with --spec=specfile. If no specfile is specified, DKMS\nwill use /etc/dkms/template-dkms-redhat-kmod.spec\n\nFor suse/UnitedLinux driver disks, /usr/share/YaST2/modules/Vendor.ycp will also be\ncopied to the driver disk; no other files are needed. However, for these distros, you\nmust specify a -r release. For SuSE 9.1, it would be -d suse -r 9.1. For SLES9, it would\nbe -d suse -r sles9.\n\nBy default the disk image it creates is 1440 (k) in size. This can be overridden by\nspecifying a different --size #### which should should be given as a number in kilobytes\ndivisible by 20.\n\nYou may have more content than will fit on a floppy. Therefore, DKMS can now generate\nimage files of different types. --media floppy (default) to generate a floppy disk im‐\nage, or --media iso to generate a CD-ROM ISO file, or --media tar to generate a tar file.\n\nYou may copy the floppy or ISO image file to a USB key to be used with OS installer.\n\nmktarball [module/module-version] [-k kernel/arch] [--archive /path/to/tarball.tar]\n[--source-only] [--binaries-only]\n\nCreates a tarball archive for the specified module/version of all files in the DKMS tree\nfor that module/version combination. This includes the source and any built modules for\nkernels in the tree (as specified). Otherwise, you can specify a singular kernel to ar‐\nchive only, or multiple kernels to archive (-k kernel1/arch1 -k kernel2/arch2). Option‐\nally, you can use --archive to specify the file that you would like to save this tarball\nto. You can also specify --binaries-only if you want the resultant tarball not to in‐\nclude the module source. Likewise, --source-only can be used to specify that no prebuilt\nbinaries should be included in the tarball. In general, mktarball is great for systems\nmanagement purposes as you can build your driver on just one system and then use ldtar‐‐\nball on all of your other systems to get the same built modules loaded without having to\nwait for anything to compile.\n\nldtarball [/path/to/tarball.tar] [--force]\n\nThis takes a tarball made from the mktarball command and loads it into your DKMS tree.\nThis will leave any newly added modules in the built state and dkms install should then\nbe called to install any of them. If files already exist where ldtarball is attempting\nto place them, it will warn and not copy over them. The --force option should be used to\noverride this.\n\nmkrpm [module/module-version] [-k kernel/arch] [--source-only] [--binaries-only]\n\nThis action allows you to create an RPM package for a specified module / version. It\nuses a template .spec file found in /etc/dkms/template-dkms-mkrpm.spec as the basis for\nthe RPM. Alternatively, if DKMS finds a file called /usr/src/-/-dkms-mkrpm.spec it will use that .spec file instead. In general, a DKMS\ntarball is placed inside the contents of this RPM, and the RPM itself calls various DKMS\ncommands to load this tarball, build and install modules on the end user's system. If\nyou do not want your RPM to contain any prebuilt binaries, be sure to specify\n--source-only in the mkrpm command.\n\nmkdeb [module/module-version] [-k kernel/arch]\n\nThis action allows you to create a debian binary package for a specified module / ver‐\nsion. It uses a template debian directory found in /etc/dkms/template-dkms-mkdeb as the\nbasis for the package. Alternatively, if DKMS finds a file called /usr/src/-/-dkms-mkdeb it will use that folder instead. In general, a DKMS tar‐\nball is placed inside the contents of this package, and the package itself calls various\nDKMS commands to load this tarball, build and install modules on the end user's system.\n\nmkbmdeb [module/module-version] [-k kernel/arch]\n\nCreates a Debian binary package containing just the binary modules in the /lib/modules\ninstallation path. This package does not depend on dkms and does not require a toolchain\nto be installed on the target host. Useful if you want to have a package to install on\nhosts identical to the build system without installing the full toolchain on them. It\nuses a template debian directory found in /etc/dkms/template-dkms-mkbmdeb as the basis\nfor the package.\n\nmkdsc [module/module-version] [-k kernel/arch]\n\nThis action allows you to create a debian source package for a specified module / ver‐\nsion. It will create a .tar.gz, and a .dsc. All options supported by mkdeb are sup‐\nported by it. The main difference in it's usage is that it will look in /etc/dkms/tem‐\nplate-dkms-mkdsc as the basis for the package. Alternatively, if DKMS finds a file called\n/usr/src/-/-dkms-mkdsc it will use that folder instead.\n\nmkkmp [module/module-version] [--spec specfile]\n\nThis action allows you to create an Kernel Module Package source RPM for a specified mod‐\nule / version. It uses the .spec file specified by --spec=specfile else $module-kmp.spec\nas the basis for the RPM. The generated source RPM may then be built using SuSE's\nbuild.rpm or Fedora/RHEL's mock chroot environments. See http://kerneldrivers.org/ for\nmore details on KMPs.\n\nstatus [module/module-version] [-k kernel/arch]\n\nReturns the current status of modules, versions and kernels within the tree as well as\nwhether they have been added, built or installed. Status can be shown for just a certain\nmodule, a certain kernel, a module/version combination or a module/version/kernel combi‐\nnation.\n", "subsections": [ { "name": "autoinstall", "content": "Attempt to install the latest revision of all modules that have been installed for other\nkernel revisions. dkmsautoinstaller is a stub that uses this action to perform its\nwork.\n" } ] }, "OPTIONS": { "content": "", "subsections": [ { "name": "-m /", "content": "The name of the module and module version you want to operate on. The -m part of this\noption is optional, and can be omitted in virtually all circumstances.\n", "flag": "-m" }, { "name": "-v ", "content": "The version of the module to execute the specified action upon. This option only has\nto be specified if you pass a -m option without a component of its\nown.\n", "flag": "-v", "arg": "" }, { "name": "-k /", "content": "The kernel and arch to perform the action upon. You can specify multiple kernel ver‐\nsion/arch pairs on the command line by repeating the -k argument with a different ker‐\nnel version and arch. However, not all actions support multiple kernel versions (it\nwill error out in this case). The arch part can be omitted, and DKMS will assume you\nwant it to be the arch of the currently running system.\n", "flag": "-k" }, { "name": "-a, --arch", "content": "The system architecture to perform the action upon. It is optional if you pass it as\npart of the -k option. If not specified, it assumes the arch of the currently running\nsystem (`uname -m`). You can specify multiple arch parameters on the same command\nline by repeating the -a argument with a different arch name. When multiple architec‐\ntures are specified, there must be a 1:1 relationship between -k arguments to -a argu‐\nments. DKMS will then assume the first -a argument aligns with the first -k kernel\nand so on for the second, third, etc.\n\nFor example, if you were to specify: -k kernel1 -k kernel2 -a i386 -k kernel3 -a i686\n-a x8664, DKMS would process this as: kernel1-i386, kernel2-i686, kernel3-x8664.\n", "flag": "-a", "long": "--arch" }, { "name": "-q, --quiet", "content": "Quiet.\n", "flag": "-q", "long": "--quiet" }, { "name": "-V, --version", "content": "Prints the currently installed version of dkms and exits.\n", "flag": "-V", "long": "--version" }, { "name": "-c ", "content": "The location of the dkms.conf file. This is needed for the add action and if not\nspecified, it is assumed to be located in /usr/src/-/. See\nbelow for more information on the format of dkms.conf.\n", "flag": "-c", "arg": "" }, { "name": "-d, --distro", "content": "The distribution being used. This is only currently needed for mkdriverdisk. The\nsupported distros are redhat, suse and UnitedLinux. See the sections on mkdriverdisk\nand mkkmp for more information.\n", "flag": "-d", "long": "--distro" }, { "name": "-r, --release", "content": "The release being used. This is only currently used for mkdriverdisk and is only used\nfor suse or UnitedLinux distros (eg. -r 9.1). It is used in the internal makeup of\nthe driverdisk.\n\n--size The size of the driver disk image to be created. By default, this value is set at\n1440. Any different size should be given as an integer value only, should be divisi‐\nble by 20 and should represent the number of kilobytes of the image size you desire.\n", "flag": "-r", "long": "--release" }, { "name": "--config ", "content": "During a build this option is used to specify an alternate location for the kernel\n.config file which was used to compile that kernel. Normally, dkms uses the Red Hat\nstandard location and config filenames located in /usr/src/linux-/configs/.\nIf the config for the kernel that you are building a module for is not located here or\ndoes not have the expected name in this location, you will need to tell dkms where the\nnecessary .config can be found so that your kernel can be properly prepared for the\nmodule build.\n", "long": "--config", "arg": "" }, { "name": "--archive ", "content": "This option is used during a ldtarball action to specify the location of the tarball\nyou wish to load into your DKMS tree. You only have to specify the --archive part of\nthis option if does not already exist as a file.\n", "long": "--archive", "arg": "" }, { "name": "--templatekernel ", "content": "This option is required for the action: match. Match will look at the templatekernel\nspecified and install all of the same module/version combinations on the other kernel.\n", "long": "--templatekernel", "arg": "" }, { "name": "--force", "content": "This option can be used in conjunction with ldtarball to force copying over of extant\nfiles.\n", "long": "--force" }, { "name": "--binaries-only", "content": "This option can be used in conjunction with mktarball in order to create a DKMS tar‐\nball which does not contain the source for the module within it. This can be helpful\nin reducing the size of the tarball if you know that the system which this tarball\nwill be loaded upon already has the source installed. In order to load a tarball made\nas binaries-only you must have the module source in that systems DKMS tree. If you do\nnot, DKMS will refuse to load a binaries-only tarball.\n", "long": "--binaries-only" }, { "name": "--source-only", "content": "This option can be used in conjunction with mktarball or mkrpm or mkdeb in order to\ncreate a DKMS tarball which does not contain any prebuilt kernel module binaries\nwithin it. This is helpful if you simply want to easily tar up your source but don't\nwant anything prebuilt within it. Likewise, if you are using mkrpm but do not want\nthe RPM you create to have any prebuilt modules within it, passing this option will\nkeep its internal DKMS tarball from containing any prebuilt modules.\n\n--all This option can be used to automatically specify all relevant kernels/arches for a\nmodule/module-version. This is useful for things like remove , mktarball , etc. This\nsaves the trouble of having to actually specify -k kernel1 -a arch1 -k kernel2 -a\narch2 for every kernel you have built your module for.\n", "long": "--source-only" }, { "name": "--no-prepare-kernel", "content": "This option keeps DKMS from first preparing your kernel before building a module for\nit. Generally, this option should not be used so as to ensure that modules are com‐\npiled correctly.\n", "long": "--no-prepare-kernel" }, { "name": "--no-clean-kernel", "content": "This option keeps DKMS from cleaning your kernel source tree after a build.\n", "long": "--no-clean-kernel" }, { "name": "--no-depmod", "content": "This option prevents DKMS from running the depmod command during install and uninstall\nwhich will avoid (re)calculating module dependencies and thereby save time.\n", "long": "--no-depmod" }, { "name": "--kernelsourcedir ", "content": "Using this option you can specify the location of your kernel source directory. Most\nlikely you will not need to set this if your kernel source is accessible via /lib/mod‐\nules/$kernelversion/build.\n", "long": "--kernelsourcedir", "arg": "" }, { "name": "--directive <\"cli-directive=cli-value\">", "content": "Using this option, you can specify additional directives from the command line. The\n--directive option can be used multiple times on the same command-line to specify mul‐\ntiple additional command line directives.\n\n--rpmsafeupgrade\nThis flag should be used when packaging DKMS enabled modules in RPMs. It should be\nspecified during both the add and remove actions in the RPM spec to ensure that DKMS\nand RPM behave correctly in all scenarios when upgrading between various versions of a\ndkms enabled module RPM package. See the sample.spec file for an example or read more\nin the section below on Creating RPMs Which Utilize DKMS.\n", "long": "--directive", "arg": "<\"cli-directive=cli-value\">" }, { "name": "--spec specfile", "content": "This option is used by the mkkmp action to specify which RPM spec file to use when\ngenerating the KMP. specfile will be sought in the module source directory.\n", "long": "--spec" }, { "name": "--dkmstree path/to/place", "content": "Provides a destination tree for building and installing modules to. Useful in cases\nthat you don't want to contaminate a system when using solely for building.\n", "long": "--dkmstree" }, { "name": "--sourcetree path/to/place", "content": "Provides a location to build a DKMS package from. Useful for systems that you may not\nhave root access, but would still like to be able to build DKMS packages.\n", "long": "--sourcetree" }, { "name": "--installtree path/to/place", "content": "Provides a location to place modules when a dkms install command is issued.\n", "long": "--installtree" }, { "name": "--legacy-postinst=[0|1]", "content": "Includes a legacy postinstall script so that a DEB or RPM built by DKMS can be used on\nversions prior than DKMS 2.1. This option currently defaults to 1.\n", "long": "--legacy-postinst", "arg": "[0|1]" }, { "name": "--dkmsframework path/to/file", "content": "A supplemental configuration file to the system-wide dkms framework, typically located\nin /etc/dkms/framework.conf. All option that are normally provided on a command line\ncan be provided in this file.\n", "long": "--dkmsframework" }, { "name": "-j number", "content": "Run no more than number jobs in parallel; see the -j option of make(1). Defaults to\nthe number of CPUs in the system, detected by nproc(1). Specify 0 to impose no limit\non the number of parallel jobs.\n", "flag": "-j" } ] }, "ORIGINAL MODULES": { "content": "During the first install of a module for a , dkms will search /lib/mod‐\nules/ for a pre-existing module of the same name. If one is found, it will au‐\ntomatically be saved as an \"originalmodule\" so that if the newer module is later removed,\ndkms will put the original module back in its place. Currently, DKMS searches for these\noriginal modules with first preference going to modules located in /lib/modules//updates/ followed by $DESTMODULELOCATION (as specified in dkms.conf ). If one cannot\nbe found in either location, a find will be used to locate one for that kernel. If none are\nfound, then during a later uninstall, your kernel will not have that module replaced.\n\nIf more than one is found, then the first one located (by preference indicated above) will be\nconsidered the \"originalmodule\". As well, all copies of the same-named module will be re‐\nmoved from your kernel tree and placed into /var/lib/dkms//originalmodule/$ker‐\nnelver/collisions so that they can be *manually* accessible later. DKMS will never actually\ndo anything with the modules found underneath the /collisions directory, and they will be\nstored there until you manually delete them.\n\nDKMS.CONF\nWhen performing an add , a proper dkms.conf file must be found. A properly formatted conf\nfile is essential for communicating to dkms how and where the module should be installed.\nWhile not all the directives are required, providing as many as possible helps to limit any\nambiguity. Note that the dkms.conf is really only a shell-script of variable definitions\nwhich are then sourced in by the dkms executable (of the format, DIRECTIVE=\"directive text\ngoes here\"). As well, the directives are case-sensitive and should be given in ALL CAPS.\n\nIt is important to understand that many of the DKMS directives are arrays whose index values\nare tied together. These array associations can be considered families, and there are cur‐\nrently four such families of directive arrays. MAKE[#] and MAKEMATCH[#] make up one family.\nPATCH[#] and PATCHMATCH[#] make up the second family. The third and largest family con‐\nsists of BUILTMODULENAME[#], BUILTMODULELOCATION[#], DESTMODULENAME[#], DESTMODULELO‐\nCATION[#], MODULESCONFALIASTYPE[#], MODULESCONFOBSOLETES[#], MODULESCONFOBSO‐\nLETEONLY[#] and STRIP[#]. The fourth family is made up of only MODULESCONF[#]. When in‐\ndexing these arrays when creating your dkms.conf, each family should start at index value 0.\n", "subsections": [ { "name": "MAKE[#]=", "content": "The MAKE directive array tells DKMS which make command should be used for building\nyour module. The default make command should be put into MAKE[0]. Other entries in\nthe MAKE array will only be used if their corresponding entry in MAKEMATCH[#]\nmatches, as a regular expression (using egrep), the kernel that the module is being\nbuilt for. Note that if no value is placed in MAKEMATCH[#] for any MAKE[#] where # >\n0, then that MAKE directive is ignored. MAKEMATCH[0] is optional and if it is popu‐\nlated, it will be used to determine if MAKE[0] should be used to build the module for\nthat kernel. If multiple MAKEMATCH directives match against the kernel being built\nfor, the last matching MAKE[#] will be used to build your module. If no MAKE directive\nis specified or if no MAKEMATCH matches the kernel being built for, DKMS will attempt\nto use a generic MAKE command to build your module.\n\nKERNELRELEASE will be automatically appended to MAKE[#]. If you want to suppress this\nbehavior, you can quote the make command: 'make'.\n\nMAKEMATCH[#]=\nSee the above entry on MAKE[#] directives. This array should be populated with regu‐\nlar expressions which, when matched against the kernel being built for, will tell DKMS\nto use the corresponding make command in the MAKE[#] directive array to build your\nmodule.\n\nBUILTMODULENAME[#]=\nThis directive gives the name of the module just after it is built. If your DKMS mod‐\nule package contains more than one module to install, this is a required directive for\nall of the modules. This directive should explicitly not contain any trailing \".o\" or\n\".ko\". Note that for each module within a dkms package, the numeric value of # must\nbe the same for each of BUILTMODULENAME, BUILTMODULELOCATION, DESTMODULENAME and\nDESTMODULELOCATION and that the numbering should start at 0 (eg. BUILTMOD‐\nULENAME[0]=\"qla2200\" BUILTMODULENAME[1]=\"qla2300\").\n\nBUILTMODULELOCATION[#]=\nThis directive tells DKMS where to find your built module after it has been built.\nThis pathname should be given relative to the root directory of your source files\n(where your dkms.conf file can be found). If unset, DKMS expects to find your\nBUILTMODULENAME[#] in the root directory of your source files. Note that for each\nmodule within a dkms package, the numeric value of # must be the same for each of\nBUILTMODULENAME, BUILTMODULELOCATION, DESTMODULENAME and DESTMODULELOCATION\nand that the numbering should start at 0 (eg. BUILTMODULELOCATION[0]=\"some/dir/\"\nBUILTMODULELOCATION[1]=\"other/dir/\").\n\nDESTMODULENAME[#]=\nThis directive can be used to specify the name of the module as it should be in‐\nstalled. This will rename the module from BUILTMODULENAME[#] to DESTMOD‐‐\nULENAME[#]. This directive should explicitly not contain any trailing \".o\" or \".ko\".\nIf unset, it is assumed to be the same value as BUILTMODULENAME[#]. Note that for\neach module within a dkms package, the numeric value of # must be the same for each of\nBUILTMODULENAME, BUILTMODULELOCATION, DESTMODULENAME and DESTMODULELOCATION\nand that the numbering should start at 0 (eg. DESTMODULENAME[0]=\"qla22006x\"\nDESTMODULENAME[1]=\"qla23006x\").\n\nDESTMODULELOCATION[#]=\nThis directive specifies the destination where a module should be installed to, once\ncompiled. It also is used for finding originalmodules. This is a required direc‐\ntive, except as noted below. This directive must start with the text \"/kernel\" which\nis in reference to /lib/modules//kernel. Note that for each module\nwithin a dkms package, the numeric value of # must be the same for each of BUILTMOD‐\nULENAME, BUILTMODULELOCATION, DESTMODULENAME and DESTMODULELOCATION and that\nthe numbering should start at 0 (eg. DESTMODULELOCATION[0]=\"/kernel/drivers/some‐\nthing/\" DESTMODULELOCATION[1]=\"/kernel/drivers/other/\").\n\nDESTMODULELOCATION is ignored on Fedora and Red Hat Enterprise Linux, Novell SuSE\nLinux Enterprise Server 10 and higher, Novell SuSE Linux 10.0 and higher, and Ubuntu.\nInstead, the proper distribution-specific directory is used.\n\nMODULESCONFALIASTYPE[#]=\nThis directive array specifies how your modules should be aliased in /etc/modules.conf\nwhen your module is installed. This is done in an intelligent fashion so if DKMS de‐\ntects an already existing reference in modules.conf, it won't add a new line. If it\nis not detected, it will add it to the modules.conf as the last alias number for that\nalias type (eg. if MODULESCONFALIASTYPE=\"scsihostadapter\", no alias currently ex‐\nists for that module and the last scsihostadapter reference is 6, then your module\nwill be added as \"scsihostadapter7\"). Common values for this directive include:\nscsihostadapter , sound-slot- and eth. Note that the numeric value of # is tied to\nthe index of BUILTMODULENAME, BUILTMODULELOCATION, DESTMODULENAME and DESTMOD‐\nULELOCATION. The index is also tied to MODULESCONFOBSOLETES.\n\nMODULESCONFOBSOLETES[#]=\nThis directive array tells DKMS what modules.conf alias references are obsoleted by\nthe module you are installing. If your module obsoletes more than one module, this\ndirective should be a comma-delimited list of those modules that are obsoleted (eg.\nfor megaraid2, MODULESCONFOBSOLETES[0]=\"megaraid,megaraid2002\"). When you are in‐\nstalling your module, DKMS ensures that any entries in /etc/modules.conf with the same\nMODULESCONFALIASTYPE are changed over to the new module name. When you are unin‐\nstalling your module, depending on the modules in your /lib/modules tree, DKMS will\ntake different actions. If you kernel has an originalmodule, then modules.conf will\nnot be touched and the non-obsolete reference will remain. If the kernel does not\nhave an originalmodule but does have one of the obsolete modules, it will replace\nthose references with the first obsolete module name in the comma-delimited list that\nis also in that kernel (thus, your obsolete list should be prioritized from left to\nright). If no originalmodule or obsolete modules are found within the kernel, the\nalias entry is removed all-together. Note that the numeric value of # is tied to the\nindex of BUILTMODULENAME, BUILTMODULELOCATION, DESTMODULENAME and DESTMOD‐\nULELOCATION. The index is also tied to MODULESCONFALIASTYPE.\n\nMODULESCONFOBSOLETEONLY[#]=\nIf set to yes , this directive will tell DKMS to only modify /etc/modules.conf if it\nfinds within it an obsolete reference as specified in the corresponding value of MOD‐‐\nULESCONFOBSOLETES[#] array directive.\n\nNOWEAKMODULES=\nThe NOWEAKMODULES parameter prevents dkms from creating a symlink into the weak-up‐\ndates directory, which is the default on Red Hat derivatives. The weak modules facil‐\nity was designed to eliminate the need to rebuild kernel modules when kernel upgrades\noccur and relies on the symbols within the kABI.\n\nFedora does not guaranteed a stable kABI so it should be disabled in the specific mod‐\nule override by setting it to \"yes\". For example, for an Nvidia DKMS module you would\nset the following in /etc/dkms/nvidia.conf:\n\nNOWEAKMODULES=\"yes\"\n" }, { "name": "STRIP[#]=", "content": "By default strip is considered to be \"yes\". If set to \"no\", DKMS will not run strip\n-g against your built module to remove debug symbols from it. STRIP[0] is used as the\ndefault for any unset entries in the STRIP array.\n\nPACKAGENAME=\nThis directive is used to give the name associated with the entire package of modules.\nThis is the same name that is used with the -m option when building, adding, etc. and\nmay not necessarily be the same as the MODULENAME. This directive must be present in\nevery dkms.conf.\n\nPACKAGEVERSION=\nThis directive is used to give the version associated with the entire package of mod‐\nules being installed within that dkms package. This directive must be present in ev‐\nery dkms.conf.\n\nCLEAN= CLEAN specifies the make clean command to be used to clean up both before and after\nbuilding the module. If unset, it is assumed to be \"make clean\".\n\nREMAKEINITRD=\nThis directive specifies whether your initrd should be remade after the module is in‐\nstalled onto the kernel. Any text after the first character is ignored and if the\nfirst character is not a \"y\" or a \"Y\", it is assumed that REMAKEINITRD=\"no\".\n\nMODULESCONF[#]=\nThis directive array specifies what static configuration text lines need to be added\ninto /etc/modules.conf for your module. See the section on MODULES.CONF CHANGES for\nmore information regarding the implications of modifying /etc/modules.conf\n\nOBSOLETEBY=\nThis directive allows you to specify a kernel version that obsoletes the necessity for\nthis particular DKMS module. This can be specified as a particular upstream kernel or\nan ABI bump of a kernel. For example, \"2.6.24\" would be an upstream kernel and\n\"2.6.24-16\" would represent an ABI bump for a kernel. Both are valid in this area.\n\nPlease avoid the use of OBSOLETEBY wherever possible. It's use indicates a lack of\nproper module versioning using MODULEVERSION() tags in the module source itself. It\nis better to fix the MODULEVERSION() tags than use OBSOLETEBY. This also introduces\na implicit distribution/version dependency on the package, as the value of OBSOLETEBY\nis meaningful only in the context of a single distribution/version.\n\nIf you feel you must use it, please use as such in dkms.conf:\n\nubuntu804=\"Ubuntu\n8.04\"\nif [ -x /usr/bin/lsbrelease ]; then\nif [ \"$(/usr/bin/lsbrelease -sir)\" == \"${ubuntu804}\" ]; then\nOBSOLETEBY=\"2.6.25\"\nfi\nfi\n\n" }, { "name": "PATCH[#]=", "content": "Use the PATCH directive array to specify patches which should be applied to your\nsource before a build occurs. All patches are expected to be in -p1 format and are\napplied with the patch -p1 command. Each directive should specify the filename of the\npatch to apply, and all patches must be located in the patches subdirectory of your\nsource directory ( /usr/src/-/patches/ ). If any patch fails\nto apply, the build will be halted and the rejections can be inspected in\n/var/lib/dkms///build/. If a PATCH should only be applied\nconditionally, the PATCHMATCH[#] array should be used, and a corresponding regular\nexpression should be placed in PATCHMATCH[#] which will alert dkms to only use that\nPATCH[#] if the regular expression matches the kernel which the module is currently\nbeing built for.\n\nPATCHMATCH[#]=\nSee the above description for PATCH[#] directives. If you only want a patch applied in\ncertain scenarios, the PATCHMATCH array should be utilized by giving a regular ex‐\npression which matches the kernels you intend the corresponding PATCH[#] to be applied\nto before building that module.\n" }, { "name": "AUTOINSTALL=", "content": "If this directive is set to yes then the service /etc/rc.d/init.d/dkmsautoinstaller\nwill automatically try to install this module on any kernel you boot into. See the\nsection on dkmsautoinstaller for more information.\n\nBUILDDEPENDS[#]=\nThis optional directive is an array that allows you to specify other modules as depen‐\ndencies for your module. Each array element should be the PACKAGENAME of another mod‐\nule that is managed by dkms. Do not specify a version or architecture in the depen‐\ndency. Note that this directive is only advisory; missing or broken dependencies cause\nnon-fatal warnings.\n\nBUILDEXCLUSIVEKERNEL=\nThis optional directive allows you to specify a regular expression which defines the\nsubset of kernels which DKMS is allowed to build your module for. If the kernel being\nbuilt for does not match against this regular expression, the dkms build will error\nout. For example, if you set it as =\"^2.4.*\", your module would not be built for 2.6\nkernels.\n\nBUILDEXCLUSIVEARCH=\nThis optional directive functions very similarly to BUILDEXCLUSIVEKERNEL except that\nit matches against the kernel architecture. For example, if you set it to =\"i.86\",\nyour module would not be built for ia32e, x8664, amd64, s390, etc.\n\nPOSTADD=\nThe name of the script to be run after an add is performed. The path should be given\nrelative to the root directory of your source.\n\nPOSTBUILD=\nThe name of the script to be run after a build is performed. The path should be given\nrelative to the root directory of your source.\n\nPOSTINSTALL=\nThe name of the script to be run after an install is performed. The path should be\ngiven relative to the root directory of your source.\n\nPOSTREMOVE=\nThe name of the script to be run after a remove is performed. The path should be given\nrelative to the root directory of your source.\n\nPREBUILD=\nThe name of the script to be run before a build is performed. The path should be given\nrelative to the root directory of your source.\n\nPREINSTALL=\nThe name of the script to be run before an install is performed. The path should be\ngiven relative to the root directory of your source. If the script exits with a\nnon-zero value, the install will be aborted. This is typically used to perform a cus‐\ntom version comparison.\n\n" }, { "name": "DKMS.CONF VARIABLES", "content": "Within your dkms.conf file, you can use certain variables which will be replaced at\nrun-time with their values.\n" }, { "name": "$kernelver", "content": "This variable can be used within a directive definition and during use, the actual\nkernel version in question will be substituted in its place. This is especially use‐\nful in MAKE commands when specifying which INCLUDE statements should be used when com‐\npiling your module (eg. MAKE=\"make all INCLUDEDIR=/lib/modules/${kernelver}/build/in‐\nclude\").\n\n$dkmstree\nSee the section on /etc/dkms/framework.conf for more information. This variable rep‐\nresents the location of the DKMS tree on the local system. By default this is\n/var/lib/dkms , but this value should not be hard-coded into a dkms.conf in the event\nthat the local user has changed it on their system.\n\n$sourcetree\nSee the section on /etc/dkms/framework.conf for more information. This variable rep‐\nresents the location where DKMS keeps source on the local system. By default this is\n/usr/src , but this value should not be hard-coded into a dkms.conf in the event that\nthe local user has changed it on their system.\n\n$kernelsourcedir\nThis variable holds the value of the location of your kernel source directory. Usu‐\nally, this will be /lib/modules/$kernelver/build , unless otherwise specified with the\n--kernelsourcedir option.\n" }, { "name": "DKMS.CONF OVERRIDES", "content": "You can override the module-provided dkms.conf files. Every time after a dkms.conf file is\nread, dkms will look for and read the following files in order:\n\n/etc/dkms/.conf\n/etc/dkms/-.conf\n/etc/dkms/--.conf\n/etc/dkms/---.conf\n\nYou can use these files to override settings in the module-provided dkms.conf files.\n\n/etc/dkms/framework.conf\nThis configuration file controls how the overall DKMS framework handles. It is sourced in\nevery time the dkms command is run. Mainly it can currently be used to set different default\nvalues for the variables.\n\n$dkmstree, $sourcetree, $installtree\ncontrol where DKMS looks for its framework.\n\n$symlinkmodules\ncontrols whether binary modules are copied to /lib/modules or if only symlinks are\ncreated there. Note that these variables can also be manipulated on the command line\nwith --dkmstree, --sourcetree, --installtree and --symlink-modules options.\n\n$signtool\nScript to be run at build for signing modules. Two arguments will be passed to the\nscript. The first argument is the target kernel version , the second is the module\nfile path. If the script exits with a non-zero value, the build will be aborted.\n\n$autoinstallallkernels\nused by the common postinst for DKMS modules. It controls if the build should be done\nfor all installed kernels or only for the current and latest installed kernel. It has\nno command line equivalent.\n\ndkmsautoinstaller\nThis boot-time service automatically installs any module which has AUTOINSTALL=\"yes\" set in\nits dkms.conf file. The service works quite simply and if multiple versions of a module are\nin your system's DKMS tree, it will not do anything and instead explain that manual interven‐\ntion is required.\n" }, { "name": "MODULES.CONF / MODPROBE.CONF CHANGES", "content": "Changes that your module will make to /etc/modules.conf or /etc/modprobe.conf should be spec‐\nified with the MODULESCONFALIASTYPE[#] , the MODULESCONFOBSOLETES[#] and the MOD‐‐\nULESCONF[#] directive arrays. These arrays should also be used even if your distro uses\n/etc/sysconfig/kernel to track kernel modules.\n\nWhen the first module is installed upon the first kernel within the user's system, these en‐\ntries in MODULESCONF[#] are automatically added to /etc/modules.conf and if REMAKEINITRD is\nspecified, then the user's initrd is then remade. Subsequently, as your modules are then\nlater removed from the user's system, until the final module/version combination is removed\nfrom the final kernel version, those references in modules.conf will remain. Once the last\nmodule/version combination is removed, those references are then removed.\n\nAs modules/versions are removed and initrds are remade, one of three things will happen if\nyou have specified a MODULESCONFALIASTYPE. If no originalmodule exists for that kernel,\nand no MODULESCONFOBSOLETES modules are found in that kernel too, the modules.conf alias\nreferences will temporarily be removed so that the initrd will successfully remake. Once the\ninitrd is remade, however; those references are then automatically put back into modules.conf\n(unless you are removing the last instance of the module on the last kernel). However, if no\noriginalmodule exists, but there is an OBSOLETE module found within that kernel, the alias\nreference is temporarily shifted to point to the OBSOLETE module so that the initrd can be\nremade. After it is remade, it then automatically puts back the alias reference (unless you\nare removing the last instance of the module on the last kernel). Lastly, if an origi‐\nnalmodule does exist for the kernel version, then modules.conf is not touched and all refer‐\nences persist (even if you are removing the last instance of the module on the last kernel).\n\nCertain module installations might not only require adding references to modules.conf but\nalso require removing conflicting references that might exist in the user's system. If this\nis the case, the MODULESCONFOBSOLETES[#] directive should be utilized to remove these ref‐\nerences. More information about this directive can be found in the DKMS.CONF section of this\nman page.\n\nNote that the end state of your modules.conf file very much depends on what kernel modules\nexist in the final kernel you remove your DKMS module from. This is an imperfect system\ncaused by the fact that there is only one modules.conf file for every kernel on your system\neven though various kernels use different modules. In a perfect world, there would be one\nmodules.conf file for every kernel (just like System.map).\n" } ] }, "CREATING RPMS WHICH UTILIZE DKMS": { "content": "See the sample.spec file packaged with DKMS as an example for what your RPM spec file might\nlook like. Creating RPMs which utilize dkms is a fairly straight-forward process. The RPM\nneed only to install the source into /usr/src/-/ and then employ dkms\nitself to do all the work of installation. As such, the RPM should first untar the source\ninto this directory. From here, within the RPM .spec file, a dkms add should be called (re‐\nmember to use the --rpmsafeupgrade flag during the add) followed by a dkms build followed\nby a dkms install. Your dkms.conf file should be placed within the /usr/src/-/ directory.\n\nUnder the removal parts of the .spec file, all that needs to be called is a: dkms remove -m\n -v --all --rpmsafeupgrade. Use of the --rpmsafeupgrade flag is\nimperative for making sure DKMS and RPM play nicely together in all scenarios of using the\n-Uvh flag with RPM to upgrade dkms enabled packages. It will only function if used during\nboth the add and remove actions within the same RPM spec file. Its use makes sure that when\nupgrading between different releases of an RPM for the same , DKMS does not\ndo anything dumb (eg. it ensures a smooth upgrade from megaraid-2.09-5.noarch.rpm to\nmegaraid-2.09-6.noarch.rpm).\n\nIt should be noted that a binary RPM which contains source is not a traditional practice.\nHowever, given the benefits of dkms it hopefully will become so. As the RPM created which\nutilizes dkms is not architecture specific, BuildArch: noarch should be specified in the\n.spec file to indicate that the package can work regardless of the system architecture. Also\nnote that DKMS RPM upgrades (-U option) will automatically work because of the structure of\nthe dkms tree.\n\nLastly, as a matter of convention, you should name your RPM: --dkms.noarch.rpm. The word dkms as part of the rpm-version signifies that the RPM works\nwithin the DKMS framework.\n", "subsections": [] }, "AUTHOR": { "content": "Gary Lerhaupt\n", "subsections": [] }, "WEBPAGE": { "content": "https://github.com/dell/dkms\n", "subsections": [] }, "MAILING-LIST": { "content": "dkms-devel@dell.com http://lists.us.dell.com/mailman/listinfo/dkms-devel\n\n\n\ndkms-2.8.7 01 October 2021 DKMS(8)", "subsections": [] } } } }