1DKMS(8)                     System Manager's Manual                    DKMS(8)
2
3
4

NAME

6       dkms - Dynamic Kernel Module Support
7

SYNOPSIS

9       dkms [action] [options] [module/module-version] [/path/to/source-tree]
10            [/path/to/tarball.tar] [/path/to/driver.rpm]
11

DESCRIPTION

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

ACTIONS

17       add [module/module-version] [/path/to/source-tree]
18           [/path/to/tarball.tar]
19
20           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
30       remove [module/module-version] [-k kernel/arch] [--all]
31
32           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
38       build [module/module-version] [-k kernel/arch]
39
40           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
47       unbuild [module/module-version] [-k kernel/arch] [--all]
48
49           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
56       install [module/module-version] [-k kernel/arch] [/path/to/driver.rpm]
57
58           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
68       uninstall [module/module-version] [-k kernel/arch] [--all]
69
70           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
77       match [--templatekernel kernel/arch] [-k kernel/arch]
78
79           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
84       mktarball [module/module-version] [-k kernel/arch]
85                 [--archive /path/to/tarball.tar] [--source-only] [--binaries-
86                 only]
87
88           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
103       ldtarball [/path/to/tarball.tar] [--force]
104
105           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
112       status [module/module-version] [-k kernel/arch]
113
114           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
120       autoinstall
121
122           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

OPTIONS

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
132       -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
137       -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
146       -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
157              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
161       -q, --quiet
162              Quiet.
163
164       -V, --version
165              Prints the currently installed version of dkms and exits.
166
167       -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
173       --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
184       --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
190       --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
195       --force
196              This option can be used in conjunction with ldtarball  to  force
197              copying over of extant files.
198
199       --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
209       --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
215       --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
221       --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
226       --modprobe-on-install
227              This option executes modprobe on the modules upon successful in‐
228              stallation.
229
230       --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
236       --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
242       --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
249       --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
254       --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
259       --installtree path/to/place
260              Provides a location to place modules when a dkms install command
261              is issued.
262
263       --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
269       -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

ORIGINAL MODULES

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
288       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

DKMS.CONF

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
307       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
317       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
334              KERNELRELEASE  will be automatically appended to MAKE[#]. If you
335              want to suppress this behavior, you can quote the make  command:
336              'make'.
337
338       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
345       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
356       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
368       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
380       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
393              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
398       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
404       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
411       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
416       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
420       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
428              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
436              If you feel you must use it, please use as such in dkms.conf:
437
438               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
447
448       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
464       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
471       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
477       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
485       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
493       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
499       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
504       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
509       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
514       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
519       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
524       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
531
532       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
536       $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
544       $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
551       $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
558       $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

DKMS.CONF OVERRIDES

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
569       /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
574       You  can  use  these  files to override settings in the module-provided
575       dkms.conf files.
576

/etc/dkms/framework.conf

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
583       $dkms_tree, $source_tree, $install_tree
584              control where DKMS looks for its framework.
585
586       $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
592       $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
598       $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

dkms_autoinstaller

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

AUTHOR

612       Gary Lerhaupt
613

WEBPAGE

615       https://github.com/dell/dkms
616

MAILING-LIST

618       dkms-devel@dell.com  http://lists.us.dell.com/mailman/listinfo/dkms-de
619       vel
620
621
622
623dkms-3.0.2                     21 November 2021                        DKMS(8)
Impressum