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 version are passed as options, this command requires
23 source in /usr/src/<module>-<module-version>/ as well as a properly
24 formatted dkms.conf file. If /path/to/source-tree is passed as an
25 option, and source-tree contains a dkms.conf file, it will copy
26 /path/to/source-tree to /usr/src/module-module-version. If
27 /path/to/tarball.tar is passed, this command behaves like the ld‐
28 tarball 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]
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.
46 unbuild [module/module-version] [-k kernel/arch] [--all]
48 Undoes the build for a module/version or module/version/kernel/arch
50 combination from the tree. If the module is currently installed, it
51 first uninstalls it and if applicable, will replace it with its
52 original_module. Finally all binary kernel modules are removed. Use
53 the --all option in order to remove all instances for every kernel
54 at once.
55 install [module/module-version] [-k kernel/arch] [/path/to/driver.rpm]
57 Installs a built module/version combo onto the kernel it was built
59 for. If the kernel option is not specified it assumes the currently
60 running kernel. If the module has not been built, dkms will try to
61 build it. If the module has not been added, dkms will try to add
62 it. In both cases, the install command can then take the same argu‐
63 ments as the build or add commands. If you pass a .rpm file, dkms
64 will try to install that file with rpm -Uvh , and it will perform
65 an autoinstall action to be sure that everything is built for your
66 kernel if the RPM installed successfully.
67 uninstall [module/module-version] [-k kernel/arch] [--all]
69 Uninstalls an installed module/module-version combo from the ker‐
71 nel/arch passed in the -k option, or the current kernel if the -k
72 option was not passed. Use the --all option in order to uninstall
73 all instances for every kernel at once. After uninstall comple‐
74 tion, the driver will be left in the built state. To completely
75 remove a driver, the remove action should be utilized.
76 match [--templatekernel kernel/arch] [-k kernel/arch]
78 Match installs modules onto the specified kernel by looking at the
80 configuration of the specified templatekernel. Every module that
81 is installed on the templatekernel within dkms is then installed on
82 that specified kernel.
83 mktarball [module/module-version] [-k kernel/arch]
85 [--archive /path/to/tarball.tar] [--source-only] [--binaries-
86 only]
87 Creates a tarball archive for the specified module/version of all
89 files in the DKMS tree for that module/version combination. This
90 includes the source and any built modules for kernels in the tree
91 (as specified). Otherwise, you can specify a singular kernel to
92 archive only, or multiple kernels to archive (-k kernel1/arch1 -k
93 kernel2/arch2). Optionally, you can use --archive to specify the
94 file that you would like to save this tarball to. You can also
95 specify --binaries-only if you want the resultant tarball not to
96 include the module source. Likewise, --source-only can be used to
97 specify that no prebuilt binaries should be included in the tar‐
98 ball. In general, mktarball is great for systems management pur‐
99 poses as you can build your driver on just one system and then use
100 ldtarball on all of your other systems to get the same built mod‐
101 ules loaded without having to wait for anything to compile.
102 ldtarball [/path/to/tarball.tar] [--force]
104 This takes a tarball made from the mktarball command and loads it
106 into your DKMS tree. This will leave any newly added modules in the
107 built state and dkms install should then be called to install any
108 of them. If files already exist where ldtarball is attempting to
109 place them, it will warn and not copy over them. The --force option
110 should be used to override this.
111 status [module/module-version] [-k kernel/arch]
113 Returns the current status of modules, versions and kernels within
115 the tree as well as whether they have been added, built or in‐
116 stalled. Status can be shown for just a certain module, a certain
117 kernel, a module/version combination or a module/version/kernel
118 combination.
119 autoinstall
121 Attempt to install the latest revision of all modules that have
123 been installed for other kernel revisions. dkms_autoinstaller is a
124 stub that uses this action to perform its work.
125
127 -m <module>/<module-version>
128 The name of the module and module version you want to operate
129 on. The -m part of this option is optional, and can be omitted
130 in virtually all circumstances.
131 -v <module-version>
133 The version of the module to execute the specified action upon.
134 This option only has to be specified if you pass a -m option
135 without a <module-version> component of its own.
136 -k <kernel-version>/<arch>
138 The kernel and arch to perform the action upon. You can specify
139 multiple kernel version/arch pairs on the command line by re‐
140 peating the -k argument with a different kernel version and
141 arch. However, not all actions support multiple kernel versions
142 (it will error out in this case). The arch part can be omitted,
143 and DKMS will assume you want it to be the arch of the currently
144 running system.
145 -a, --arch
147 The system architecture to perform the action upon. It is op‐
148 tional if you pass it as part of the -k option. If not speci‐
149 fied, it assumes the arch of the currently running system (`un‐
150 ame -m`). You can specify multiple arch parameters on the same
151 command line by repeating the -a argument with a different arch
152 name. When multiple architectures are specified, there must be a
153 1:1 relationship between -k arguments to -a arguments. DKMS will
154 then assume the first -a argument aligns with the first -k ker‐
155 nel and so on for the second, third, etc.
156 For example, if you were to specify: -k kernel1 -k kernel2 -a
158 i386 -k kernel3 -a i686 -a x86_64, DKMS would process this as:
159 kernel1-i386, kernel2-i686, kernel3-x86_64.
160 -q, --quiet
162 Quiet.
163 -V, --version
165 Prints the currently installed version of dkms and exits.
166 -c <dkms.conf-location>
168 The location of the dkms.conf file. This is needed for the add
169 action and if not specified, it is assumed to be located in
170 /usr/src/<module>-<module-version>/. See below for more infor‐
171 mation on the format of dkms.conf.
172 --config <kernel-.config-location>
174 During a build this option is used to specify an alternate loca‐
175 tion for the kernel .config file which was used to compile that
176 kernel. Normally, dkms uses the Red Hat standard location and
177 config filenames located in /usr/src/linux-<kernel>/configs/.
178 If the config for the kernel that you are building a module for
179 is not located here or does not have the expected name in this
180 location, you will need to tell dkms where the necessary .config
181 can be found so that your kernel can be properly prepared for
182 the module build.
183 --archive <tarball-location>
185 This option is used during a ldtarball action to specify the lo‐
186 cation of the tarball you wish to load into your DKMS tree. You
187 only have to specify the --archive part of this option if <tar‐
188 ball-location> does not already exist as a file.
189 --templatekernel <kernel-version>
191 This option is required for the action: match. Match will look
192 at the templatekernel specified and install all of the same mod‐
193 ule/version combinations on the other kernel.
194 --force
196 This option can be used in conjunction with ldtarball to force
197 copying over of extant files.
198 --binaries-only
200 This option can be used in conjunction with mktarball in order
201 to create a DKMS tarball which does not contain the source for
202 the module within it. This can be helpful in reducing the size
203 of the tarball if you know that the system which this tarball
204 will be loaded upon already has the source installed. In order
205 to load a tarball made as binaries-only you must have the module
206 source in that systems DKMS tree. If you do not, DKMS will
207 refuse to load a binaries-only tarball.
208 --source-only
210 This option can be used in conjunction with mktarball but do not
211 want the tarball you create to have any prebuilt modules within
212 it, passing this option will keep its internal DKMS tarball from
213 containing any prebuilt modules.
214 --all This option can be used to automatically specify all relevant
216 kernels/arches for a module/module-version. This can be used for
217 things like remove, unbuild and uninstall. This saves the trou‐
218 ble of having to actually specify -k kernel1 -a arch1 -k kernel2
219 -a arch2 for every kernel you have built your module for.
220 --no-depmod
222 This option prevents DKMS from running the depmod command during
223 install and uninstall which will avoid (re)calculating module
224 dependencies and thereby save time.
225 --modprobe-on-install
227 This option executes modprobe on the modules upon successful in‐
228 stallation.
229 --kernelsourcedir <kernel-source-directory-location>
231 Using this option you can specify the location of your kernel
232 source directory. Most likely you will not need to set this if
233 your kernel source is accessible via /lib/modules/$kernel_ver‐
234 sion/build.
235 --directive <"cli-directive=cli-value">
237 Using this option, you can specify additional directives from
238 the command line. The --directive option can be used multiple
239 times on the same command-line to specify multiple additional
240 command line directives.
241 --rpm_safe_upgrade
243 This flag should be used when packaging DKMS enabled modules in
244 RPMs. It should be specified during both the add and remove ac‐
245 tions in the RPM spec to ensure that DKMS and RPM behave cor‐
246 rectly in all scenarios when upgrading between various versions
247 of a dkms enabled module RPM package.
248 --dkmstree path/to/place
250 Provides a destination tree for building and installing modules
251 to. Useful in cases that you don't want to contaminate a system
252 when using solely for building.
253 --sourcetree path/to/place
255 Provides a location to build a DKMS package from. Useful for
256 systems that you may not have root access, but would still like
257 to be able to build DKMS packages.
258 --installtree path/to/place
260 Provides a location to place modules when a dkms install command
261 is issued.
262 --dkmsframework path/to/file
264 A supplemental configuration file to the system-wide dkms frame‐
265 work, typically located in /etc/dkms/framework.conf. All option
266 that are normally provided on a command line can be provided in
267 this file.
268 -j number
270 Run no more than number jobs in parallel; see the -j option of
271 make(1). Defaults to the number of CPUs in the system, detected
272 by nproc(1). Specify 0 to impose no limit on the number of par‐
273 allel jobs.
274
276 During the first install of a module for a <kernelversion>, dkms will
277 search /lib/modules/<kernelversion> for a pre-existing module of the
278 same name. If one is found, it will automatically be saved as an "orig‐
279 inal_module" so that if the newer module is later removed, dkms will
280 put the original module back in its place. Currently, DKMS searches for
281 these original modules with first preference going to modules located
282 in /lib/modules/<kernelversion>/updates/ followed by $DEST_MODULE_LOCA‐
283 TION (as specified in dkms.conf ). If one cannot be found in either lo‐
284 cation, a find will be used to locate one for that kernel. If none are
285 found, then during a later uninstall, your kernel will not have that
286 module replaced.
287 If more than one is found, then the first one located (by preference
289 indicated above) will be considered the "original_module". As well, all
290 copies of the same-named module will be removed from your kernel tree
291 and placed into /var/lib/dkms/<module>/original_module/$kernelver/col‐
292 lisions so that they can be *manually* accessible later. DKMS will
293 never actually do anything with the modules found underneath the /col‐
294 lisions directory, and they will be stored there until you manually
295 delete them.
296
298 When performing an add , a proper dkms.conf file must be found. A prop‐
299 erly formatted conf file is essential for communicating to dkms how and
300 where the module should be installed. While not all the directives are
301 required, providing as many as possible helps to limit any ambiguity.
302 Note that the dkms.conf is really only a shell-script of variable defi‐
303 nitions which are then sourced in by the dkms executable (of the for‐
304 mat, DIRECTIVE="directive text goes here"). As well, the directives are
305 case-sensitive and should be given in ALL CAPS.
306 It is important to understand that many of the DKMS directives are ar‐
308 rays whose index values are tied together. These array associations can
309 be considered families, and there are currently three such families of
310 directive arrays. MAKE[#] and MAKE_MATCH[#] make up one family.
311 PATCH[#] and PATCH_MATCH[#] make up the second family. The third and
312 largest family consists of BUILT_MODULE_NAME[#], BUILT_MODULE_LOCA‐
313 TION[#], DEST_MODULE_NAME[#], DEST_MODULE_LOCATION[#] and STRIP[#].
314 When indexing these arrays when creating your dkms.conf, each family
315 should start at index value 0.
316 MAKE[#]=
318 The MAKE directive array tells DKMS which make command should be
319 used for building your module. The default make command should
320 be put into MAKE[0]. Other entries in the MAKE array will only
321 be used if their corresponding entry in MAKE_MATCH[#] matches,
322 as a regular expression (using egrep), the kernel that the mod‐
323 ule is being built for. Note that if no value is placed in
324 MAKE_MATCH[#] for any MAKE[#] where # > 0, then that MAKE direc‐
325 tive is ignored. MAKE_MATCH[0] is optional and if it is popu‐
326 lated, it will be used to determine if MAKE[0] should be used to
327 build the module for that kernel. If multiple MAKE_MATCH direc‐
328 tives match against the kernel being built for, the last match‐
329 ing MAKE[#] will be used to build your module. If no MAKE direc‐
330 tive is specified or if no MAKE_MATCH matches the kernel being
331 built for, DKMS will attempt to use a generic MAKE command to
332 build your module.
333 KERNELRELEASE will be automatically appended to MAKE[#]. If you
335 want to suppress this behavior, you can quote the make command:
336 'make'.
337 MAKE_MATCH[#]=
339 See the above entry on MAKE[#] directives. This array should be
340 populated with regular expressions which, when matched against
341 the kernel being built for, will tell DKMS to use the corre‐
342 sponding make command in the MAKE[#] directive array to build
343 your module.
344 BUILT_MODULE_NAME[#]=
346 This directive gives the name of the module just after it is
347 built. If your DKMS module package contains more than one module
348 to install, this is a required directive for all of the modules.
349 This directive should explicitly not contain any trailing ".o"
350 or ".ko". Note that for each module within a dkms package, the
351 numeric value of # must be the same for each of BUILT_MOD‐
352 ULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MOD‐
353 ULE_LOCATION and that the numbering should start at 0 (eg.
354 BUILT_MODULE_NAME[0]="qla2200" BUILT_MODULE_NAME[1]="qla2300").
355 BUILT_MODULE_LOCATION[#]=
357 This directive tells DKMS where to find your built module after
358 it has been built. This pathname should be given relative to the
359 root directory of your source files (where your dkms.conf file
360 can be found). If unset, DKMS expects to find your BUILT_MOD‐
361 ULE_NAME[#] in the root directory of your source files. Note
362 that for each module within a dkms package, the numeric value of
363 # must be the same for each of BUILT_MODULE_NAME, BUILT_MOD‐
364 ULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that
365 the numbering should start at 0 (eg. BUILT_MODULE_LOCA‐
366 TION[0]="some/dir/" BUILT_MODULE_LOCATION[1]="other/dir/").
367 DEST_MODULE_NAME[#]=
369 This directive can be used to specify the name of the module as
370 it should be installed. This will rename the module from
371 BUILT_MODULE_NAME[#] to DEST_MODULE_NAME[#]. This directive
372 should explicitly not contain any trailing ".o" or ".ko". If un‐
373 set, it is assumed to be the same value as BUILT_MODULE_NAME[#].
374 Note that for each module within a dkms package, the numeric
375 value of # must be the same for each of BUILT_MODULE_NAME,
376 BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION
377 and that the numbering should start at 0 (eg. DEST_MOD‐
378 ULE_NAME[0]="qla2200_6x" DEST_MODULE_NAME[1]="qla2300_6x").
379 DEST_MODULE_LOCATION[#]=
381 This directive specifies the destination where a module should
382 be installed to, once compiled. It also is used for finding
383 original_modules. This is a required directive, except as noted
384 below. This directive must start with the text "/kernel" which
385 is in reference to /lib/modules/<kernelversion>/kernel. Note
386 that for each module within a dkms package, the numeric value of
387 # must be the same for each of BUILT_MODULE_NAME, BUILT_MOD‐
388 ULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that
389 the numbering should start at 0 (eg. DEST_MODULE_LOCA‐
390 TION[0]="/kernel/drivers/something/" DEST_MODULE_LOCA‐
391 TION[1]="/kernel/drivers/other/").
392 DEST_MODULE_LOCATION is ignored on Fedora and Red Hat Enterprise
394 Linux, Novell SuSE Linux Enterprise Server 10 and higher, Novell
395 SuSE Linux 10.0 and higher, and Ubuntu. Instead, the proper dis‐
396 tribution-specific directory is used.
397 STRIP[#]=
399 By default strip is considered to be "yes". If set to "no", DKMS
400 will not run strip -g against your built module to remove debug
401 symbols from it. STRIP[0] is used as the default for any unset
402 entries in the STRIP array.
403 PACKAGE_NAME=
405 This directive is used to give the name associated with the en‐
406 tire package of modules. This is the same name that is used with
407 the -m option when building, adding, etc. and may not necessar‐
408 ily be the same as the MODULE_NAME. This directive must be
409 present in every dkms.conf.
410 PACKAGE_VERSION=
412 This directive is used to give the version associated with the
413 entire package of modules being installed within that dkms pack‐
414 age. This directive must be present in every dkms.conf.
415 CLEAN= CLEAN specifies the make clean command to be used to clean up
417 both before and after building the module. If unset, it is as‐
418 sumed to be "make clean".
419 OBSOLETE_BY=
421 This directive allows you to specify a kernel version that obso‐
422 letes the necessity for this particular DKMS module. This can be
423 specified as a particular upstream kernel or an ABI bump of a
424 kernel. For example, "2.6.24" would be an upstream kernel and
425 "2.6.24-16" would represent an ABI bump for a kernel. Both are
426 valid in this area.
427 Please avoid the use of OBSOLETE_BY wherever possible. It's use
429 indicates a lack of proper module versioning using MODULE_VER‐
430 SION() tags in the module source itself. It is better to fix the
431 MODULE_VERSION() tags than use OBSOLETE_BY. This also intro‐
432 duces a implicit distribution/version dependency on the package,
433 as the value of OBSOLETE_BY is meaningful only in the context of
434 a single distribution/version.
435 If you feel you must use it, please use as such in dkms.conf:
437 ubuntu_804="Ubuntu
439 8.04"
440 if [ -x /usr/bin/lsb_release ]; then
441 if [ "$(/usr/bin/lsb_release -sir)" == "${ubuntu_804}" ];
442 then
443 OBSOLETE_BY="2.6.25"
444 fi
445 fi
446 PATCH[#]=
449 Use the PATCH directive array to specify patches which should be
450 applied to your source before a build occurs. All patches are
451 expected to be in -p1 format and are applied with the patch -p1
452 command. Each directive should specify the filename of the
453 patch to apply, and all patches must be located in the patches
454 subdirectory of your source directory ( /usr/src/<module>-<mod‐
455 ule-version>/patches/ ). If any patch fails to apply, the build
456 will be halted and the rejections can be inspected in
457 /var/lib/dkms/<module>/<module-version>/build/. If a PATCH
458 should only be applied conditionally, the PATCH_MATCH[#] array
459 should be used, and a corresponding regular expression should be
460 placed in PATCH_MATCH[#] which will alert dkms to only use that
461 PATCH[#] if the regular expression matches the kernel which the
462 module is currently being built for.
463 PATCH_MATCH[#]=
465 See the above description for PATCH[#] directives. If you only
466 want a patch applied in certain scenarios, the PATCH_MATCH array
467 should be utilized by giving a regular expression which matches
468 the kernels you intend the corresponding PATCH[#] to be applied
469 to before building that module.
470 AUTOINSTALL=
472 If this directive is set to yes then the service
473 /etc/rc.d/init.d/dkms_autoinstaller will automatically try to
474 install this module on any kernel you boot into. See the section
475 on dkms_autoinstaller for more information.
476 BUILD_DEPENDS[#]=
478 This optional directive is an array that allows you to specify
479 other modules as dependencies for your module. Each array ele‐
480 ment should be the PACKAGE_NAME of another module that is man‐
481 aged by dkms. Do not specify a version or architecture in the
482 dependency. Note that this directive is only advisory; missing
483 or broken dependencies cause non-fatal warnings.
484 BUILD_EXCLUSIVE_KERNEL=
486 This optional directive allows you to specify a regular expres‐
487 sion which defines the subset of kernels which DKMS is allowed
488 to build your module for. If the kernel being built for does not
489 match against this regular expression, the dkms build will error
490 out. For example, if you set it as ="^2.4.*", your module would
491 not be built for 2.6 kernels.
492 BUILD_EXCLUSIVE_ARCH=
494 This optional directive functions very similarly to BUILD_EXCLU‐
495 SIVE_KERNEL except that it matches against the kernel architec‐
496 ture. For example, if you set it to ="i.86", your module would
497 not be built for ia32e, x86_64, amd64, s390, etc.
498 POST_ADD=
500 The name of the script to be run after an add is performed. The
501 path should be given relative to the root directory of your
502 source.
503 POST_BUILD=
505 The name of the script to be run after a build is performed. The
506 path should be given relative to the root directory of your
507 source.
508 POST_INSTALL=
510 The name of the script to be run after an install is performed.
511 The path should be given relative to the root directory of your
512 source.
513 POST_REMOVE=
515 The name of the script to be run after a remove is performed.
516 The path should be given relative to the root directory of your
517 source.
518 PRE_BUILD=
520 The name of the script to be run before a build is performed.
521 The path should be given relative to the root directory of your
522 source.
523 PRE_INSTALL=
525 The name of the script to be run before an install is performed.
526 The path should be given relative to the root directory of your
527 source. If the script exits with a non-zero value, the install
528 will be aborted. This is typically used to perform a custom ver‐
529 sion comparison.
530 DKMS.CONF VARIABLES
533 Within your dkms.conf file, you can use certain variables which
534 will be replaced at run-time with their values.
535 $kernelver
537 This variable can be used within a directive definition and dur‐
538 ing use, the actual kernel version in question will be substi‐
539 tuted in its place. This is especially useful in MAKE commands
540 when specifying which INCLUDE statements should be used when
541 compiling your module (eg. MAKE="make all INCLUDEDIR=/lib/mod‐
542 ules/${kernelver}/build/include").
543 $dkms_tree
545 See the section on /etc/dkms/framework.conf for more informa‐
546 tion. This variable represents the location of the DKMS tree on
547 the local system. By default this is /var/lib/dkms , but this
548 value should not be hard-coded into a dkms.conf in the event
549 that the local user has changed it on their system.
550 $source_tree
552 See the section on /etc/dkms/framework.conf for more informa‐
553 tion. This variable represents the location where DKMS keeps
554 source on the local system. By default this is /usr/src , but
555 this value should not be hard-coded into a dkms.conf in the
556 event that the local user has changed it on their system.
557 $kernel_source_dir
559 This variable holds the value of the location of your kernel
560 source directory. Usually, this will be /lib/modules/$ker‐
561 nelver/build , unless otherwise specified with the --kernel‐
562 sourcedir option.
563
565 You can override the module-provided dkms.conf files. Every time after
566 a dkms.conf file is read, dkms will look for and read the following
567 files in order:
568 /etc/dkms/<module>.conf
570 /etc/dkms/<module>-<module-version>.conf
571 /etc/dkms/<module>-<module-version>-<kernel>.conf
572 /etc/dkms/<module>-<module-version>-<kernel>-<arch>.conf
573 You can use these files to override settings in the module-provided
575 dkms.conf files.
576
578 This configuration file controls how the overall DKMS framework han‐
579 dles. It is sourced in every time the dkms command is run. Mainly it
580 can currently be used to set different default values for the vari‐
581 ables.
582 $dkms_tree, $source_tree, $install_tree
584 control where DKMS looks for its framework.
585 $symlink_modules
587 controls whether binary modules are copied to /lib/modules or if
588 only symlinks are created there. Note that these variables can
589 also be manipulated on the command line with --dkmstree,
590 --sourcetree, --installtree and --symlink-modules options.
591 $sign_tool
593 Script to be run at build for signing modules. Two arguments
594 will be passed to the script. The first argument is the target
595 kernel version , the second is the module file path. If the
596 script exits with a non-zero value, the build will be aborted.
597 $autoinstall_all_kernels
599 used by the common postinst for DKMS modules. It controls if the
600 build should be done for all installed kernels or only for the
601 current and latest installed kernel. It has no command line
602 equivalent.
603
605 This boot-time service automatically installs any module which has AU‐
606 TOINSTALL="yes" set in its dkms.conf file. The service works quite sim‐
607 ply and if multiple versions of a module are in your system's DKMS
608 tree, it will not do anything and instead explain that manual interven‐
609 tion is required.
610
612 Gary Lerhaupt
613
615 https://github.com/dell/dkms
616
618 dkms-devel@dell.com http://lists.us.dell.com/mailman/listinfo/dkms-de‐
619 vel
620dkms-3.0.2 21 November 2021 DKMS(8)