dkms

package: dkms

title: dkms(8)

summary: Dynamic Kernel Module Support

text:
# dkms(8)

## NAME
dkms - Dynamic Kernel Module Support

## SYNOPSIS
dkms

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

## DESCRIPTION
dkms is a framework which allows kernel modules to be dynamically built for each kernel on your system in a simplified and organized fashion.

## ACTIONS
add

[module/module-version | /path/to/source-tree | /path/to/tarball.tar]

Adds a module/module-version combination to the tree for builds and installs. If module/module-version, -m module/module-version, or -m module -v module-version are passed as options, this command requires source in /usr/src/<module>-<module-version>/ as well as a properly formatted dkms.conf file. If /path/to/source-tree is passed as an option, and source-tree contains a dkms.conf file, it will copy /path/to/source-tree to /usr/src/module-module-version. If /path/to/tarball.tar is passed, this command behaves like the ldtarball command.

remove

[module/module-version] [-k kernel/arch] [--all]

Removes a module/version or module/version/kernel/arch combination from the tree. If the module is currently installed, it first uninstalls it and if applicable, will replace it with its original_module. Use the --all option in order to remove all instances for every kernel at once.

build

[module/module-version] [-k kernel/arch] [--force]

Builds the specified module/version combo for the specified kernel/arch. If the -k option is not specified it builds for the currently running kernel and arch. All builds occur in the directory /var/lib/dkms/<module>/<module-version>/build/. If the module/module-version combo has not been added, dkms will try to add it, and in that case build can take the same arguments that add can. If the module is already built, it will not be rebuilt again by default, and the --force option should be used to override this.

unbuild

[module/module-version] [-k kernel/arch] [--all]

Undoes the build for a module/version or module/version/kernel/arch combination from the tree. If the module is currently installed, it first uninstalls it and if applicable, will replace it with its original_module. Finally all binary kernel modules are removed. Use the --all option in order to remove all instances for every kernel at once.

install

[module/module-version] [-k kernel/arch] [--force] [/path/to/driver.rpm]

Installs a built module/version combo onto the kernel it was built for. If the kernel option is not specified it assumes the currently running kernel. If the module has not been built, dkms will try to build it. If the module has not been added, dkms will try to add it. In both cases, the install command can then take the same arguments as the build or add commands. If the module is already installed, it will not be reinstalled again by default, and the --force option should be used to override this. If you pass a .rpm file, dkms will try to install that file with rpm -Uvh, and it will perform an autoinstall action to be sure that everything is built for your kernel if the RPM installed successfully.

uninstall

[module/module-version] [-k kernel/arch] [--all]

Uninstalls an installed module/module-version combo from the kernel/arch passed in the -k option, or the current kernel if the -k option was not passed. Use the --all option in order to uninstall all instances for every kernel at once. After uninstall completion, the driver will be left in the built state. To completely remove a driver, the remove action should be utilized.

match

[--templatekernel kernel/arch] [-k kernel/arch]

Match installs modules onto the specified kernel by looking at the configuration of the specified templatekernel. Every module that is installed on the templatekernel within dkms is then installed on that specified kernel.

mktarball

[module/module-version] [-k kernel/arch] [--archive /path/to/tarball.tar] [--source-only] [--binaries-only]

Creates a tarball archive for the specified module/version of all files in the DKMS tree for that module/version combination. This includes the source and any built modules for kernels in the tree (as specified). Otherwise, you can specify a singular kernel to archive only, or multiple kernels to archive (-k kernel1/arch1 -k kernel2/arch2). Optionally, you can use --archive to specify the file that you would like to save this tarball to. You can also specify --binaries-only if you want the resultant tarball not to include the module source. Likewise, --source-only can be used to specify that no prebuilt binaries should be included in the tarball. In general, mktarball is great for systems management purposes as you can build your driver on just one system and then use ldtarball on all of your other systems to get the same built modules loaded without having to wait for anything to compile.

ldtarball

[/path/to/tarball.tar] [--force]

This takes a tarball made from the mktarball command and loads it into your DKMS tree. This will leave any newly added modules in the built state and dkms install should then be called to install any of them. If files already exist where ldtarball is attempting to place them, it will warn and not copy over them. The --force option should be used to override this.

status

[module/module-version] [-k kernel/arch]

Returns the current status of modules, versions and kernels within the tree as well as whether they have been added, built or installed. Status can be shown for just a certain module, a certain kernel, a module/version combination or a module/version/kernel combination. If the source directory, or the symbolic link 'source' pointing to it is missing, the status of the module/version combination will be displayed as 'broken'. In that case dkms will not perform any other action on that particular module/version combination. Manual intervention is required. If only the symbolic link 'source' is missing, the add action may be used to re-add the module/version combination to dkms.

autoinstall

Attempt to install the latest revision of all modules that have been installed for other kernel revisions. dkms_autoinstaller is a stub that uses this action to perform its work.

generate_mok

Command to be issued standalone to generate Secure Boot keys. Required only if prior manipulation of the keys is needed, otherwise the keys are automatically generated on the first build attempt of a DKMS module. No additional arguments are parsed.

## OPTIONS
-m <module>/<module-version>

The name of the module and module version you want to operate on. The -m part of this option is optional, and can be omitted in virtually all circumstances.

-v <module-version>

The version of the module to execute the specified action upon. This option only has to be specified if you pass a -m option without a <module-version> component of its own.

-k <kernel-version>/<arch>

The kernel and arch to perform the action upon. You can specify multiple kernel version/arch pairs on the command line by repeating the -k argument with a different kernel version and arch. However, not all actions support multiple kernel versions (it will error out in this case). The arch part can be omitted, and DKMS will assume you want it to be the arch of the currently running system.

-a, --arch

The system architecture to perform the action upon. It is optional if you pass it as part of the -k option. If not specified, it assumes the arch of the currently running system (`uname -m`). You can specify multiple arch parameters on the same command line by repeating the -a argument with a different arch name. When multiple architectures are specified, there must be a 1:1 relationship between -k arguments to -a arguments. DKMS will then assume the first -a argument aligns with the first -k kernel and so on for the second, third, etc. For example, if you were to specify: -k kernel1 -k kernel2 -a i386 -k kernel3 -a i686 -a x86_64, DKMS would process this as: kernel1-i386, kernel2-i686, kernel3-x86_64.

-q, --quiet

Quiet.

-V, --version

Prints the currently installed version of dkms and exits.

-c <dkms.conf-location>

The location of the dkms.conf file. This is needed for the add action and if not specified, it is assumed to be located in /usr/src/<module>-<module-version>/. See below for more information on the format of dkms.conf.

--config <kernel-.config-location>

During a build this option is used to specify an alternate location for the kernel .config file which was used to compile that kernel. Normally, dkms uses the Red Hat standard location and config filenames located in /usr/src/linux-<kernel>/configs/. If the config for the kernel that you are building a module for is not located here or does not have the expected name in this location, you will need to tell dkms where the necessary .config can be found so that your kernel can be properly prepared for the module build.

--archive <tarball-location>

This option is used during a ldtarball action to specify the location of the tarball you wish to load into your DKMS tree. You only have to specify the --archive part of this option if <tarball-location> does not already exist as a file.

--templatekernel <kernel-version>

This option is required for the action: match. Match will look at the templatekernel specified and install all of the same module/version combinations on the other kernel.

--force

This option can be used in conjunction with build, install and ldtarball to force copying over existing files.

--force-version-override

This option skips the checks whether the version of the module, which is going to be installed, is newer than the already installed version.

--binaries-only

This option can be used in conjunction with mktarball in order to create a DKMS tarball which does not contain the source for the module within it. This can be helpful in reducing the size of the tarball if you know that the system which this tarball will be loaded upon already has the source installed. In order to load a tarball made as binaries-only you must have the module source in that systems DKMS tree. If you do not, DKMS will refuse to load a binaries-only tarball.

--source-only

This option can be used in conjunction with mktarball but do not want the tarball you create to have any prebuilt modules within it, passing this option will keep its internal DKMS tarball from containing any prebuilt modules.

--all

This option can be used to automatically specify all relevant kernels/arches for a module/module-version. This can be used for things like remove, unbuild and uninstall. This saves the trouble of having to actually specify -k kernel1 -a arch1 -k kernel2 -a arch2 for every kernel you have built your module for.

--no-depmod

This option prevents DKMS from running the depmod command during install and uninstall which will avoid (re)calculating module dependencies and thereby save time.

--modprobe-on-install

This option executes modprobe on the modules upon successful installation.

--kernelsourcedir <kernel-source-directory-location>

Using this option you can specify the location of your kernel source directory. Most likely you will not need to set this if your kernel source is accessible via /lib/modules/$kernel_version/build.

--directive <"cli-directive=cli-value">

Using this option, you can specify additional directives from the command line. The --directive option can be used multiple times on the same command-line to specify multiple additional command line directives.

--rpm_safe_upgrade

This flag should be used when packaging DKMS enabled modules in RPMs. It should be specified during both the add and remove actions in the RPM spec to ensure that DKMS and RPM behave correctly in all scenarios when upgrading between various versions of a dkms enabled module RPM package.

--dkmstree path/to/place

Provides a destination tree for building and installing modules to. Useful in cases that you don't want to contaminate a system when using solely for building.

--sourcetree path/to/place

Provides a location to build a DKMS package from. Useful for systems that you may not have root access, but would still like to be able to build DKMS packages.

--installtree path/to/place

Provides a location to place modules when a dkms install command is issued.

-j number

Run no more than number jobs in parallel; see the -j option of make(1). Defaults to the number of CPUs in the system, detected by nproc(1). Specify 0 to impose no limit on the number of parallel jobs.

--verbose

Enable verbose output of external commands executed in DKMS.

## ORIGINAL MODULES
During the first install of a module for a <kernelversion>, dkms will search /lib/modules/<kernelversion> for a pre-existing module of the same name. If one is found, it will automatically be saved as an "original_module" so that if the newer module is later removed, dkms will put the original module back in its place. Currently, DKMS searches for these original modules with first preference going to modules located in /lib/modules/<kernelversion>/updates/ followed by $DEST_MODULE_LOCATION (as specified in dkms.conf ). If one cannot be found in either location, a find will be used to locate one for that kernel. If none are found, then during a later uninstall, your kernel will not have that module replaced.

If more than one is found, then the first one located (by preference indicated above) will be considered the "original_module". As well, all copies of the same-named module will be removed from your kernel tree and placed into /var/lib/dkms/<module>/original_module/$kernelver/collisions so that they can be *manually* accessible later. DKMS will never actually do anything with the modules found underneath the /collisions directory, and they will be stored there until you manually delete them.

## DKMS.CONF
When performing an add, a proper dkms.conf file must be found. A properly formatted conf file is essential for communicating to dkms how and where the module should be installed. While not all the directives are required, providing as many as possible helps to limit any ambiguity. Note that the dkms.conf is really only a shell-script of variable definitions which are then sourced in by the dkms executable (of the format, DIRECTIVE="directive text goes here"). As well, the directives are case-sensitive and should be given in ALL CAPS.

It is important to understand that many of the DKMS directives are arrays whose index values are tied together. These array associations can be considered families, and there are currently three such families of directive arrays. MAKE[#] and MAKE_MATCH[#] make up one family. PATCH[#] and PATCH_MATCH[#] make up the second family. The third and largest family consists of BUILT_MODULE_NAME[#], BUILT_MODULE_LOCATION[#], DEST_MODULE_NAME[#], DEST_MODULE_LOCATION[#] and STRIP[#]. When indexing these arrays when creating your dkms.conf, each family should start at index value 0.

PACKAGE_NAME=

This directive is used to give the name associated with the entire package of modules. This is the same name that is used with the -m option when building, adding, etc. and may not necessarily be the same as the MODULE_NAME. This directive must be present in every dkms.conf.

PACKAGE_VERSION=

This directive is used to give the version associated with the entire package of modules being installed within that dkms package. This directive must be present in every dkms.conf.

BUILT_MODULE_NAME[#]=

This directive gives the name of the module just after it is built. If your DKMS module package contains more than one module to install, this is a required directive for all of the modules. This directive should explicitly not contain any trailing ".o" or ".ko". Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. BUILT_MODULE_NAME[0]="qla2200" BUILT_MODULE_NAME[1]="qla2300").

BUILT_MODULE_LOCATION[#]=

This directive tells DKMS where to find your built module after it has been built. This pathname should be given relative to the root directory of your source files (where your dkms.conf file can be found). If unset, DKMS expects to find your BUILT_MODULE_NAME[#] in the root directory of your source files. Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. BUILT_MODULE_LOCATION[0]="some/dir/" BUILT_MODULE_LOCATION[1]="other/dir/").

DEST_MODULE_NAME[#]=

This directive can be used to specify the name of the module as it should be installed. This will rename the module from BUILT_MODULE_NAME[#] to DEST_MODULE_NAME[#]. This directive should explicitly not contain any trailing ".o" or ".ko". If unset, it is assumed to be the same value as BUILT_MODULE_NAME[#]. Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. DEST_MODULE_NAME[0]="qla2200_6x" DEST_MODULE_NAME[1]="qla2300_6x").

DEST_MODULE_LOCATION[#]=

This directive specifies the destination where a module should be installed to, once compiled. It also is used for finding original_modules. This is a required directive, except as noted below. This directive must start with the text "/kernel" which is in reference to /lib/modules/<kernelversion>/kernel. Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. DEST_MODULE_LOCATION[0]="/kernel/drivers/something/" DEST_MODULE_LOCATION[1]="/kernel/drivers/other/"). DEST_MODULE_LOCATION is ignored on Fedora and Red Hat Enterprise Linux, Novell SuSE Linux Enterprise Server 10 and higher, Novell SuSE Linux 10.0 and higher, and Ubuntu. Instead, the proper distribution-specific directory is used.

STRIP[#]=

By default strip is considered to be "yes". If set to "no", DKMS will not run strip -g against your built module to remove debug symbols from it. STRIP[0] is used as the default for any unset entries in the STRIP array.

MAKE[#]=

The MAKE directive array tells DKMS which make command should be used for building your module. The default make command should be put into MAKE[0]. Other entries in the MAKE array will only be used if their corresponding entry in MAKE_MATCH[#] matches, as a regular expression (using grep -E), the kernel that the module is being built for. Note that if no value is placed in MAKE_MATCH[#] for any MAKE[#] where # > 0, then that MAKE directive is ignored. MAKE_MATCH[0] is optional and if it is populated, it will be used to determine if MAKE[0] should be used to build the module for that kernel. If multiple MAKE_MATCH directives match against the kernel being built for, the last matching MAKE[#] will be used to build your module. If no MAKE directive is specified or if no MAKE_MATCH matches the kernel being built for, DKMS will attempt to use a generic MAKE command to build your module. KERNELRELEASE will be automatically appended to MAKE[#]. If you want to suppress this behavior, you can quote the make command: 'make'.

MAKE_MATCH[#]=

See the above entry on MAKE[#] directives. This array should be populated with regular expressions which, when matched against the kernel being built for, will tell DKMS to use the corresponding make command in the MAKE[#] directive array to build your module.

CLEAN=

CLEAN specifies the make clean command to be used to clean up both before and after building the module. If unset, it is assumed to be "make clean".

NO_WEAK_MODULES=

The NO_WEAK_MODULES parameter prevents dkms from creating a symlink into the weak-updates directory, which is the default on Red Hat derivatives. The weak modules facility was designed to eliminate the need to rebuild kernel modules when kernel upgrades occur and relies on the symbols within the kABI. Fedora does not guaranteed a stable kABI so it should be disabled in the specific module override by setting it to "yes". For example, for an Nvidia DKMS module you would set the following in /etc/dkms/nvidia.conf:

NO_WEAK_MODULES="yes"

OBSOLETE_BY=

This directive allows you to specify a kernel version that obsoletes the necessity for this particular DKMS module. This can be specified as a particular upstream kernel or an ABI bump of a kernel. For example, "2.6.24" would be an upstream kernel and "2.6.24-16" would represent an ABI bump for a kernel. Both are valid in this area. Please avoid the use of OBSOLETE_BY wherever possible. It's use indicates a lack of proper module versioning using MODULE_VERSION() tags in the module source itself. It is better to fix the MODULE_VERSION() tags than use OBSOLETE_BY. This also introduces a implicit distribution/version dependency on the package, as the value of OBSOLETE_BY is meaningful only in the context of a single distribution/version.

PATCH[#]=

Use the PATCH directive array to specify patches which should be applied to your source before a build occurs. All patches are expected to be in -p1 format and are applied with the patch -p1 command. Each directive should specify the filename of the patch to apply, and all patches must be located in the patches subdirectory of your source directory ( /usr/src/<module>-<module-version>/patches/ ). If any patch fails to apply, the build will be halted and the rejections can be inspected in /var/lib/dkms/<module>/<module-version>/build/. If a PATCH should only be applied conditionally, the PATCH_MATCH[#] array should be used, and a corresponding regular expression should be placed in PATCH_MATCH[#] which will alert dkms to only use that PATCH[#] if the regular expression matches the kernel which the module is currently being built for.

PATCH_MATCH[#]=

See the above description for PATCH[#] directives. If you only want a patch applied in certain scenarios, the PATCH_MATCH array should be utilized by giving a regular expression which matches the kernels you intend the corresponding PATCH[#] to be applied to before building that module.

AUTOINSTALL=

If this directive is set to yes then the service /etc/rc.d/init.d/dkms_autoinstaller will automatically try to install this module on any kernel you boot into. See the section on dkms_autoinstaller for more information.

BUILD_DEPENDS[#]=

This optional directive is an array that allows you to specify other modules as dependencies for your module. Each array element should be the PACKAGE_NAME of another module that is managed by dkms. Do not specify a version or architecture in the dependency. Note that this directive is only advisory; missing or broken dependencies cause non-fatal warnings.

BUILD_EXCLUSIVE_KERNEL=

This optional directive allows you to specify a regular expression which defines the subset of kernels which DKMS is allowed to build your module for. If the kernel being built for does not match against this regular expression (or does not the satisfy the constraints of any other BUILD_EXCLUSIVE_* directive), the dkms build will error out with exit code 77. Note that dkms autoinstall will ignore this type of error condition and simply skip the respective modules. For example, if you set it as ="^2.4.*", your module would not be built for 2.6 or later kernels.

BUILD_EXCLUSIVE_KERNEL_MIN=

and BUILD_EXCLUSIVE_KERNEL_MAX= These optional directives allow one to specify the minimal and maximal kernel versions supported by the module. If one (or both) of these are defined, the module will not be built for kernels outside the specified version limits. For example, if you set BUILD_EXCLUSIVE_KERNEL_MIN as "=3.5", your module would be built for e.g. "3.5-rc2", "3.6.18" or other later versions but not for "3.4.999" or earlier kernels. Similarly, if you set BUILD_EXCLUSIVE_KERNEL_MAX as ="4.12", your module would be built for e.g. "4.11.999", "3.9-rc5" or other earlier versions, but not for "4.12-rc1" or later kernels.

BUILD_EXCLUSIVE_ARCH=

This optional directive functions very similarly to BUILD_EXCLUSIVE_KERNEL except that it matches against the kernel architecture. For example, if you set it to ="i.86", your module would not be built for ia32e, x86_64, amd64, s390, etc.

BUILD_EXCLUSIVE_CONFIG=

This optional directive allows you to specify a space separated list of kernel configuration options ("CONFIG_FOO") that must be enabled in the targeted kernels ".config" file (either to be compiled in or to be built as a module) or absent (if prefixed with an exclamation mark, e.g. "!CONFIG_BAR") in order to build the module. For example, if you set it as ="CONFIG_PCI !CONFIG_PREEMPT_RT", your module would only be built for kernels that have PCI enabled, but the RT patchset disabled.

POST_ADD=

The name of the script to be run after an add is performed. The path should be given relative to the root directory of your source.

POST_BUILD=

The name of the script to be run after a build is performed. The path should be given relative to the root directory of your source.

POST_INSTALL=

The name of the script to be run after an install is performed. The path should be given relative to the root directory of your source.

POST_REMOVE=

The name of the script to be run after a remove is performed. The path should be given relative to the root directory of your source.

PRE_BUILD=

The name of the script to be run before a build is performed. The path should be given relative to the root directory of your source.

PRE_INSTALL=

The name of the script to be run before an install is performed. The path should be given relative to the root directory of your source. If the script exits with a non-zero value, the install will be aborted. This is typically used to perform a custom version comparison.

## DKMS.CONF VARIABLES
Within your dkms.conf file, you can use certain variables which will be replaced at run-time with their values.

$kernelver

This variable can be used within a directive definition and during use, the actual kernel version in question will be substituted in its place. This is especially useful in MAKE commands when specifying which INCLUDE statements should be used when compiling your module (eg. MAKE="make all INCLUDEDIR=/lib/modules/${kernelver}/build/include").

$kernel_source_dir

This variable holds the value of the location of your kernel source directory. Usually, this will be /lib/modules/$kernelver/build, unless otherwise specified with the --kernelsourcedir option.

## DKMS.CONF OVERRIDES
You can override the module-provided dkms.conf files. Every time after a dkms.conf file is read, dkms will look for and read the following files in order:

/etc/dkms/<module>.conf

/etc/dkms/<module>-<module-version>.conf

/etc/dkms/<module>-<module-version>-<kernel>.conf

/etc/dkms/<module>-<module-version>-<kernel>-<arch>.conf

You can use these files to override settings in the module-provided dkms.conf files.

## /etc/dkms/framework.conf
This configuration file controls how the overall DKMS framework handles. It is sourced in every time the dkms command is run. Mainly it can currently be used to set different default values for the variables.

The file contains descriptions for each directive it supports.

Additionally to /etc/dkms/framework.conf, any file matching the glob /etc/dkms/framework.conf.d/*.conf will be loaded as well.

$dkms_tree, $source_tree, $install_tree, $tmp_location

Control which folders DKMS uses for components and artifacts.

$verbose

Can be set to anything but a null value to enable verbose output of external commands executed in DKMS.

$symlink_modules

Controls whether binary modules are copied to /lib/modules or if only symlinks are created there. Note that these variables can also be manipulated on the command line with --dkmstree, --sourcetree, --installtree and --symlink-modules options.

$autoinstall_all_kernels

Used by the common postinst for DKMS modules. It controls if the build should be done for all installed kernels or only for the current and latest installed kernel. It has no command line equivalent.

$sign_file

This is the path of the sign-file kernel binary that is used to sign the kernel modules. The variable $kernelver can be used in path to represent the target kernel version. The path for the binary depends on the distribution.

$mok_signing_key, $mok_certificate

Location of the key and certificate files used for Secure boot. The variable $kernelver can be used in path to represent the target kernel version. NOTE: If any of the files specified by $mok_signing_key and $mok_certificate are non-existant, dkms will re-create both files.

mok_signing_key can also be a "pkcs11:..." string for PKCS#11 engine, as long as the sign_file program supports it.

$modprobe_on_install

Automatically load the built modules upon successful installation.

$parallel_jobs

Run no more than this number of jobs in parallel.

## dkms_autoinstaller
This boot-time service automatically installs any module which has AUTOINSTALL="yes" set in its dkms.conf file. The service works quite simply and if multiple versions of a module are in your system's DKMS tree, it will not do anything and instead explain that manual intervention is required.

## AUTHOR
Gary Lerhaupt, Emil Velikov, Simone Caronni, Xu Zhen

## WEBPAGE
https://github.com/dell/dkms


package: dlm

title: dlm_controld(8)

summary: dlm cluster control daemon

text:
# dlm_controld(8)

## NAME
dlm_controld - dlm cluster control daemon

## SYNOPSIS
dlm_controld [OPTIONS]

## DESCRIPTION
The kernel dlm requires a user daemon to manage lockspace membership. dlm_controld manages lockspace membership using corosync cpg groups, and translates membership changes into dlm kernel recovery events. dlm_controld also manages posix locks for cluster file systems using the dlm.

## OPTIONS
Command line options override a corresponding setting in dlm.conf(5).

For default settings, see dlm_controld -h.

--daemon_debug | -D

enable debugging to stderr and don't fork

--foreground

don't fork

--log_debug | -K

enable kernel dlm debugging messages

--protocol | -r str

dlm kernel lowcomms protocol: tcp, sctp, detect

--debug_logfile | -L

write debugging to log file

--enable_plock | -p 0|1

enable/disable posix lock support for cluster fs

--plock_debug | -P

enable plock debugging

--plock_rate_limit | -l int

limit rate of plock operations (0 for none)

--plock_ownership | -o 0|1

enable/disable plock ownership

--drop_resources_time | -t int

plock ownership drop resources time (milliseconds)

--drop_resources_count | -c int

plock ownership drop resources count

--drop_resources_age | -a int

plock ownership drop resources age (milliseconds)

--post_join_delay | -j int

seconds to delay fencing after cluster join

--enable_fencing | -f 0|1

enable/disable fencing

--enable_concurrent_fencing 0|1

enable/disable concurrent fencing

--enable_startup_fencing | -s 0|1

enable/disable startup fencing

--enable_quorum_fencing | -q 0|1

enable/disable quorum requirement for fencing

--enable_quorum_lockspace 0|1

enable/disable quorum requirement for lockspace operations

--enable_helper 0|1

enable/disable helper process for running commands

--repeat_failed_fencing 0|1

enable/disable retrying after fencing fails

--fence_all str

fence all nodes with this agent

--unfence_all

enable unfencing self with fence_all agent

--help | -h

print this help, then exit

--version | -V

Print program version information, then exit

## SEE ALSO
dlm_tool(8), dlm.conf(5)


title: dlm_stonith(8)

text:
# dlm_stonith(8)

## NAME
dlm_stonith - a proxy for fencing via stonith/pacemaker

## SYNOPSIS
dlm_stonith

## DESCRIPTION
dlm_controld can use dlm_stonith as a proxy fence agent when the stonith/pacemaker system performs actual fencing.

dlm_stonith is run by dlm_controld, and is not meant to be run manually. dlm_controld provides the options on stdin as key=val; command line options are for testing.

If fencing was successful, this program has a zero exit code. If fencing failed, this program has a non-zero exit code.

## OPTIONS
-n nodeid

The nodeid of the target node. (stdin key is "node")

-t fail_time

The time(2) at which the target node failed. If this option is provided, and the last fencing time is later, then a new fencing request is not made.

## SEE ALSO
dlm_controld(8), dlm.conf(5)


title: dlm_tool(8)

text:
# dlm_tool(8)

## NAME
dlm_tool - a utility for the dlm and dlm_controld daemon

## SYNOPSIS
dlm_tool [COMMAND] [OPTIONS] [ name ]

## COMMANDS
ls

Display dlm_controld internal lockspace state.

status

Dump dlm_controld daemon state.

dump

Dump dlm_controld debug buffer.

dump_config

Dump dlm_controld config settings.

reload_config

Reload dlm_controld config settings from dlm.conf.

set_config setting=value

Set dlm_controld config settings in the currently running daemon.

fence_ack nodeid

Cancel a waiting fencing operation and consider it successful.

log_plock

Dump dlm_controld plock debug buffer.

plocks lockspace_name

Dump posix locks from dlm_controld for the lockspace.

join lockspace_name

Join a lockspace.

leave lockspace_name

Leave a lockspace.

joinleave lockspace_name

Join then immediately leave a lockspace (for testing only.)

lockdebug lockspace_name

Complete display of locks from the lockspace.

lockdump lockspace_name

Minimal display of locks from the lockspace (deprecated).

run command

Run command and check for result (for lvmlockd only.)

run_start command

Run command and don't check for result.

run_check uuid

Check status of a command that was run.

run_cancel uuid

Cancel a command that was run and is not yet done.

run_list

Dump a list of running commands.

## OPTIONS
-n Show all node information from dlm_tool ls.

-d 0|1 Resource directory off/on in join, default 0

-e 0|1 Exclusive create off/on in join, default 0

-f 0|1 FS (filesystem) flag off/on in join, default 0

-i sec Seconds to wait in run_check.

-m mode Permission mode for lockspace device (octal), default 0600

-s Summary following lockdebug output (experiemental)

-v Verbose lockdebug or status output

-w Wide lockdebug output

-M Include MSTCPY locks in lockdump output

-h Print help, then exit

-V Print program version information, then exit

## USAGE

### fence_ack
See dlm_tool status for information about waiting fencing operations for specific nodeid's.

### set_config
dlm_tool set_config can change certain config settings in the currently running dlm_controld. Supported options:

```
daemon_debug
log_debug
debug_logfile
plock_debug
plock_rate_limit
drop_resources_time
drop_resources_count
drop_resources_age
post_join_delay
enable_quorum_fencing
enable_quorum_lockspace
repeat_failed_fencing
```

Special cases to revert a previous set_config and restore the previous value (from default or dlm.conf):

dlm_tool set_config setting=restore

restores a single setting.

dlm_tool set_config restore_all

restores all settings.

### dump_config
A config setting may have been set from: the default, the dlm_controld command line, dlm.conf at startup, dlm.conf from reload_config, dlm_tool set_config. The dump_config output indicates how values were set:

setting=value

default value.

setting=value (cli option)

Set from a dlm_controld command line option.

setting=value (dlm.conf)

Set from dlm.conf (at startup or reload.)

setting=value (set_config)

Set from dlm_tool set_config.

## EXAMPLES

### dump_config

```
$ dlm_tool dump_config | head -n 5
daemon_debug=1 (set_config)
foreground=0
log_debug=1 (dlm.conf)
protocol=detect
```

In this case, daemon_debug is set by set_config, log_debug is set from dlm.conf, foreground and protocol are using default values.

### set_config

```
$ dlm_tool dump_config | grep log_debug
log_debug=1 (dlm.conf)
$ dlm_tool set_config "log_debug=0"
set_config done
$ dlm_tool dump_config | grep log_debug
log_debug=0 (set_config)
$ dlm_tool set_config "log_debug=restore"
set_config done
$ dlm_tool dump_config | grep log_debug
log_debug=1 (dlm.conf)
```

log_debug is set by dlm.conf (value is 1), then run set_config to change to 0, then use restore to restore to dlm.conf setting.

### set_config

```
$ dlm_tool dump_config | grep _debug
daemon_debug=0
log_debug=1 (dlm.conf)
plock_debug=0
$ dlm_tool set_config "daemon_debug=1 log_debug=1 plock_debug=1"
set_config done
$ dlm_tool dump_config | grep _debug
daemon_debug=1 (set_config)
log_debug=1 (set_config)
plock_debug=1 (set_config)
$ dlm_tool set_config "restore_all"
set_config done
$ dlm_tool dump_config | grep _debug
daemon_debug=0
log_debug=1 (dlm.conf)
plock_debug=0
```

## SEE ALSO
dlm_controld(8), dlm.conf(5)


biosdecode

package: dmidecode

title: biosdecode(8)

summary: \s-1BIOS\s0 information decoder

text:
# biosdecode(8)

## NAME
biosdecode - BIOS information decoder

## SYNOPSIS
biosdecode [OPTIONS]

## DESCRIPTION
biosdecode parses the BIOS memory and prints information about all structures (or entry points) it knows of. Currently known entry point types are:

- SMBIOS (System Management BIOS)

Use dmidecode for a more detailed output.

- DMI (Desktop Management Interface, a legacy version of SMBIOS)

Use dmidecode for a more detailed output.

- SYSID

- PNP (Plug and Play)

- ACPI (Advanced Configuration and Power Interface)

- BIOS32 (BIOS32 Service Directory)

- PIR (PCI IRQ Routing)

- 32OS (BIOS32 Extension, Compaq-specific)

See ownership for a Compaq ownership tag retrieval tool.

- SNY (Sony-specific, not decoded)

- VPD (Vital Product Data, IBM-specific)

Use vpddecode for a more detailed output.

- FJKEYINF (Application Panel, Fujitsu-specific)

biosdecode started its life as a part of dmidecode but as more entry point types were added, it was moved to a different program.

## OPTIONS
-d, --dev-mem FILE

Read memory from device FILE (default: /dev/mem)

--pir full

Decode the details of the PCI IRQ routing table. Only full mode is supported.

-h, --help

Display usage information and exit

-V, --version

Display the version and exit

## FILES
/dev/mem

## BUGS
Most of the time, biosdecode prints too much information (you don't really care about addresses) or not enough (because it doesn't follow pointers and has no lookup tables).

## AUTHORS
Alan Cox, Jean Delvare

## SEE ALSO
dmidecode(8), mem(4), ownership(8), vpddecode(8)


dmidecode

title: dmidecode(8)

summary: \s-1DMI\s0 table decoder

text:
# dmidecode(8)

## NAME
dmidecode - DMI table decoder

## SYNOPSIS
dmidecode [OPTIONS]

## DESCRIPTION
dmidecode is a tool for dumping a computer's DMI (some say SMBIOS) table contents in a human-readable format. This table contains a description of the system's hardware components, as well as other useful pieces of information such as serial numbers and BIOS revision. Thanks to this table, you can retrieve this information without having to probe for the actual hardware. While this is a good point in terms of report speed and safeness, this also makes the presented information possibly unreliable.

The DMI table doesn't only describe what the system is currently made of, it also can report the possible evolutions (such as the fastest supported CPU or the maximal amount of memory supported).

SMBIOS stands for System Management BIOS, while DMI stands for Desktop Management Interface. Both standards are tightly related and developed by the DMTF (Desktop Management Task Force).

As you run it, dmidecode will try to locate the DMI table. It will first try to read the DMI table from sysfs, and next try reading directly from memory if sysfs access failed. If dmidecode succeeds in locating a valid DMI table, it will then parse this table and display a list of records like this one:

Handle 0x0002, DMI type 2, 8 bytes. Base Board Information

Manufacturer: Intel

Product Name: C440GX+

Version: 727281-001

Serial Number: INCY92700942

Each record has:

- A handle. This is a unique identifier, which allows records to reference each other. For example, processor records usually reference cache memory records using their handles.

- A type. The SMBIOS specification defines different types of elements a computer can be made of. In this example, the type is 2, which means that the record contains "Base Board Information".

- A size. Each record has a 4-byte header (2 for the handle, 1 for the type, 1 for the size), the rest is used by the record data. This value doesn't take text strings into account (these are placed at the end of the record), so the actual length of the record may be (and is often) greater than the displayed value.

- Decoded values. The information presented of course depends on the type of record. Here, we learn about the board's manufacturer, model, version and serial number.

## OPTIONS
-d, --dev-mem FILE

Read memory from device FILE (default: /dev/mem)

-q, --quiet

Be less verbose. Unknown, inactive and OEM-specific entries are not displayed. Meta-data and handle references are hidden.

--no-quirks

Decode everything exactly as it is in the table, without trying to fix up common mistakes or hide irrelevant fields. This mode is primarily aimed at firmware developers.

-s, --string KEYWORD

Only display the value of the DMI string identified by KEYWORD. It must be a keyword from the following list: bios-vendor, bios-version, bios-release-date, bios-revision, firmware-revision, system-manufacturer, system-product-name, system-version, system-serial-number, system-uuid, system-sku-number, system-family, baseboard-manufacturer, baseboard-product-name, baseboard-version, baseboard-serial-number, baseboard-asset-tag, chassis-manufacturer, chassis-type, chassis-version, chassis-serial-number, chassis-asset-tag, processor-family, processor-manufacturer, processor-version, processor-frequency. Each keyword corresponds to a given DMI type and a given offset within this entry type. Not all strings may be meaningful or even defined on all systems. Some keywords may return more than one result on some systems (e.g. processor-version on a multi-processor system). If KEYWORD is not provided or not valid, a list of all valid keywords is printed and dmidecode exits with an error. This option cannot be used more than once. Note: on Linux, most of these strings can alternatively be read directly from sysfs, typically from files under /sys/devices/virtual/dmi/id. Most of these files are even readable by regular users.

--list-strings

List available string keywords, which can then be passed to the --string option.

-t, --type TYPE

Only display the entries of type TYPE. It can be either a DMI type number, or a comma-separated list of type numbers, or a keyword from the following list: bios, system, baseboard, chassis, processor, memory, cache, connector, slot. Refer to the DMI TYPES section below for details. If this option is used more than once, the set of displayed entries will be the union of all the given types. If TYPE is not provided or not valid, a list of all valid keywords is printed and dmidecode exits with an error.

--list-types

List available type keywords, which can then be passed to the --type option.

-H, --handle HANDLE

Only display the entry whose handle matches HANDLE. HANDLE is a 16-bit integer.

-u, --dump

Do not decode the entries, dump their contents as hexadecimal instead. Note that this is still a text output, no binary data will be thrown upon you. The strings attached to each entry are displayed as both hexadecimal and ASCII. This option is mainly useful for debugging.

--dump-bin FILE

Do not decode the entries, instead dump the DMI data to a file in binary form. The generated file is suitable to pass to --from-dump later. FILE must not exist.

--from-dump FILE

Read the DMI data from a binary file previously generated using --dump-bin.

--no-sysfs

Do not attempt to read DMI data from sysfs files. This is mainly useful for debugging.

--oem-string N

Only display the value of the OEM string number N. The first OEM string has number 1. With special value count, return the number of OEM strings instead.

-h, --help

Display usage information and exit

-V, --version

Display the version and exit

Options --string, --type, --dump-bin and --oem-string determine the output format and are mutually exclusive.

Please note in case of dmidecode is run on a system with BIOS that boasts new SMBIOS specification, which is not supported by the tool yet, it will print out relevant message in addition to requested data on the very top of the output. Thus informs the output data is not reliable.

## DMI TYPES
The SMBIOS specification defines the following DMI types:

Type

Information

0

BIOS

1

System

2

Baseboard

3

Chassis

4

Processor

5

Memory Controller

6

Memory Module

7

Cache

8

Port Connector

9

System Slots

10

On Board Devices

11

OEM Strings

12

System Configuration Options

13

BIOS Language

14

Group Associations

15

System Event Log

16

Physical Memory Array

17

Memory Device

18

32-bit Memory Error

19

Memory Array Mapped Address

20

Memory Device Mapped Address

21

Built-in Pointing Device

22

Portable Battery

23

System Reset

24

Hardware Security

25

System Power Controls

26

Voltage Probe

27

Cooling Device

28

Temperature Probe

29

Electrical Current Probe

30

Out-of-band Remote Access

31

Boot Integrity Services

32

System Boot

33

64-bit Memory Error

34

Management Device

35

Management Device Component

36

Management Device Threshold Data

37

Memory Channel

38

IPMI Device

39

Power Supply

40

Additional Information

41

Onboard Devices Extended Information

42

Management Controller Host Interface

Additionally, type 126 is used for disabled entries and type 127 is an end-of-table marker. Types 128 to 255 are for OEM-specific data. dmidecode will display these entries by default, but it can only decode them when the vendors have contributed documentation or code for them.

Keywords can be used instead of type numbers with --type. Each keyword is equivalent to a list of type numbers:

Keyword

Types

bios

0, 13

system

1, 12, 15, 23, 32

baseboard

2, 10, 41

chassis

3

processor

4

memory

5, 6, 16, 17

cache

7

connector

8

slot

9

Keywords are matched case-insensitively. The following command lines are equivalent:

- dmidecode --type 0 --type 13

- dmidecode --type 0,13

- dmidecode --type bios

- dmidecode --type BIOS

## BINARY DUMP FILE FORMAT
The binary dump files generated by --dump-bin and read using --from-dump are formatted as follows:

- The SMBIOS or DMI entry point is located at offset 0x00. It is crafted to hard-code the table address at offset 0x20.

- The DMI table is located at offset 0x20.

## UUID FORMAT
There is some ambiguity about how to interpret the UUID fields prior to SMBIOS specification version 2.6. There was no mention of byte swapping, and RFC 4122 says that no byte swapping should be applied by default. However, SMBIOS specification version 2.6 (and later) explicitly states that the first 3 fields of the UUID should be read as little-endian numbers (byte-swapped). Furthermore, it implies that the same was already true for older versions of the specification, even though it was not mentioned. In practice, many hardware vendors were not byte-swapping the UUID. So, in order to preserve compatibility, it was decided to interpret the UUID fields according to RFC 4122 (no byte swapping) when the SMBIOS version is older than 2.6, and to interpret the first 3 fields as little-endian (byte-swapped) when the SMBIOS version is 2.6 or later. The Linux kernel follows the same logic.

## FILES
/dev/mem

/sys/firmware/dmi/tables/smbios_entry_point (Linux only)

/sys/firmware/dmi/tables/DMI (Linux only)

## BUGS
More often than not, information contained in the DMI tables is inaccurate, incomplete or simply wrong.

## AUTHORS
Alan Cox, Jean Delvare

## SEE ALSO
biosdecode(8), mem(4), ownership(8), vpddecode(8)


ownership

title: ownership(8)

summary: Compaq ownership tag retriever

text:
# ownership(8)

## NAME
ownership - Compaq ownership tag retriever

## SYNOPSIS
ownership [OPTIONS]

## DESCRIPTION
ownership retrieves and prints the "ownership tag" that can be set on Compaq computers. Contrary to all other programs of the dmidecode package, ownership doesn't print any version information, nor labels, but only the raw ownership tag. This should help its integration in scripts.

## OPTIONS
-d, --dev-mem FILE

Read memory from device FILE (default: /dev/mem)

-h, --help

Display usage information and exit

-V, --version

Display the version and exit

## FILES
/dev/mem

## AUTHOR
Jean Delvare

## SEE ALSO
biosdecode(8), dmidecode(8), mem(4), vpddecode(8)


vpddecode

title: vpddecode(8)

summary: \s-1VPD\s0 structure decoder

text:
# vpddecode(8)

## NAME
vpddecode - VPD structure decoder

## SYNOPSIS
vpddecode [OPTIONS]

## DESCRIPTION
vpddecode prints the "vital product data" information that can be found in almost all IBM and Lenovo computers. Available items are:

- BIOS Build ID

- Box Serial Number

- Motherboard Serial Number

- Machine Type/Model

Some systems have these additional items:

- BIOS Release Date

- Default Flash Image File Name

Note that these additional items are not documented by IBM, so this is guess work, and as such should not be blindly trusted. Feedback about the accuracy of these labels is welcome.

## OPTIONS
-d, --dev-mem FILE

Read memory from device FILE (default: /dev/mem)

-s, --string KEYWORD

Only display the value of the VPD string identified by KEYWORD. It must be a keyword from the following list: bios-build-id, box-serial-number, motherboard-serial-number, machine-type-model, bios-release-date. Each keyword corresponds to an offset and a length within the VPD record. Not all strings may be defined on all VPD-enabled systems. If KEYWORD is not provided or not valid, a list of all valid keywords is printed and vpddecode exits with an error. This option cannot be used more than once. Mutually exclusive with --dump.

-u, --dump

Do not decode the VPD records, dump their contents as hexadecimal instead. Note that this is still a text output, no binary data will be thrown upon you. ASCII equivalent is displayed when possible. This option is mainly useful for debugging. Mutually exclusive with --string.

-h, --help

Display usage information and exit

-V, --version

Display the version and exit

## FILES
/dev/mem

## AUTHOR
Jean Delvare

## SEE ALSO
biosdecode(8), dmidecode(8), mem(4), ownership(8)


package: dmraid

title: dmevent_tool(8)

text:
# dmevent_tool(8)

## NAME
dmevent_tool - A utility used to load a DSO into dmeventd and (un)register devices with it for monitoring

## SYNOPSIS
dmevent_tool -[Vhmru] {RAID device name} {DSO Name}

## DESCRIPTION
dmevent_tool is a userspace utility used to register/unregister DSOs with the daemon dmeventd.

If used with the -m command line parameter users can display all of the actively dmeventd monitored devices.

## OPTIONS
-V Show version of dmevent_tool

-{h/?} Show this help information

-m[r|u] List all currently active device mapper devices

and their current status with dmeventd

for registered (-r)/unregistered (-m) devices

Syntax: dmevent_tool -m[u|r]

-a[r|u] Same as -m, but for devices with UUID only!

Syntax: dmevent_tool -a[u|r]

-r Register a device with dmeventd

Syntax: dmevent_tool -r <device name> <path to DSO library>

Example: dmevent_tool -r isw_abcdeh_Volume0 libdmraid-events.so

-u Unregister a device with dmeventd

Syntax: dmevent_tool -u <device name> [<path to DSO library>]

Example: dmevent_tool -u isw_abcdefgh_Volume0

## EXAMPLES
dmevent_tool -m is used to display all of the actively monitored devices

dmevent_tool -m

Device Name: isw_defeaigdde_Volume0_dmraid00

Registered DSO: libdmraid-events.so

UUID: isw_defeaigdde_Volume0_dmraid00

status: Active

major device #: 253

minor device #: 0

read only device: No

number of recorded kernel events: 0

SATA drives in this volume group: /dev/sdb /dev/sdc

dmevent_tool -r is used to register a volume group device with dmeventd

dmevent_tool -r isw_defeaigdde_Volume0_dmraid00 libdmraid-events.so

dmevent_tool -u is used to unregister a volume group from dmeventd

dmevent_tool -u isw_defeaigdde_Volume0_dmraid00

## DIAGNOSTICS
dmevent_tool returns an exit code of 0 for success or 1 for error.

## AUTHOR
Brian Wood <brian.j.wood@intel.com>


dmraid

title: dmraid(8)

text:
# dmraid(8)

## NAME
dmraid - discover, configure and activate software (ATA)RAID

## SYNOPSIS
dmraid

{-a|--activate} {y|n|yes|no}

[-d|--debug]... [-v|--verbose]... [-i|--ignorelocking]

[-f|--format FORMAT[,FORMAT...]]

[{-P|--partchar} CHAR]

[-p|--no_partitions]

[-Z|--rm_partitions]

[--separator SEPARATOR]

[-t|--test]

[-u|--update_defer]

[RAID-set...]

dmraid

{-b|--block_devices}

[-c|--display_columns][FIELD[,FIELD...]]...

[-d|--debug]... [-v|--verbose]...

[--separator SEPARATOR]

[device-path...]

dmraid

{-h|--help}

dmraid

{-l|--list_formats}

[-d|--debug]... [-v|--verbose]...

dmraid

{-n|--native_log}

[-d|--debug]... [-v|--verbose]... [-i|--ignorelocking]

[-f|--format FORMAT[,FORMAT...]]

[--separator SEPARATOR]

[device-path...]

dmraid

{-R| --rebuild}

RAID-set

[device-path]

[-u|--update_defer]

dmraid

{-x| --remove}

[RAID-set]

dmraid

-f FORMAT-handler {-C| --create} set

--type raidlevel

[--size=setsize --strip stridesize]

--disk "device-path, device-path [, device-path ...]"

dmraid [ -f|--format FORMAT-handler] -S|--spare [RAID-set] -M|--media "device-path"

dmraid

{-r|--raid_devices}

[-c|--display_columns][FIELD[,FIELD...]]...

[-d|--debug]... [-v|--verbose]... [-i|--ignorelocking]

[-D|--dump_metadata]

[-f|--format FORMAT[,FORMAT...]]

[--separator SEPARATOR]

[device-path...]

dmraid

{-r|--raid_devices}

[-d|--debug]... [-v|--verbose]... [-i|--ignorelocking]

[-E|--erase_metadata]

[-f|--format FORMAT[,FORMAT...]]

[--separator SEPARATOR]

[device-path...]

dmraid

{-s|--sets}...[a|i|active|inactive]

[-c|--display_columns][FIELD[,FIELD...]]...

[-d|--debug]... [-v|--verbose]... [-i|--ignorelocking]

[-f|--format FORMAT[,FORMAT...]]

[-g|--display_group]

[--separator SEPARATOR]

[RAID-set...]

dmraid

{-V/--version}

## DESCRIPTION
dmraid discovers block and software RAID devices (eg, ATARAID) by using multiple different metadata format handlers which support various formats (eg, Highpoint 37x series). It offers activating RAID sets made up by 2 or more discovered RAID devices, display properties of devices and sets (see option -l for supported metadata formats). Block device access to activated RAID sets occurs via device-mapper nodes /dev/mapper/RaidSetName. RaidSetName starts with the format name (see -l option) which can be used to access all RAID sets of a specific format easily with certain options (eg, -a below).

### OPTIONS
-a, --activate {y|n} [RAID set...]

Activates or deactivates all or particular software RAID set. In case metadata format handlers are chosen with -f , only RAID sets with such format(s) can be activated or deactivated. Useful if devices have multiple metadata signatures. When activating RAID sets, -p disables the activation of partitions on them, and -Z will make dmraid tell the kernel to remove the partitions from the disks underlying the set, ie if sda is part of the set, remove sda1, sda2, etc. This prevents applications from directly accessiong the disks bypassing dmraid. RAID set names given on command line don't need to be fully specified (eg, "dmraid -ay sil" would activate all discovered Silicon Image Medley RAID sets). Option -u defers metadata update in case of rebuild is triggered parallelly with activation. Awoids metadata update to "OK" state if volume is not registered to the event monitoring. Useful if volume is activating at early stage of booting process when registration to the event monitoring is impossible.

{-b|--block_devices} [device-path...]

List all or particular discovered block devices with their properties (size, serial number). Add -c to display block device names only and -cc for CSV column output of block device properties. See description of -c below for FIELD identifiers.

[-d|--debug]...

Enable debugging output. Opion can be given multiple times increasing the debug output level.

[-c|--display_columns][FIELD[,FIELD...]]...

Display properties of block devices, RAID sets and devices in column(s). Optional list specifying which FIELDs to display.

For -b:

d[evpath]|p[ath], sec[tors]|si[ze], ser[ialnumber].

For -r:

de[vpath]|p[ath], f[ormat], r[aidname], t[ype], st[atus], se[ctors]|si[ze], da[taoffset]|o[ffset].

For -s:

f[ormat], r[aidname], t[ype], sta[tus], str[ide], se[ctors]|si[ze], su[bsets], d[evices], sp[ares].

[-f|--format FORMAT[,FORMAT...]]

Use metadata format handler(s) to discover RAID devices. See -l for a list of supported format handler names. This is useful to select particular formats in case multiple metadata signatures are found on a device. A comma seperated list of format names can be specified which may not contain white space.

{-h|--help}

Display help text.

{-i|--ignorelocking}

Don't take out any locks. Useful in early boot where no read/write access to /var is available.

{-l|--list_formats}

List all available metadata format handlers with their names and descriptions. Supported RAID levels are listed in parenthesis: S: Span (concatination)

0: RAID0 (stripe)

1: RAID1 (mirror)

10: RAID10 (mirror on top of stripes)

01: RAID10 (stripe on top of mirrors) Note: Intel OROM displays this as RAID10

{-n|--native_log} [device-path...]

Display metadata in native, vendor-specific format. In case a metadata format handler is chosen with -f only RAID devices with such format will be displayed in native format. If device-path(s) is/are given on the command line, native metadata output is restricted to those listed.

[{-P|--partchar} CHAR]

Use CHAR as the separator between the device name and the partition number.

{-R| --rebuild} RAID-set [device-path]

Rebuild raid array after a drive has failed and a new drive is added. For Intel chipset based systems, there are two methods in which a new drive is added to the system. Option -u defers metadata update in case of rebuild is triggered. Awoids metadata update to "OK" state if volume is not registered to the event monitoring. 1. Using OROM to identify a new drive

During system reboot, enter OROM and mark the new drive as the rebuild drive.

After booting to the OS, use the dmraid command to rebuild.

Example: dmraid -R raid_set

2. Using dmraid to identify a new drive

Boot to the OS and use the dmraid command with the new drive as the second parameter.

Example: dmraid -R raid_set /dev/sdc

3. Using hot spare drive

Mark a drive as hot spare using the "dmraid -f isw -S" command. Then use the dmraid command to start the rebuild.

Example: dmraid -R raid_set

{-x|--remove} [RAID-set]

Delete one or all existing software RAID devices from the metadata.

-f FORMAT-handler {-C|--create} --type raidlevel [--size=setsize --strip stripsize] --disk device-path, device-path [,device-path]

Delete one or all existing Configure a software RAID device and store the configuration data in a group of hard drive devices consisting of this array. This command requires the following options: -f FORMAT-handler

metadata format (see "dmraid -l")

--type digit[digit...]

specify the raid level of the software RAID set.

0: raid0

1: raid1

5: raid5

01: raid01 (isw raid10)

--size: [digits[k|K|m|M|g|G][b|B]]

specify the size of the RAID set.The number is an integer followed by [kKmMgG] and/or [bB].

b: byte (default)

B: block (512 bytes)

K or K: on the base of 1024

m or M: on the base of 1024*1024

g or G: on the base of 1024*1024*1024

If this option is missing, it's set to the default value pre-configured by the vendor. Note that different vendors may apply different constraints on the granularity of the size or the minimal value.

--strip: [digits[k|K|m|M|g|G][b|B]]

specify the strip size of a RAID1, RAID5, and RAID10 RAID set (as above)

--disk: device-path[{,| }device-path...]

specify the array of the hard drives, e.g. /dev/sda.

-f FORMAT-handler -S -M device-path

-S -M device-path This command adds hot spare support for one or more RAID sets.

1. When used with a format handler, which supports hot spare sets (e.g. isw), a hot spare is marked to be used when rebuilding any RAID set of that format. 2. When used when specifying a RAID set, the drive is added to that RAID set and will be used only to rebuild that set. Note: If the specified name does not match an existing RAID-set, a set with the new name will be created.

{-r|--raid_devices} [device-path...]

List all discovered RAID devices with format, RAID level, sectors used and data offset into the device. In case a metadata format handler is chosen with -f , only RAID devices with such format can be discovered. Useful if devices have multiple metadata signatures. If -D is added to -r the RAID metadata gets dumped into a subdirectory named dmraid.format_name (eg. format_name = isw) in files named devicename.dat. The byte offset where the metadata is located on the device is written into files named devicename.offset and the size of the device in sectors into files named devicename.size. If -E is added to -r the RAID metadata on the devices gets conditionally erased. Useful to erase old metadata after new one of different type has been stored on a device in order to avoid discovering both. If you enter -E option -D will be enforced in order to have a fallback in case the wrong metadata got erased. Manual copying back onto the device is needed to recover from erasing the wrong metadata using the dumped files devicename_formatname.dat and devicename_formatname.offset. Eg, to restore all *.dat files in the working directory to the respective devices:

for f in *.dat

do

dd if=$f of=/dev/${f%%.dat} \

seek=`cat ${f%%dat}offset` bs=1

done

If device-path(s) is/are given on the command line, the above actions are restricted to those listed. Add -c to display RAID device names only and -cc for CSV column output of RAID device properties. See description of -c above for FIELD identifiers.

--separator SEPARATOR

Use SEPARATOR as a delimiter for all options taking or displaying lists.

-s... [a|i] [RAID-set...]

Display properties of RAID sets. Multiple RAID set names can be given on the command line which don't need to be fully specified (eg, "dmraid -s hpt" would display all discovered Highpoint RAID sets). Enter -s twice to display RAID subsets too. Add -c to display names of RAID sets only, -cc for CSV column output of RAID set properties and -ccc for inclusion of block devices in the listing. Doesn't imply -s -s to show RAID subsets (implied for group sets, e.g. isw). Add -g to include information about group RAID sets (as with Intel Software RAID) in the listing. See description of -c above for FIELD identifiers. Note: Size is given in sectors (not bytes).

[-v|--verbose]...

Enable verbose runtime information output. Opion can be given multiple times increasing the verbosity level.

## EXAMPLES
"dmraid -l" lists all supported metadata formats with their names along with some descriptive information, eg:

hpt37x : (+) Highpoint HPT37X

hpt45x : (+) Highpoint HPT45X

isw : (+) Intel Software RAID

lsi : (0) LSI Logic MegaRAID

nvidia : (+) NVidia RAID

pdc : (+) Promise FastTrack

sil : (+) Silicon Image(tm) Medley(tm)

via : (+) VIA Software RAID

dos : (+) DOS partitions on SW RAIDs

(0): Discover, (+): Discover+Activate

"dmraid -ay" activates all software RAID sets discovered.

"dmraid -an" deactivates all active software RAID sets which are not open (eg, mounted filesystem on them).

"dmraid -ay -f pdc" (pdc looked up from "dmraid -l") activates all software RAID sets with Promise format discovered and ignores all other supported formats.

"dmraid -r" discovers all software RAID devices supported on your system, eg:

/dev/dm-46: hpt45x, "hpt45x_chidjhaiaa-0", striped, ok, 320172928 sectors, data@ 0

/dev/dm-50: hpt45x, "hpt45x_chidjhaiaa-0", striped, ok, 320172928 sectors, data@ 0

/dev/dm-54: hpt45x, "hpt45x_chidjhaiaa-1", striped, ok, 320172928 sectors, data@ 0

/dev/dm-58: hpt45x, "hpt45x_chidjhaiaa-1", striped, ok, 320172928 sectors, data@ 0

"dmraid -s -s hpt45x_chidjhaiaa" displays properties of set "hpt45x_chidjhaiaa", eg:

*** Superset

name : hpt45x_chidjhaiaa

size : 640345856

stride : 128

type : raid10

status : ok

subsets: 2

dev : 4

spare : 0

---> Subset

name : hpt45x_chidjhaiaa-0

size : 640345856

stride : 128

type : stripe

status : ok

subsets: 0

dev : 2

spare : 0

---> Subset

name : hpt45x_chidjhaiaa-1

size : 640345856

stride : 128

type : stripe

status : ok

subsets: 0

dev : 2

spare : 0

"dmraid -s -ccs hpt45" displays properties in column format of all sets and subsets with hpt45* format, eg:

hpt45x_chidjhaiaa,640345856,128,raid10,ok,4,0

hpt45x_chidjhaiaa-a,640345856,128,stripe,ok,2,0

hpt45x_chidjhaiaa-b,640345856,128,stripe,ok,2,0

"dmraid -r --sep : -cpath:size" display paths and sizes in sectors for RAID devices in column format using ':' as a delimiter, eg:

/dev/dm-8:320173055

/dev/dm-12:320173055

/dev/dm-22:320173055

/dev/dm-26:320173055

/dev/dm-30:586114703

/dev/dm-34:586114703

/dev/dm-38:586114703

/dev/dm-42:586114703

/dev/dm-46:156301487

/dev/dm-50:156301487

/dev/dm-54:390624896

/dev/dm-58:390624896

/dev/dm-62:390624896

/dev/dm-66:390624896

"dmraid -f isw -C Raid0 --type 0 --strip 8k --size 20g --disk "/dev/sdb /dev/sdc"" creates an ISW volume with a name of "Raid0", 20Gig bytes in total, and 8kilo bytes strip size on two disks.

"dmraid -f isw -C Test0 --type 0 --disk "/dev/sdd /dev/sde"" creates an ISW volume with the default size and strip size.

"dmraid -f isw -C Test10 --type 01 --strip 128B --disk "/dev/sda /dev/sdb /dev/sdc /dev/sdd" creates a stacked RAID device, RAID10 (isw format), with a name of "Test10", 128 blocks (512bytes) strip size , and the default volume size on 4 disks.

"dmraid -f isw -S -M /dev/sde" marks the device /dev/sde as a hot spare for rebuild

"dmraid -R isw_djaggchdde_RAID1 /dev/sde" starts rebuild of the RAID volume on device /dev/sde

## DIAGNOSTICS
dmraid returns an exit code of 0 for success or 1 for error.

## AUTHOR
Heinz Mauelshagen <Mauelshagen@RedHat.com>


dmsdosfsck

package: dmsdos

title: dmsdosfsck(8)

summary: dmsdos filesystem checker

text:
# dmsdosfsck(8)

## NAME
dmsdosfsck - dmsdos filesystem checker

## SYNOPSIS
dmsdosfsck [-aflrtvVw] [-d path -d ...] [-u path -u ...] filename

## DESCRIPTION
dmsdosfsck checks the CVF located in filename for errors and optionally tries to repair errors. It is command-line compatible with dosfsck(8).

-a automatically repair the file system

-d path (*) drop that file

-f (*) salvage unused chains to files

-l list path names

-r interactively repair the file system

-t (*) test for bad clusters

-u path (*) try to undelete that (non-directory) file

-v verbose mode

-V (*) perform a verification pass

-w (*) write changes to disk immediately

(*) not yet implemented but option accepted for dosfsck compatibility

## BUGS
dmsdosfsck is not yet complete. Be extremely careful with repairs.

It is strongly recommended to let only the native CVF management tools that came with your CVF software package do any repairs. Use dmsdosfsck only to check (which is a read-only operation).

## SEE ALSO
Refer to the dmsdos main documentation for further information.


blkdeactivate

package: dmsetup

title: blkdeactivate(8)

summary: utility to deactivate block devices

text:
# blkdeactivate(8)

## NAME
blkdeactivate — utility to deactivate block devices

## SYNOPSIS
blkdeactivate [-d dm_options] [-e] [-h] [-l lvm_options] [-m mpath_options] [-r mdraid_options] [-o vdo_options] [-u] [-v] [device]

## DESCRIPTION
The blkdeactivate utility deactivates block devices. For mounted block devices, it attempts to unmount it automatically before trying to deactivate. The utility currently supports device-mapper devices (DM), including LVM volumes and software RAID MD devices. LVM volumes are handled directly using the lvm(8) command, the rest of device-mapper based devices are handled using the dmsetup(8) command. MD devices are handled using the mdadm(8) command.

## OPTIONS
-d|--dmoptions dm_options

Comma separated list of device-mapper specific options. Accepted dmsetup(8) options are:

retry

Retry removal several times in case of failure.

force

Force device removal.

-e|--errors

Show errors reported from tools called by blkdeactivate. Without this option, any error messages from these external tools are suppressed and the blkdeactivate itself provides only a summary message to indicate the device was skipped.

-h|--help

Display the help text.

-l|--lvmoptions lvm_options

Comma-separated list of LVM specific options:

retry

Retry removal several times in case of failure.

wholevg

Deactivate the whole LVM Volume Group when processing a Logical Volume. Deactivating the Volume Group as a whole is quicker than deactivating each Logical Volume separately.

-r|--mdraidoptions mdraid_options

Comma-separated list of MD RAID specific options:

wait

Wait MD device's resync, recovery or reshape action to complete before deactivation.

-m|--mpathoptions mpath_options

Comma-separated list of device-mapper multipath specific options:

disablequeueing

Disable queueing on all multipath devices before deactivation. This avoids a situation where blkdeactivate may end up waiting if all the paths are unavailable for any underlying device-mapper multipath device.

-o|--vdooptions vdo_options

Comma-separated list of VDO specific options:

configfile=file

Use specified VDO configuration file.

-u|--umount

Unmount a mounted device before trying to deactivate it. Without this option used, a device that is mounted is not deactivated.

-v, --verbose

Run in verbose mode. Use -vv for even more verbose mode.

## EXAMPLES
Deactivate all supported block devices found in the system, skipping mounted devices.

\# blkdeactivate

Deactivate all supported block devices found in the system, unmounting any mounted devices first, if possible.

\# blkdeactivate -u

Deactivate the device /dev/vg/lvol0 together with all its holders, unmounting any mounted devices first, if possible.

\# blkdeactivate -u /dev/vg/lvol0

Deactivate all supported block devices found in the system. If the deactivation of a device-mapper device fails, retry it. Deactivate the whole Volume Group at once when processing an LVM Logical Volume.

\# blkdeactivate -u -d retry -l wholevg

Deactivate all supported block devices found in the system. If the deactivation of a device-mapper device fails, retry it and force removal.

\# blkdeactivate -d force,retry

## SEE ALSO
dmsetup(8), lsblk(8), lvm(8), mdadm(8), multipathd(8), vdo(8), umount(8)


dmsetup

title: dmsetup(8)

summary: low level logical volume management

text:
# dmsetup(8)

## NAME
dmsetup — low level logical volume management

## SYNOPSIS
dmsetup clear device_name

dmsetup create device_name [-n|--notable|--table table|table_file] [--readahead [+]sectors|auto|none] [-u|--uuid uuid] [--addnodeoncreate|--addnodeonresume]

dmsetup create --concise [concise_device_specification]

dmsetup deps [-o options] [device_name...]

dmsetup help [-c|-C|--columns]

dmsetup info [device_name...]

dmsetup info -c|-C|--columns [--count count] [--interval seconds] [--noheadings|--headings] [-o fields] [-O|--sort sort_fields] [--nameprefixes] [--separator separator] [device_name]

dmsetup load device_name [--table table|table_file]

dmsetup ls [--target target_type] [-o options] [--exec command] [--tree]

dmsetup mangle [device_name...]

dmsetup measure [device_name...]

dmsetup message device_name sector message

dmsetup mknodes [device_name...]

dmsetup reload device_name [--table table|table_file]

dmsetup remove [-f|--force] [--retry] [--deferred] device_name...

dmsetup remove_all [-f|--force] [--deferred]

dmsetup rename device_name new_name

dmsetup rename device_name --setuuid uuid

dmsetup resume device_name... [--addnodeoncreate|--addnodeonresume] [--noflush] [--nolockfs] [--readahead [+]sectors|auto|none]

dmsetup setgeometry device_name cyl head sect start

dmsetup splitname device_name [subsystem]

dmsetup stats command [options]

dmsetup status [--target target_type] [--noflush] [device_name...]

dmsetup suspend [--nolockfs] [--noflush] device_name...

dmsetup table [--concise] [--target target_type] [--showkeys] [device_name...]

dmsetup targets

dmsetup udevcomplete cookie

dmsetup udevcomplete_all [age_in_minutes]

dmsetup udevcookie

dmsetup udevcreatecookie

dmsetup udevflags cookie

dmsetup udevreleasecookie [cookie]

dmsetup version

dmsetup wait [--noflush] device_name [event_nr]

dmsetup wipe_table device_name... [-f|--force] [--noflush] [--nolockfs]

devmap_name major minor

devmap_name major:minor

## DESCRIPTION
dmsetup manages logical devices that use the device-mapper driver. Devices are created by loading a table that specifies a target for each sector (512 bytes) in the logical device.

The first argument to dmsetup is a command. The second argument is the logical device name or uuid.

Invoking the dmsetup tool as devmap_name (which is not normally distributed and is supported only for historical reasons) is equivalent to dmsetup info -c --noheadings -j major -m minor.

## OPTIONS
--addnodeoncreate

Ensure /dev/mapper node exists after dmsetup create.

--addnodeonresume

Ensure /dev/mapper node exists after dmsetup resume (default with udev).

--checks

Perform additional checks on the operations requested and report potential problems. Useful when debugging scripts. In some cases these checks may slow down operations noticeably.

-c|-C|--columns

Display output in columns rather than as Field: Value lines.

--count count

Specify the number of times to repeat a report. Set this to zero continue until interrupted. The default interval is one second.

-f|--force

Try harder to complete operation.

-h|--help

Outputs a summary of the commands available, optionally including the list of report fields (synonym with help command).

--inactive

When returning any table information from the kernel report on the inactive table instead of the live table. Requires kernel driver version 4.16.0 or above.

--interval seconds

Specify the interval in seconds between successive iterations for repeating reports. If --interval is specified but --count is not, reports will continue to repeat until interrupted. The default interval is one second.

--manglename auto|hex|none

Mangle any character not on a whitelist using mangling_mode when processing device-mapper device names and UUIDs. The names and UUIDs are mangled on input and unmangled on output where the mangling mode is one of: auto (only do the mangling if not mangled yet, do nothing if already mangled, error on mixed), hex (always do the mangling) and none (no mangling). Default mode is auto. Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also supported by udev. Any character not on a whitelist is replaced with its hex value (two digits) prefixed by \x. Mangling mode could be also set through DM_DEFAULT_NAME_MANGLING_MODE environment variable.

-j|--major major

Specify the major number.

-m|--minor minor

Specify the minor number.

-n|--notable

When creating a device, don't load any table.

--nameprefixes

Add a "DM_" prefix plus the field name to the output. Useful with --noheadings to produce a list of field=value pairs that can be used to set environment variables (for example, in udev(7) rules).

--noheadings

Suppress the headings line when using columnar output.

--headings none|abbrev|full|0|1|2

Type of headings line to use for columnar output. none or 0: No headings. abbrev or 1: Column name abbreviations. full or 2: Full column names.

--noflush

Do not flush outstanding I/O when suspending a device, or do not commit thin-pool metadata when obtaining thin-pool status.

--nolockfs

Do not attempt to synchronize filesystem eg, when suspending a device.

--noopencount

Tell the kernel not to supply the open reference count for the device.

--noudevrules

Do not allow udev to manage nodes for devices in device-mapper directory.

--noudevsync

Do not synchronize with udev when creating, renaming or removing devices.

-o|--options options

Specify which fields to display.

--readahead [+]sectors|auto|none

Specify read ahead size in units of sectors. The default value is auto which allows the kernel to choose a suitable value automatically. The + prefix lets you specify a minimum value which will not be used if it is smaller than the value chosen by the kernel. The value none is equivalent to specifying zero.

-r|--readonly

Set the table being loaded read-only.

-S|--select selection

Process only items that match selection criteria. If the command is producing report output, adding the "selected" column (-o selected) displays all rows and shows 1 if the row matches the selection and 0 otherwise. The selection criteria are defined by specifying column names and their valid values while making use of supported comparison operators. As a quick help and to see full list of column names that can be used in selection and the set of supported selection operators, check the output of dmsetup info -c -S help command.

--table table

Specify a one-line table directly on the command line. See below for more information on the table format.

--udevcookie cookie

Use cookie for udev synchronization. Note: Same cookie should be used for same type of operations i.e. creation of multiple different devices. It's not advised to combine different operations on the single device.

-u|--uuid uuid

Specify the uuid.

-y|--yes

Answer yes to all prompts automatically.

-v|--verbose [-v|--verbose]

Produce additional output.

--verifyudev

If udev synchronization is enabled, verify that udev operations get performed correctly and try to fix up the device nodes afterwards if not.

--version

Display the library and kernel driver version.

## COMMANDS
clear device_name

Destroys the table in the inactive table slot for device_name.

create device_name [-n|--notable|--table table|table_file] [--readahead [+]sectors|auto|none] [-u|--uuid uuid] [--addnodeoncreate|--addnodeonresume]

Creates a device with the given name. If table or table_file is supplied, the table is loaded and made live. Otherwise a table is read from standard input unless --notable is used. The optional uuid can be used in place of device_name in subsequent dmsetup commands. If successful the device will appear in table and for live device the node /dev/mapper/device_name is created. See below for more information on the table format.

create --concise [concise_device_specification]

Creates one or more devices from a concise device specification. Each device is specified by a comma-separated list: name, uuid, minor number, flags, comma-separated table lines. Flags defaults to read-write (rw) or may be read-only (ro). Uuid, minor number and flags are optional so those fields may be empty. A semi-colon separates specifications of different devices. Use a backslash to escape the following character, for example a comma or semi-colon in a name or table. See also CONCISE FORMAT below.

deps [-o options] [device_name...]

Outputs a list of devices referenced by the live table for the specified device. Device names on output can be customised by following options: devno (major and minor pair, used by default), blkdevname (block device name), devname (map name for device-mapper devices, equal to blkdevname otherwise).

help [-c|-C|--columns]

Outputs a summary of the commands available, optionally including the list of report fields.

info [device_name...]

Outputs some brief information about the device in the form:

State: SUSPENDED|ACTIVE, READ-ONLY

Tables present: LIVE and/or INACTIVE

Open reference count

Last event sequence number (used by wait)

Major and minor device number

Number of targets in the live table

UUID

info -c|-C|--columns [--count count] [--interval seconds] [--noheadings|--headings] [-o fields] [-O|--sort sort_fields] [--nameprefixes] [--separator separator] [device_name]

Output you can customise. Fields are comma-separated and chosen from the following list: name, major, minor, attr, open, segments, events, uuid. Attributes are: (L)ive, (I)nactive, (s)uspended, (r)ead-only, read-(w)rite. Precede the list with '+' to append to the default selection of columns instead of replacing it. Precede any sort field with '-' for a reverse sort on that column.

ls [--target target_type] [-o options] [--exec command] [--tree]

List device names. Optionally only list devices that have at least one target of the specified type. Optionally execute a command for each device. The device name is appended to the supplied command. Device names on output can be customised by following options: devno (major and minor pair, used by default), blkdevname (block device name), devname (map name for device-mapper devices, equal to blkdevname otherwise). --tree displays dependencies between devices as a tree. It accepts a comma-separate list of options. Some specify the information displayed against each node: device/nodevice; blkdevname; active, open, rw, uuid. Others specify how the tree is displayed: ascii, utf, vt100; compact, inverted, notrunc.

load|reload device_name [--table table|table_file]

Loads table or table_file into the inactive table slot for device_name. If neither is supplied, reads a table from standard input.

mangle [device_name...]

Ensure existing device-mapper device_name and UUID is in the correct mangled form containing only whitelisted characters (supported by udev) and do a rename if necessary. Any character not on the whitelist will be mangled based on the --manglename setting. Automatic rename works only for device names and not for device UUIDs because the kernel does not allow changing the UUID of active devices. Any incorrect UUIDs are reported only and they must be manually corrected by deactivating the device first and then reactivating it with proper mangling mode used (see also --manglename).

measure [device_name...]

Show the data that device_name would report to the IMA subsystem if a measurement was triggered at the current time. This is for debugging and does not actually trigger a measurement.

message device_name sector message

Send message to target. If sector not needed use 0.

mknodes [device_name...]

Ensure that the node in /dev/mapper for device_name is correct. If no device_name is supplied, ensure that all nodes in /dev/mapper correspond to mapped devices currently loaded by the device-mapper kernel driver, adding, changing or removing nodes as necessary.

remove [-f|--force] [--retry] [--deferred] device_name...

Removes a device. It will no longer be visible to dmsetup. Open devices cannot be removed, but adding --force will replace the table with one that fails all I/O. --deferred will enable deferred removal of open devices - the device will be removed when the last user closes it. The deferred removal feature is supported since version 4.27.0 of the device-mapper driver available in upstream kernel version 3.13. (Use dmsetup version to check this.) If an attempt to remove a device fails, perhaps because a process run from a quick udev rule temporarily opened the device, the --retry option will cause the operation to be retried for a few seconds before failing. Do NOT combine --force and --udevcookie, as udev may start to process udev rules in the middle of error target replacement and result in nondeterministic result.

remove_all [-f|--force] [--deferred]

Attempts to remove all device definitions i.e. reset the driver. This also runs mknodes afterwards. Use with care! Open devices cannot be removed, but adding --force will replace the table with one that fails all I/O. --deferred will enable deferred removal of open devices - the device will be removed when the last user closes it. The deferred removal feature is supported since version 4.27.0 of the device-mapper driver available in upstream kernel version 3.13.

rename device_name new_name

Renames a device.

rename device_name --setuuid uuid

Sets the uuid of a device that was created without a uuid. After a uuid has been set it cannot be changed.

resume device_name... [--addnodeoncreate|--addnodeonresume] [--noflush] [--nolockfs] [--readahead [+]sectors|auto|none]

Un-suspends a device. If an inactive table has been loaded, it becomes live. Postponed I/O then gets re-queued for processing.

setgeometry device_name cyl head sect start

Sets the device geometry to C/H/S.

splitname device_name [subsystem]

Splits given device name into subsystem constituents. The default subsystem is LVM. LVM currently generates device names by concatenating the names of the Volume Group, Logical Volume and any internal Layer with a hyphen as separator. Any hyphens within the names are doubled to escape them. The precise encoding might change without notice in any future release, so we recommend you always decode using the current version of this command.

stats command [options]

Manages IO statistics regions for devices. See dmstats(8) for more details.

status [--target target_type] [--noflush] [device_name...]

Outputs status information for each of the device's targets. With --target, only information relating to the specified target type any is displayed. With --noflush, the thin target (from version 1.3.0) doesn't commit any outstanding changes to disk before reporting its statistics.

suspend [--nolockfs] [--noflush] device_name...

Suspends a device. Any I/O that has already been mapped by the device but has not yet completed will be flushed. Any further I/O to that device will be postponed for as long as the device is suspended. If there's a filesystem on the device which supports the operation, an attempt will be made to sync it first unless --nolockfs is specified. Some targets such as recent (October 2006) versions of multipath may support the --noflush option. This lets outstanding I/O that has not yet reached the device to remain unflushed.

table [--concise] [--target target_type] [--showkeys] [device_name...]

Outputs the current table for the device in a format that can be fed back in using the create or load commands. With --target, only information relating to the specified target type is displayed. Real encryption keys are suppressed in the table output for crypt and integrity targets unless the --showkeys parameter is supplied. Kernel key references prefixed with : are not affected by the parameter and get displayed always (crypt target only). With --concise, the output is presented concisely on a single line. Commas then separate the name, uuid, minor device number, flags ('ro' or 'rw') and the table (if present). Semi-colons separate devices. Backslashes escape any commas, semi-colons or backslashes. See CONCISE FORMAT below.

targets

Displays the names and versions of the currently-loaded targets.

udevcomplete cookie

Wake any processes that are waiting for udev to complete processing the specified cookie.

udevcomplete_all [age_in_minutes]

Remove all cookies older than the specified number of minutes. Any process waiting on a cookie will be resumed immediately.

udevcookie

List all existing cookies. Cookies are system-wide semaphores with keys prefixed by two predefined bytes (0x0D4D).

udevcreatecookie

Creates a new cookie to synchronize actions with udev processing. The output is a cookie value. Normally we don't need to create cookies since dmsetup creates and destroys them for each action automatically. However, we can generate one explicitly to group several actions together and use only one cookie instead. We can define a cookie to use for each relevant command by using --udevcookie option. Alternatively, we can export this value into the environment of the dmsetup process as DM_UDEV_COOKIE variable and it will be used automatically with all subsequent commands until it is unset. Invoking this command will create system-wide semaphore that needs to be cleaned up explicitly by calling udevreleasecookie command.

udevflags cookie

Parses given cookie value and extracts any udev control flags encoded. The output is in environment key format that is suitable for use in udev rules. If the flag has its symbolic name assigned then the output is DM_UDEV_FLAG_<flag_name> = '1', DM_UDEV_FLAG<flag_position> = '1' otherwise. Subsystem udev flags don't have symbolic names assigned and these ones are always reported as DM_SUBSYSTEM_UDEV_FLAG<flag_position> = '1'. There are 16 udev flags altogether.

udevreleasecookie [cookie]

Waits for all pending udev processing bound to given cookie value and clean up the cookie with underlying semaphore. If the cookie is not given directly, the command will try to use a value defined by DM_UDEV_COOKIE environment variable.

version

Outputs version information.

wait [--noflush] device_name [event_nr]

Sleeps until the event counter for device_name exceeds event_nr. Use -v to see the event number returned. To wait until the next event is triggered, use info to find the last event number. With --noflush, the thin target (from version 1.3.0) doesn't commit any outstanding changes to disk before reporting its statistics.

wipe_table device_name... [-f|--force] [--noflush] [--nolockfs]

Wait for any I/O in-flight through the device to complete, then replace the table with a new table that fails any new I/O sent to the device. If successful, this should release any devices held open by the device's table(s).

## TABLE FORMAT
Each line of the table specifies a single target and is of the form:

logical_start_sector num_sectors target_type target_args

Simple target types and target args include:

linear destination_device start_sector

The traditional linear mapping.

striped num_stripes chunk_size [destination start_sector]...

Creates a striped area.

e.g. striped 2 32 /dev/hda1 0 /dev/hdb1 0 will map the first chunk (16k) as follows:

LV chunk 1 → hda1, chunk 1

LV chunk 2 → hdb1, chunk 1

LV chunk 3 → hda1, chunk 2

LV chunk 4 → hdb1, chunk 2

etc.

error

Errors any I/O that goes to this area. Useful for testing or for creating devices with holes in them.

zero

Returns blocks of zeroes on reads. Any data written is discarded silently. This is a block-device equivalent of the /dev/zero character-device data sink described in null(4).

More complex targets include:

cache

Improves performance of a block device (eg, a spindle) by dynamically migrating some of its data to a faster smaller device (eg, an SSD).

crypt

Transparent encryption of block devices using the kernel crypto API.

delay

Delays reads and/or writes to different devices. Useful for testing.

flakey

Creates a similar mapping to the linear target but exhibits unreliable behaviour periodically. Useful for simulating failing devices when testing.

mirror

Mirrors data across two or more devices.

multipath

Mediates access through multiple paths to the same device.

raid

Offers an interface to the kernel's software raid driver, md.

snapshot

Supports snapshots of devices.

thin, thin-pool

Supports thin provisioning of devices and also provides a better snapshot support.

To find out more about the various targets and their table formats and status lines, please read the files in the Documentation/device-mapper directory in the kernel source tree. (Your distribution might include a copy of this information in the documentation directory for the device-mapper package.)

## EXAMPLES

```
# A table to join two disks together
0 1028160 linear /dev/hda 0
1028160 3903762 linear /dev/hdb 0
```

```
# A table to stripe across the two disks,
# and add the spare space from
# hdb to the back of the volume
0 2056320 striped 2 32 /dev/hda 0 /dev/hdb 0
2056320 2875602 linear /dev/hdb 1028160
```

## CONCISE FORMAT
A concise representation of one of more devices.

- A comma separates the fields of each device.

- A semi-colon separates devices.

The representation of a device takes the form:

<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]]

The fields are:

name

The name of the device.

uuid

The UUID of the device (or empty).

minor

The minor number of the device. If empty, the kernel assigns a suitable minor number.

flags

Supported flags are:

ro Sets the table being loaded for the device read-only

rw Sets the table being loaded for the device read-write (default)

table

One line of the table. See TABLE FORMAT above.

## EXAMPLES
\# A simple linear read-only device

test-linear-small,,,ro,0 2097152 linear /dev/loop0 0,2097152 2097152 linear /dev/loop1 0

\# Two linear devices

test-linear-small,,,,0 2097152 linear /dev/loop0 0;test-linear-large,,,,0 2097152 linear /dev/loop1 0, 2097152 2097152 linear /dev/loop2 0

## ENVIRONMENT VARIABLES
DM_DEV_DIR

The device directory name. Defaults to "/dev" and must be an absolute path.

DM_UDEV_COOKIE

A cookie to use for all relevant commands to synchronize with udev processing. It is an alternative to using --udevcookie option.

DM_DEFAULT_NAME_MANGLING_MODE

A default mangling mode. Defaults to "auto" and it is an alternative to using --manglename option.

## AUTHORS
Original version: Joe Thornber <thornber@redhat.com>

## SEE ALSO
dmstats(8), udev(7), udevadm(8)

LVM2 resource page: https://www.sourceware.org/lvm2

Device-mapper resource page: http://sources.redhat.com/dm