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 -j number
264 Run no more than number jobs in parallel; see the -j option of
265 make(1). Defaults to the number of CPUs in the system, detected
266 by nproc(1). Specify 0 to impose no limit on the number of par‐
267 allel jobs.
268
270 During the first install of a module for a <kernelversion>, dkms will
271 search /lib/modules/<kernelversion> for a pre-existing module of the
272 same name. If one is found, it will automatically be saved as an "orig‐
273 inal_module" so that if the newer module is later removed, dkms will
274 put the original module back in its place. Currently, DKMS searches for
275 these original modules with first preference going to modules located
276 in /lib/modules/<kernelversion>/updates/ followed by $DEST_MODULE_LOCA‐
277 TION (as specified in dkms.conf ). If one cannot be found in either lo‐
278 cation, a find will be used to locate one for that kernel. If none are
279 found, then during a later uninstall, your kernel will not have that
280 module replaced.
281 If more than one is found, then the first one located (by preference
283 indicated above) will be considered the "original_module". As well, all
284 copies of the same-named module will be removed from your kernel tree
285 and placed into /var/lib/dkms/<module>/original_module/$kernelver/col‐
286 lisions so that they can be *manually* accessible later. DKMS will
287 never actually do anything with the modules found underneath the /col‐
288 lisions directory, and they will be stored there until you manually
289 delete them.
290
292 When performing an add , a proper dkms.conf file must be found. A prop‐
293 erly formatted conf file is essential for communicating to dkms how and
294 where the module should be installed. While not all the directives are
295 required, providing as many as possible helps to limit any ambiguity.
296 Note that the dkms.conf is really only a shell-script of variable defi‐
297 nitions which are then sourced in by the dkms executable (of the for‐
298 mat, DIRECTIVE="directive text goes here"). As well, the directives are
299 case-sensitive and should be given in ALL CAPS.
300 It is important to understand that many of the DKMS directives are ar‐
302 rays whose index values are tied together. These array associations can
303 be considered families, and there are currently three such families of
304 directive arrays. MAKE[#] and MAKE_MATCH[#] make up one family.
305 PATCH[#] and PATCH_MATCH[#] make up the second family. The third and
306 largest family consists of BUILT_MODULE_NAME[#], BUILT_MODULE_LOCA‐
307 TION[#], DEST_MODULE_NAME[#], DEST_MODULE_LOCATION[#] and STRIP[#].
308 When indexing these arrays when creating your dkms.conf, each family
309 should start at index value 0.
310 MAKE[#]=
312 The MAKE directive array tells DKMS which make command should be
313 used for building your module. The default make command should
314 be put into MAKE[0]. Other entries in the MAKE array will only
315 be used if their corresponding entry in MAKE_MATCH[#] matches,
316 as a regular expression (using egrep), the kernel that the mod‐
317 ule is being built for. Note that if no value is placed in
318 MAKE_MATCH[#] for any MAKE[#] where # > 0, then that MAKE direc‐
319 tive is ignored. MAKE_MATCH[0] is optional and if it is popu‐
320 lated, it will be used to determine if MAKE[0] should be used to
321 build the module for that kernel. If multiple MAKE_MATCH direc‐
322 tives match against the kernel being built for, the last match‐
323 ing MAKE[#] will be used to build your module. If no MAKE direc‐
324 tive is specified or if no MAKE_MATCH matches the kernel being
325 built for, DKMS will attempt to use a generic MAKE command to
326 build your module.
327 KERNELRELEASE will be automatically appended to MAKE[#]. If you
329 want to suppress this behavior, you can quote the make command:
330 'make'.
331 MAKE_MATCH[#]=
333 See the above entry on MAKE[#] directives. This array should be
334 populated with regular expressions which, when matched against
335 the kernel being built for, will tell DKMS to use the corre‐
336 sponding make command in the MAKE[#] directive array to build
337 your module.
338 BUILT_MODULE_NAME[#]=
340 This directive gives the name of the module just after it is
341 built. If your DKMS module package contains more than one module
342 to install, this is a required directive for all of the modules.
343 This directive should explicitly not contain any trailing ".o"
344 or ".ko". Note that for each module within a dkms package, the
345 numeric value of # must be the same for each of BUILT_MOD‐
346 ULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MOD‐
347 ULE_LOCATION and that the numbering should start at 0 (eg.
348 BUILT_MODULE_NAME[0]="qla2200" BUILT_MODULE_NAME[1]="qla2300").
349 BUILT_MODULE_LOCATION[#]=
351 This directive tells DKMS where to find your built module after
352 it has been built. This pathname should be given relative to the
353 root directory of your source files (where your dkms.conf file
354 can be found). If unset, DKMS expects to find your BUILT_MOD‐
355 ULE_NAME[#] in the root directory of your source files. Note
356 that for each module within a dkms package, the numeric value of
357 # must be the same for each of BUILT_MODULE_NAME, BUILT_MOD‐
358 ULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that
359 the numbering should start at 0 (eg. BUILT_MODULE_LOCA‐
360 TION[0]="some/dir/" BUILT_MODULE_LOCATION[1]="other/dir/").
361 DEST_MODULE_NAME[#]=
363 This directive can be used to specify the name of the module as
364 it should be installed. This will rename the module from
365 BUILT_MODULE_NAME[#] to DEST_MODULE_NAME[#]. This directive
366 should explicitly not contain any trailing ".o" or ".ko". If un‐
367 set, it is assumed to be the same value as BUILT_MODULE_NAME[#].
368 Note that for each module within a dkms package, the numeric
369 value of # must be the same for each of BUILT_MODULE_NAME,
370 BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION
371 and that the numbering should start at 0 (eg. DEST_MOD‐
372 ULE_NAME[0]="qla2200_6x" DEST_MODULE_NAME[1]="qla2300_6x").
373 DEST_MODULE_LOCATION[#]=
375 This directive specifies the destination where a module should
376 be installed to, once compiled. It also is used for finding
377 original_modules. This is a required directive, except as noted
378 below. This directive must start with the text "/kernel" which
379 is in reference to /lib/modules/<kernelversion>/kernel. Note
380 that for each module within a dkms package, the numeric value of
381 # must be the same for each of BUILT_MODULE_NAME, BUILT_MOD‐
382 ULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that
383 the numbering should start at 0 (eg. DEST_MODULE_LOCA‐
384 TION[0]="/kernel/drivers/something/" DEST_MODULE_LOCA‐
385 TION[1]="/kernel/drivers/other/").
386 DEST_MODULE_LOCATION is ignored on Fedora and Red Hat Enterprise
388 Linux, Novell SuSE Linux Enterprise Server 10 and higher, Novell
389 SuSE Linux 10.0 and higher, and Ubuntu. Instead, the proper dis‐
390 tribution-specific directory is used.
391 STRIP[#]=
393 By default strip is considered to be "yes". If set to "no", DKMS
394 will not run strip -g against your built module to remove debug
395 symbols from it. STRIP[0] is used as the default for any unset
396 entries in the STRIP array.
397 PACKAGE_NAME=
399 This directive is used to give the name associated with the en‐
400 tire package of modules. This is the same name that is used with
401 the -m option when building, adding, etc. and may not necessar‐
402 ily be the same as the MODULE_NAME. This directive must be
403 present in every dkms.conf.
404 PACKAGE_VERSION=
406 This directive is used to give the version associated with the
407 entire package of modules being installed within that dkms pack‐
408 age. This directive must be present in every dkms.conf.
409 CLEAN= CLEAN specifies the make clean command to be used to clean up
411 both before and after building the module. If unset, it is as‐
412 sumed to be "make clean".
413 OBSOLETE_BY=
415 This directive allows you to specify a kernel version that obso‐
416 letes the necessity for this particular DKMS module. This can be
417 specified as a particular upstream kernel or an ABI bump of a
418 kernel. For example, "2.6.24" would be an upstream kernel and
419 "2.6.24-16" would represent an ABI bump for a kernel. Both are
420 valid in this area.
421 Please avoid the use of OBSOLETE_BY wherever possible. It's use
423 indicates a lack of proper module versioning using MODULE_VER‐
424 SION() tags in the module source itself. It is better to fix the
425 MODULE_VERSION() tags than use OBSOLETE_BY. This also intro‐
426 duces a implicit distribution/version dependency on the package,
427 as the value of OBSOLETE_BY is meaningful only in the context of
428 a single distribution/version.
429 If you feel you must use it, please use as such in dkms.conf:
431 ubuntu_804="Ubuntu
433 8.04"
434 if [ -x /usr/bin/lsb_release ]; then
435 if [ "$(/usr/bin/lsb_release -sir)" == "${ubuntu_804}" ];
436 then
437 OBSOLETE_BY="2.6.25"
438 fi
439 fi
440 PATCH[#]=
443 Use the PATCH directive array to specify patches which should be
444 applied to your source before a build occurs. All patches are
445 expected to be in -p1 format and are applied with the patch -p1
446 command. Each directive should specify the filename of the
447 patch to apply, and all patches must be located in the patches
448 subdirectory of your source directory ( /usr/src/<module>-<mod‐
449 ule-version>/patches/ ). If any patch fails to apply, the build
450 will be halted and the rejections can be inspected in
451 /var/lib/dkms/<module>/<module-version>/build/. If a PATCH
452 should only be applied conditionally, the PATCH_MATCH[#] array
453 should be used, and a corresponding regular expression should be
454 placed in PATCH_MATCH[#] which will alert dkms to only use that
455 PATCH[#] if the regular expression matches the kernel which the
456 module is currently being built for.
457 PATCH_MATCH[#]=
459 See the above description for PATCH[#] directives. If you only
460 want a patch applied in certain scenarios, the PATCH_MATCH array
461 should be utilized by giving a regular expression which matches
462 the kernels you intend the corresponding PATCH[#] to be applied
463 to before building that module.
464 AUTOINSTALL=
466 If this directive is set to yes then the service
467 /etc/rc.d/init.d/dkms_autoinstaller will automatically try to
468 install this module on any kernel you boot into. See the section
469 on dkms_autoinstaller for more information.
470 BUILD_DEPENDS[#]=
472 This optional directive is an array that allows you to specify
473 other modules as dependencies for your module. Each array ele‐
474 ment should be the PACKAGE_NAME of another module that is man‐
475 aged by dkms. Do not specify a version or architecture in the
476 dependency. Note that this directive is only advisory; missing
477 or broken dependencies cause non-fatal warnings.
478 BUILD_EXCLUSIVE_KERNEL=
480 This optional directive allows you to specify a regular expres‐
481 sion which defines the subset of kernels which DKMS is allowed
482 to build your module for. If the kernel being built for does not
483 match against this regular expression, the dkms build will error
484 out. For example, if you set it as ="^2.4.*", your module would
485 not be built for 2.6 kernels.
486 BUILD_EXCLUSIVE_ARCH=
488 This optional directive functions very similarly to BUILD_EXCLU‐
489 SIVE_KERNEL except that it matches against the kernel architec‐
490 ture. For example, if you set it to ="i.86", your module would
491 not be built for ia32e, x86_64, amd64, s390, etc.
492 POST_ADD=
494 The name of the script to be run after an add is performed. The
495 path should be given relative to the root directory of your
496 source.
497 POST_BUILD=
499 The name of the script to be run after a build is performed. The
500 path should be given relative to the root directory of your
501 source.
502 POST_INSTALL=
504 The name of the script to be run after an install is performed.
505 The path should be given relative to the root directory of your
506 source.
507 POST_REMOVE=
509 The name of the script to be run after a remove is performed.
510 The path should be given relative to the root directory of your
511 source.
512 PRE_BUILD=
514 The name of the script to be run before a build is performed.
515 The path should be given relative to the root directory of your
516 source.
517 PRE_INSTALL=
519 The name of the script to be run before an install is performed.
520 The path should be given relative to the root directory of your
521 source. If the script exits with a non-zero value, the install
522 will be aborted. This is typically used to perform a custom ver‐
523 sion comparison.
524 DKMS.CONF VARIABLES
527 Within your dkms.conf file, you can use certain variables which
528 will be replaced at run-time with their values.
529 $kernelver
531 This variable can be used within a directive definition and dur‐
532 ing use, the actual kernel version in question will be substi‐
533 tuted in its place. This is especially useful in MAKE commands
534 when specifying which INCLUDE statements should be used when
535 compiling your module (eg. MAKE="make all INCLUDEDIR=/lib/mod‐
536 ules/${kernelver}/build/include").
537 $dkms_tree
539 See the section on /etc/dkms/framework.conf for more informa‐
540 tion. This variable represents the location of the DKMS tree on
541 the local system. By default this is /var/lib/dkms , but this
542 value should not be hard-coded into a dkms.conf in the event
543 that the local user has changed it on their system.
544 $source_tree
546 See the section on /etc/dkms/framework.conf for more informa‐
547 tion. This variable represents the location where DKMS keeps
548 source on the local system. By default this is /usr/src , but
549 this value should not be hard-coded into a dkms.conf in the
550 event that the local user has changed it on their system.
551 $kernel_source_dir
553 This variable holds the value of the location of your kernel
554 source directory. Usually, this will be /lib/modules/$ker‐
555 nelver/build , unless otherwise specified with the --kernel‐
556 sourcedir option.
557
559 You can override the module-provided dkms.conf files. Every time after
560 a dkms.conf file is read, dkms will look for and read the following
561 files in order:
562 /etc/dkms/<module>.conf
564 /etc/dkms/<module>-<module-version>.conf
565 /etc/dkms/<module>-<module-version>-<kernel>.conf
566 /etc/dkms/<module>-<module-version>-<kernel>-<arch>.conf
567 You can use these files to override settings in the module-provided
569 dkms.conf files.
570
572 This configuration file controls how the overall DKMS framework han‐
573 dles. It is sourced in every time the dkms command is run. Mainly it
574 can currently be used to set different default values for the vari‐
575 ables.
576 Additionally to /etc/dkms/framework.conf, any file matching the glob
578 /etc/dkms/framework.conf.d/*.conf will be loaded as well.
579 $dkms_tree, $source_tree, $install_tree
581 control where DKMS looks for its framework.
582 $symlink_modules
584 controls whether binary modules are copied to /lib/modules or if
585 only symlinks are created there. Note that these variables can
586 also be manipulated on the command line with --dkmstree,
587 --sourcetree, --installtree and --symlink-modules options.
588 $autoinstall_all_kernels
590 used by the common postinst for DKMS modules. It controls if the
591 build should be done for all installed kernels or only for the
592 current and latest installed kernel. It has no command line
593 equivalent.
594
596 This boot-time service automatically installs any module which has AU‐
597 TOINSTALL="yes" set in its dkms.conf file. The service works quite sim‐
598 ply and if multiple versions of a module are in your system's DKMS
599 tree, it will not do anything and instead explain that manual interven‐
600 tion is required.
601
603 Gary Lerhaupt
604
606 https://github.com/dell/dkms
607
609 dkms-devel@dell.com http://lists.us.dell.com/mailman/listinfo/dkms-de‐
610 vel
611dkms-3.0.4 18 June 2022 DKMS(8)