1DKMS(8) System Manager's Manual DKMS(8)
2
6 dkms - Dynamic Kernel Module Support
7
9 dkms [action] [options] [module/module-version] [/path/to/source-tree]
10 [/path/to/tarball.tar] [/path/to/driver.rpm]
11
13 dkms is a framework which allows kernel modules to be dynamically built
14 for each kernel on your system in a simplified and organized fashion.
15
17 add [module/module-version | /path/to/source-tree |
18 /path/to/tarball.tar]
19 Adds a module/module-version combination to the tree for builds and
21 installs. If module/module-version, -m module/module-version, or
22 -m module -v module-version are passed as options, this command re‐
23 quires source in /usr/src/<module>-<module-version>/ as well as a
24 properly formatted dkms.conf file. If /path/to/source-tree is
25 passed as an option, and source-tree contains a dkms.conf file, it
26 will copy /path/to/source-tree to /usr/src/module-module-version.
27 If /path/to/tarball.tar is passed, this command behaves like the
28 ldtarball command.
29 remove [module/module-version] [-k kernel/arch] [--all]
31 Removes a module/version or module/version/kernel/arch combination
33 from the tree. If the module is currently installed, it first unin‐
34 stalls it and if applicable, will replace it with its original_mod‐
35 ule. Use the --all option in order to remove all instances for ev‐
36 ery kernel at once.
37 build [module/module-version] [-k kernel/arch] [--force]
39 Builds the specified module/version combo for the specified ker‐
41 nel/arch. If the -k option is not specified it builds for the cur‐
42 rently running kernel and arch. All builds occur in the directory
43 /var/lib/dkms/<module>/<module-version>/build/. If the module/mod‐
44 ule-version combo has not been added, dkms will try to add it, and
45 in that case build can take the same arguments that add can. If
46 the module is already built, it will not be rebuilt again by de‐
47 fault, and the --force option should be used to override this.
48 unbuild [module/module-version] [-k kernel/arch] [--all]
50 Undoes the build for a module/version or module/version/kernel/arch
52 combination from the tree. If the module is currently installed, it
53 first uninstalls it and if applicable, will replace it with its
54 original_module. Finally all binary kernel modules are removed. Use
55 the --all option in order to remove all instances for every kernel
56 at once.
57 install [module/module-version] [-k kernel/arch] [--force]
59 [/path/to/driver.rpm]
60 Installs a built module/version combo onto the kernel it was built
62 for. If the kernel option is not specified it assumes the currently
63 running kernel. If the module has not been built, dkms will try to
64 build it. If the module has not been added, dkms will try to add
65 it. In both cases, the install command can then take the same argu‐
66 ments as the build or add commands. If the module is already in‐
67 stalled, it will not be reinstalled again by default, and the
68 --force option should be used to override this. If you pass a .rpm
69 file, dkms will try to install that file with rpm -Uvh, and it will
70 perform an autoinstall action to be sure that everything is built
71 for your kernel if the RPM installed successfully.
72 uninstall [module/module-version] [-k kernel/arch] [--all]
74 Uninstalls an installed module/module-version combo from the ker‐
76 nel/arch passed in the -k option, or the current kernel if the -k
77 option was not passed. Use the --all option in order to uninstall
78 all instances for every kernel at once. After uninstall comple‐
79 tion, the driver will be left in the built state. To completely
80 remove a driver, the remove action should be utilized.
81 match [--templatekernel kernel/arch] [-k kernel/arch]
83 Match installs modules onto the specified kernel by looking at the
85 configuration of the specified templatekernel. Every module that
86 is installed on the templatekernel within dkms is then installed on
87 that specified kernel.
88 mktarball [module/module-version] [-k kernel/arch]
90 [--archive /path/to/tarball.tar] [--source-only] [--binaries-
91 only]
92 Creates a tarball archive for the specified module/version of all
94 files in the DKMS tree for that module/version combination. This
95 includes the source and any built modules for kernels in the tree
96 (as specified). Otherwise, you can specify a singular kernel to
97 archive only, or multiple kernels to archive (-k kernel1/arch1 -k
98 kernel2/arch2). Optionally, you can use --archive to specify the
99 file that you would like to save this tarball to. You can also
100 specify --binaries-only if you want the resultant tarball not to
101 include the module source. Likewise, --source-only can be used to
102 specify that no prebuilt binaries should be included in the tar‐
103 ball. In general, mktarball is great for systems management pur‐
104 poses as you can build your driver on just one system and then use
105 ldtarball on all of your other systems to get the same built mod‐
106 ules loaded without having to wait for anything to compile.
107 ldtarball [/path/to/tarball.tar] [--force]
109 This takes a tarball made from the mktarball command and loads it
111 into your DKMS tree. This will leave any newly added modules in the
112 built state and dkms install should then be called to install any
113 of them. If files already exist where ldtarball is attempting to
114 place them, it will warn and not copy over them. The --force option
115 should be used to override this.
116 status [module/module-version] [-k kernel/arch]
118 Returns the current status of modules, versions and kernels within
120 the tree as well as whether they have been added, built or in‐
121 stalled. Status can be shown for just a certain module, a certain
122 kernel, a module/version combination or a module/version/kernel
123 combination.
124 autoinstall
126 Attempt to install the latest revision of all modules that have
128 been installed for other kernel revisions. dkms_autoinstaller is a
129 stub that uses this action to perform its work.
130
132 -m <module>/<module-version>
133 The name of the module and module version you want to operate
134 on. The -m part of this option is optional, and can be omitted
135 in virtually all circumstances.
136 -v <module-version>
138 The version of the module to execute the specified action upon.
139 This option only has to be specified if you pass a -m option
140 without a <module-version> component of its own.
141 -k <kernel-version>/<arch>
143 The kernel and arch to perform the action upon. You can specify
144 multiple kernel version/arch pairs on the command line by re‐
145 peating the -k argument with a different kernel version and
146 arch. However, not all actions support multiple kernel versions
147 (it will error out in this case). The arch part can be omitted,
148 and DKMS will assume you want it to be the arch of the currently
149 running system.
150 -a, --arch
152 The system architecture to perform the action upon. It is op‐
153 tional if you pass it as part of the -k option. If not speci‐
154 fied, it assumes the arch of the currently running system (`un‐
155 ame -m`). You can specify multiple arch parameters on the same
156 command line by repeating the -a argument with a different arch
157 name. When multiple architectures are specified, there must be a
158 1:1 relationship between -k arguments to -a arguments. DKMS will
159 then assume the first -a argument aligns with the first -k ker‐
160 nel and so on for the second, third, etc.
161 For example, if you were to specify: -k kernel1 -k kernel2 -a
163 i386 -k kernel3 -a i686 -a x86_64, DKMS would process this as:
164 kernel1-i386, kernel2-i686, kernel3-x86_64.
165 -q, --quiet
167 Quiet.
168 -V, --version
170 Prints the currently installed version of dkms and exits.
171 -c <dkms.conf-location>
173 The location of the dkms.conf file. This is needed for the add
174 action and if not specified, it is assumed to be located in
175 /usr/src/<module>-<module-version>/. See below for more infor‐
176 mation on the format of dkms.conf.
177 --config <kernel-.config-location>
179 During a build this option is used to specify an alternate loca‐
180 tion for the kernel .config file which was used to compile that
181 kernel. Normally, dkms uses the Red Hat standard location and
182 config filenames located in /usr/src/linux-<kernel>/configs/.
183 If the config for the kernel that you are building a module for
184 is not located here or does not have the expected name in this
185 location, you will need to tell dkms where the necessary .config
186 can be found so that your kernel can be properly prepared for
187 the module build.
188 --archive <tarball-location>
190 This option is used during a ldtarball action to specify the lo‐
191 cation of the tarball you wish to load into your DKMS tree. You
192 only have to specify the --archive part of this option if <tar‐
193 ball-location> does not already exist as a file.
194 --templatekernel <kernel-version>
196 This option is required for the action: match. Match will look
197 at the templatekernel specified and install all of the same mod‐
198 ule/version combinations on the other kernel.
199 --force
201 This option can be used in conjunction with ldtarball to force
202 copying over of extant files.
203 --binaries-only
205 This option can be used in conjunction with mktarball in order
206 to create a DKMS tarball which does not contain the source for
207 the module within it. This can be helpful in reducing the size
208 of the tarball if you know that the system which this tarball
209 will be loaded upon already has the source installed. In order
210 to load a tarball made as binaries-only you must have the module
211 source in that systems DKMS tree. If you do not, DKMS will
212 refuse to load a binaries-only tarball.
213 --source-only
215 This option can be used in conjunction with mktarball but do not
216 want the tarball you create to have any prebuilt modules within
217 it, passing this option will keep its internal DKMS tarball from
218 containing any prebuilt modules.
219 --all This option can be used to automatically specify all relevant
221 kernels/arches for a module/module-version. This can be used for
222 things like remove, unbuild and uninstall. This saves the trou‐
223 ble of having to actually specify -k kernel1 -a arch1 -k kernel2
224 -a arch2 for every kernel you have built your module for.
225 --no-depmod
227 This option prevents DKMS from running the depmod command during
228 install and uninstall which will avoid (re)calculating module
229 dependencies and thereby save time.
230 --modprobe-on-install
232 This option executes modprobe on the modules upon successful in‐
233 stallation.
234 --kernelsourcedir <kernel-source-directory-location>
236 Using this option you can specify the location of your kernel
237 source directory. Most likely you will not need to set this if
238 your kernel source is accessible via /lib/modules/$kernel_ver‐
239 sion/build.
240 --directive <"cli-directive=cli-value">
242 Using this option, you can specify additional directives from
243 the command line. The --directive option can be used multiple
244 times on the same command-line to specify multiple additional
245 command line directives.
246 --rpm_safe_upgrade
248 This flag should be used when packaging DKMS enabled modules in
249 RPMs. It should be specified during both the add and remove ac‐
250 tions in the RPM spec to ensure that DKMS and RPM behave cor‐
251 rectly in all scenarios when upgrading between various versions
252 of a dkms enabled module RPM package.
253 --dkmstree path/to/place
255 Provides a destination tree for building and installing modules
256 to. Useful in cases that you don't want to contaminate a system
257 when using solely for building.
258 --sourcetree path/to/place
260 Provides a location to build a DKMS package from. Useful for
261 systems that you may not have root access, but would still like
262 to be able to build DKMS packages.
263 --installtree path/to/place
265 Provides a location to place modules when a dkms install command
266 is issued.
267 -j number
269 Run no more than number jobs in parallel; see the -j option of
270 make(1). Defaults to the number of CPUs in the system, detected
271 by nproc(1). Specify 0 to impose no limit on the number of par‐
272 allel jobs.
273
275 During the first install of a module for a <kernelversion>, dkms will
276 search /lib/modules/<kernelversion> for a pre-existing module of the
277 same name. If one is found, it will automatically be saved as an "orig‐
278 inal_module" so that if the newer module is later removed, dkms will
279 put the original module back in its place. Currently, DKMS searches for
280 these original modules with first preference going to modules located
281 in /lib/modules/<kernelversion>/updates/ followed by $DEST_MODULE_LOCA‐
282 TION (as specified in dkms.conf ). If one cannot be found in either lo‐
283 cation, a find will be used to locate one for that kernel. If none are
284 found, then during a later uninstall, your kernel will not have that
285 module replaced.
286 If more than one is found, then the first one located (by preference
288 indicated above) will be considered the "original_module". As well, all
289 copies of the same-named module will be removed from your kernel tree
290 and placed into /var/lib/dkms/<module>/original_module/$kernelver/col‐
291 lisions so that they can be *manually* accessible later. DKMS will
292 never actually do anything with the modules found underneath the /col‐
293 lisions directory, and they will be stored there until you manually
294 delete them.
295
297 When performing an add, a proper dkms.conf file must be found. A prop‐
298 erly formatted conf file is essential for communicating to dkms how and
299 where the module should be installed. While not all the directives are
300 required, providing as many as possible helps to limit any ambiguity.
301 Note that the dkms.conf is really only a shell-script of variable defi‐
302 nitions which are then sourced in by the dkms executable (of the for‐
303 mat, DIRECTIVE="directive text goes here"). As well, the directives are
304 case-sensitive and should be given in ALL CAPS.
305 It is important to understand that many of the DKMS directives are ar‐
307 rays whose index values are tied together. These array associations can
308 be considered families, and there are currently three such families of
309 directive arrays. MAKE[#] and MAKE_MATCH[#] make up one family.
310 PATCH[#] and PATCH_MATCH[#] make up the second family. The third and
311 largest family consists of BUILT_MODULE_NAME[#], BUILT_MODULE_LOCA‐
312 TION[#], DEST_MODULE_NAME[#], DEST_MODULE_LOCATION[#] and STRIP[#].
313 When indexing these arrays when creating your dkms.conf, each family
314 should start at index value 0.
315 PACKAGE_NAME=
317 This directive is used to give the name associated with the en‐
318 tire package of modules. This is the same name that is used with
319 the -m option when building, adding, etc. and may not necessar‐
320 ily be the same as the MODULE_NAME. This directive must be
321 present in every dkms.conf.
322 PACKAGE_VERSION=
324 This directive is used to give the version associated with the
325 entire package of modules being installed within that dkms pack‐
326 age. This directive must be present in every dkms.conf.
327 BUILT_MODULE_NAME[#]=
329 This directive gives the name of the module just after it is
330 built. If your DKMS module package contains more than one module
331 to install, this is a required directive for all of the modules.
332 This directive should explicitly not contain any trailing ".o"
333 or ".ko". Note that for each module within a dkms package, the
334 numeric value of # must be the same for each of BUILT_MOD‐
335 ULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MOD‐
336 ULE_LOCATION and that the numbering should start at 0 (eg.
337 BUILT_MODULE_NAME[0]="qla2200" BUILT_MODULE_NAME[1]="qla2300").
338 BUILT_MODULE_LOCATION[#]=
340 This directive tells DKMS where to find your built module after
341 it has been built. This pathname should be given relative to the
342 root directory of your source files (where your dkms.conf file
343 can be found). If unset, DKMS expects to find your BUILT_MOD‐
344 ULE_NAME[#] in the root directory of your source files. Note
345 that for each module within a dkms package, the numeric value of
346 # must be the same for each of BUILT_MODULE_NAME, BUILT_MOD‐
347 ULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that
348 the numbering should start at 0 (eg. BUILT_MODULE_LOCA‐
349 TION[0]="some/dir/" BUILT_MODULE_LOCATION[1]="other/dir/").
350 DEST_MODULE_NAME[#]=
352 This directive can be used to specify the name of the module as
353 it should be installed. This will rename the module from
354 BUILT_MODULE_NAME[#] to DEST_MODULE_NAME[#]. This directive
355 should explicitly not contain any trailing ".o" or ".ko". If un‐
356 set, it is assumed to be the same value as BUILT_MODULE_NAME[#].
357 Note that for each module within a dkms package, the numeric
358 value of # must be the same for each of BUILT_MODULE_NAME,
359 BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION
360 and that the numbering should start at 0 (eg. DEST_MOD‐
361 ULE_NAME[0]="qla2200_6x" DEST_MODULE_NAME[1]="qla2300_6x").
362 DEST_MODULE_LOCATION[#]=
364 This directive specifies the destination where a module should
365 be installed to, once compiled. It also is used for finding
366 original_modules. This is a required directive, except as noted
367 below. This directive must start with the text "/kernel" which
368 is in reference to /lib/modules/<kernelversion>/kernel. Note
369 that for each module within a dkms package, the numeric value of
370 # must be the same for each of BUILT_MODULE_NAME, BUILT_MOD‐
371 ULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that
372 the numbering should start at 0 (eg. DEST_MODULE_LOCA‐
373 TION[0]="/kernel/drivers/something/" DEST_MODULE_LOCA‐
374 TION[1]="/kernel/drivers/other/").
375 DEST_MODULE_LOCATION is ignored on Fedora and Red Hat Enterprise
377 Linux, Novell SuSE Linux Enterprise Server 10 and higher, Novell
378 SuSE Linux 10.0 and higher, and Ubuntu. Instead, the proper dis‐
379 tribution-specific directory is used.
380 STRIP[#]=
382 By default strip is considered to be "yes". If set to "no", DKMS
383 will not run strip -g against your built module to remove debug
384 symbols from it. STRIP[0] is used as the default for any unset
385 entries in the STRIP array.
386 MAKE[#]=
388 The MAKE directive array tells DKMS which make command should be
389 used for building your module. The default make command should
390 be put into MAKE[0]. Other entries in the MAKE array will only
391 be used if their corresponding entry in MAKE_MATCH[#] matches,
392 as a regular expression (using grep -E), the kernel that the
393 module is being built for. Note that if no value is placed in
394 MAKE_MATCH[#] for any MAKE[#] where # > 0, then that MAKE direc‐
395 tive is ignored. MAKE_MATCH[0] is optional and if it is popu‐
396 lated, it will be used to determine if MAKE[0] should be used to
397 build the module for that kernel. If multiple MAKE_MATCH direc‐
398 tives match against the kernel being built for, the last match‐
399 ing MAKE[#] will be used to build your module. If no MAKE direc‐
400 tive is specified or if no MAKE_MATCH matches the kernel being
401 built for, DKMS will attempt to use a generic MAKE command to
402 build your module.
403 KERNELRELEASE will be automatically appended to MAKE[#]. If you
405 want to suppress this behavior, you can quote the make command:
406 'make'.
407 MAKE_MATCH[#]=
409 See the above entry on MAKE[#] directives. This array should be
410 populated with regular expressions which, when matched against
411 the kernel being built for, will tell DKMS to use the corre‐
412 sponding make command in the MAKE[#] directive array to build
413 your module.
414 CLEAN= CLEAN specifies the make clean command to be used to clean up
416 both before and after building the module. If unset, it is as‐
417 sumed to be "make clean".
418 NO_WEAK_MODULES=
420 The NO_WEAK_MODULES parameter prevents dkms from creating a sym‐
421 link into the weak-updates directory, which is the default on
422 Red Hat derivatives. The weak modules facility was designed to
423 eliminate the need to rebuild kernel modules when kernel up‐
424 grades occur and relies on the symbols within the kABI.
425 Fedora does not guaranteed a stable kABI so it should be dis‐
427 abled in the specific module override by setting it to "yes".
428 For example, for an Nvidia DKMS module you would set the follow‐
429 ing in /etc/dkms/nvidia.conf:
430 NO_WEAK_MODULES="yes"
432 OBSOLETE_BY=
434 This directive allows you to specify a kernel version that obso‐
435 letes the necessity for this particular DKMS module. This can be
436 specified as a particular upstream kernel or an ABI bump of a
437 kernel. For example, "2.6.24" would be an upstream kernel and
438 "2.6.24-16" would represent an ABI bump for a kernel. Both are
439 valid in this area.
440 Please avoid the use of OBSOLETE_BY wherever possible. It's use
442 indicates a lack of proper module versioning using MODULE_VER‐
443 SION() tags in the module source itself. It is better to fix the
444 MODULE_VERSION() tags than use OBSOLETE_BY. This also intro‐
445 duces a implicit distribution/version dependency on the package,
446 as the value of OBSOLETE_BY is meaningful only in the context of
447 a single distribution/version.
448 PATCH[#]=
450 Use the PATCH directive array to specify patches which should be
451 applied to your source before a build occurs. All patches are
452 expected to be in -p1 format and are applied with the patch -p1
453 command. Each directive should specify the filename of the
454 patch to apply, and all patches must be located in the patches
455 subdirectory of your source directory ( /usr/src/<module>-<mod‐
456 ule-version>/patches/ ). If any patch fails to apply, the build
457 will be halted and the rejections can be inspected in
458 /var/lib/dkms/<module>/<module-version>/build/. If a PATCH
459 should only be applied conditionally, the PATCH_MATCH[#] array
460 should be used, and a corresponding regular expression should be
461 placed in PATCH_MATCH[#] which will alert dkms to only use that
462 PATCH[#] if the regular expression matches the kernel which the
463 module is currently being built for.
464 PATCH_MATCH[#]=
466 See the above description for PATCH[#] directives. If you only
467 want a patch applied in certain scenarios, the PATCH_MATCH array
468 should be utilized by giving a regular expression which matches
469 the kernels you intend the corresponding PATCH[#] to be applied
470 to before building that module.
471 AUTOINSTALL=
473 If this directive is set to yes then the service
474 /etc/rc.d/init.d/dkms_autoinstaller will automatically try to
475 install this module on any kernel you boot into. See the section
476 on dkms_autoinstaller for more information.
477 BUILD_DEPENDS[#]=
479 This optional directive is an array that allows you to specify
480 other modules as dependencies for your module. Each array ele‐
481 ment should be the PACKAGE_NAME of another module that is man‐
482 aged by dkms. Do not specify a version or architecture in the
483 dependency. Note that this directive is only advisory; missing
484 or broken dependencies cause non-fatal warnings.
485 BUILD_EXCLUSIVE_KERNEL=
487 This optional directive allows you to specify a regular expres‐
488 sion which defines the subset of kernels which DKMS is allowed
489 to build your module for. If the kernel being built for does
490 not match against this regular expression (or does not the sat‐
491 isfy the constraints of any other BUILD_EXCLUSIVE_* directive),
492 the dkms build will error out with exit code 77. Note that dkms
493 autoinstall will ignore this type of error condition and simply
494 skip the respective modules. For example, if you set it as
495 ="^2.4.*", your module would not be built for 2.6 or later ker‐
496 nels.
497 BUILD_EXCLUSIVE_KERNEL_MIN=
499 and BUILD_EXCLUSIVE_KERNEL_MAX= These optional directives allow
500 one to specify the minimal and maximal kernel versions supported
501 by the module. If one (or both) of these are defined, the module
502 will not be built for kernels outside the specified version lim‐
503 its. For example, if you set BUILD_EXCLUSIVE_KERNEL_MIN as
504 "=3.5", your module would be built for e.g. "3.5-rc2", "3.6.18"
505 or other later versions but not for "3.4.999" or earlier ker‐
506 nels. Similarly, if you set BUILD_EXCLUSIVE_KERNEL_MAX as
507 ="4.12", your module would be built for e.g. "4.11.999",
508 "3.9-rc5" or other earlier versions, but not for "4.12-rc1" or
509 later kernels.
510 BUILD_EXCLUSIVE_ARCH=
512 This optional directive functions very similarly to BUILD_EXCLU‐
513 SIVE_KERNEL except that it matches against the kernel architec‐
514 ture. For example, if you set it to ="i.86", your module would
515 not be built for ia32e, x86_64, amd64, s390, etc.
516 BUILD_EXCLUSIVE_CONFIG=
518 This optional directive allows you to specify a space separated
519 list of kernel configuration options ("CONFIG_FOO") that must be
520 enabled in the targeted kernels ".config" file (either to be
521 compiled in or to be built as a module) or absent (if prefixed
522 with an exclamation mark, e.g. "!CONFIG_BAR") in order to build
523 the module. For example, if you set it as ="CONFIG_PCI !CON‐
524 FIG_PREEMPT_RT", your module would only be built for kernels
525 that have PCI enabled, but the RT patchset disabled.
526 POST_ADD=
528 The name of the script to be run after an add is performed. The
529 path should be given relative to the root directory of your
530 source.
531 POST_BUILD=
533 The name of the script to be run after a build is performed. The
534 path should be given relative to the root directory of your
535 source.
536 POST_INSTALL=
538 The name of the script to be run after an install is performed.
539 The path should be given relative to the root directory of your
540 source.
541 POST_REMOVE=
543 The name of the script to be run after a remove is performed.
544 The path should be given relative to the root directory of your
545 source.
546 PRE_BUILD=
548 The name of the script to be run before a build is performed.
549 The path should be given relative to the root directory of your
550 source.
551 PRE_INSTALL=
553 The name of the script to be run before an install is performed.
554 The path should be given relative to the root directory of your
555 source. If the script exits with a non-zero value, the install
556 will be aborted. This is typically used to perform a custom ver‐
557 sion comparison.
558 DKMS.CONF VARIABLES
561 Within your dkms.conf file, you can use certain variables which
562 will be replaced at run-time with their values.
563 $kernelver
565 This variable can be used within a directive definition and dur‐
566 ing use, the actual kernel version in question will be substi‐
567 tuted in its place. This is especially useful in MAKE commands
568 when specifying which INCLUDE statements should be used when
569 compiling your module (eg. MAKE="make all INCLUDEDIR=/lib/mod‐
570 ules/${kernelver}/build/include").
571 $kernel_source_dir
573 This variable holds the value of the location of your kernel
574 source directory. Usually, this will be /lib/modules/$ker‐
575 nelver/build, unless otherwise specified with the --kernel‐
576 sourcedir option.
577
579 You can override the module-provided dkms.conf files. Every time after
580 a dkms.conf file is read, dkms will look for and read the following
581 files in order:
582 /etc/dkms/<module>.conf
584 /etc/dkms/<module>-<module-version>.conf
585 /etc/dkms/<module>-<module-version>-<kernel>.conf
586 /etc/dkms/<module>-<module-version>-<kernel>-<arch>.conf
587 You can use these files to override settings in the module-provided
589 dkms.conf files.
590
592 This configuration file controls how the overall DKMS framework han‐
593 dles. It is sourced in every time the dkms command is run. Mainly it
594 can currently be used to set different default values for the vari‐
595 ables.
596 The file contains descriptions for each directive it supports.
598 Additionally to /etc/dkms/framework.conf, any file matching the glob
600 /etc/dkms/framework.conf.d/*.conf will be loaded as well.
601 $dkms_tree, $source_tree, $install_tree, $tmp_location
603 Control which folders DKMS uses for components and artifacts.
604 $verbose
606 Can be set to anything but a null value to enable verbose output
607 in DKMS.
608 $symlink_modules
610 Controls whether binary modules are copied to /lib/modules or if
611 only symlinks are created there. Note that these variables can
612 also be manipulated on the command line with --dkmstree,
613 --sourcetree, --installtree and --symlink-modules options.
614 $autoinstall_all_kernels
616 Used by the common postinst for DKMS modules. It controls if the
617 build should be done for all installed kernels or only for the
618 current and latest installed kernel. It has no command line
619 equivalent.
620 $sign_file
622 This is the path of the sign-file kernel binary that is used to
623 sign the kernel modules. The variable $kernelver can be used in
624 path to represent the target kernel version. The path for the
625 binary depends on the distribution.
626 $mok_signing_key, $mok_certificate
628 Location of the key and certificate files used for Secure boot.
629 The variable $kernelver can be used in path to represent the
630 target kernel version. mok_signing_key can also be a
631 "pkcs11:..." string for PKCS#11 engine, as long as the sign_file
632 program supports it.
633 $modprobe_on_install
635 Automatically load the built modules upon successful installa‐
636 tion.
637
639 This boot-time service automatically installs any module which has AU‐
640 TOINSTALL="yes" set in its dkms.conf file. The service works quite sim‐
641 ply and if multiple versions of a module are in your system's DKMS
642 tree, it will not do anything and instead explain that manual interven‐
643 tion is required.
644
646 Gary Lerhaupt, Emil Velikov, Simone Caronni, Xu Zhen
647
649 https://github.com/dell/dkms
650dkms-3.0.12 24 September 2023 DKMS(8)