lilo.conf

package: lilo

title: lilo.conf(5)

summary: configuration file for lilo

text:
# lilo.conf(5)

## NAME
lilo.conf - configuration file for lilo

## DESCRIPTION
This file, by default /etc/lilo.conf, is read by the boot loader installer 'lilo' (see lilo(8)).

It might look as follows:

```
# /etc/lilo.conf
#
#  global options:
boot=/dev/hda
prompt
timeout=150
lba32
compact
vga=normal
root=/dev/hda1
read-only
menu-title=" John's Computer "
#
### bootable kernel images ###
image=/boot/vmlinuz-2.6.29-1-i386

     label=try

     initrd=/boot/initrd.img-2.6.29-1-i386
image=/boot/vmlinuz-2.4.33-1-i386

     label=2.4.33
image=/tamu/vmlinuz

     label=tamu

     initrd=/tamu/initrd.img

     root=/dev/hdb2

     vga=ask
#
### other operating systems ###
other=/dev/hda3

     label=PCDOS

     boot-as=0x80    # must be C:
other=/dev/hdb1

     label=WinXP

     boot-as=0x80    # must be C:
other=/dev/hdb5

     label=oldDOS

     loader=chain

     table=/dev/hdb5
```

This configuration file specifies that lilo uses the Master Boot Record on /dev/hda. (For a discussion of the various ways to use lilo, and the interaction with other operating systems, see html/user_21-5.html inside the old documentation.)

When booting, the boot loader will issue its boot: prompt and wait for you to enter the label of the kernel (and any options) which you wish to boot. At any time you may hit [Tab] to see a list of kernel/other labels. Alternately, if the menu boot loader is installed, a menu of boot options will be presented for your selection. The title of this menu is overridden with the menu title specification in this configuration file. If you enter nothing, then the default kernel image, the first mentioned, (in the example /boot/vmlinuz-2.6.29-1-i386) will be booted after a timeout of 15 seconds (150 deciseconds). There may be at least 16 images mentioned in lilo.conf. (The exact number depends upon compilation options.)

As can be seen above, a configuration file starts with a number of global options (the top 9 lines in the example), followed by descriptions of the options for the various images. An option in an image description will override a global option.

Comment lines may appear anywhere, and begin with the "#" character.

## GLOBAL OPTIONS
There are many possible keywords. The description below is almost literally from html/user_21-5.html inside the old documentation (just slightly abbreviated).

backup=<backup-file>

Specifies the location where a copy of any modified boot sector will be saved in a file. 'backup=' may specify this location in one of three ways: a directory where the default backup file 'boot.NNNN' will be created; a file pathname template to which the '.NNNN' suffix will be added; or the full file pathname, which must include the correct '.NNNN' suffix. All RAID installations should use only the first two alternatives, as multiple backups may be created. The '.NNNN' suffix is the hexadecimal representation of the major and minor device numbers of the device or partition. If this option is not specified, the default name of boot sector backups is '/boot/boot.NNNN'. If a backup already exists, it will be preserved, rather than overwritten. C.f., force-backup= below.

bios-passes-dl=<option>

The option is indicated as yes, no, or unknown. If not specified, a value of "unknown" is assumed, unless additional information is available to the boot installer. When "no" is specified, it indicates that the BIOS is known not to pass the current boot device code to the boot loader in the DL register. Its only function at this point is experimental, as certain RAID installations may benefit from knowing that the BIOS is 100% reliable. Its use should be considered experimental. This option may be specified on the command line with the '-Z' switch: yes=1, no=0.

bitmap=<bitmap-file>

Specifies use of a 640x480x16 (VGA BIOS) or 640x480x256 (VGA/VESA BIOS) bitmap file as the background on which a boot menu is displayed. May not be used if 'message=' is specified. Use of this option will select a bitmap-capable boot loader, unless overridden with "install=" (see below). When a bitmap file is specified as a background screen during the boot process, the color selection and layout of the text which overlays the graphic image must be specified in one of two ways.

One way is the use of header information in the bitmap image (*.bmp) file: From a text file with all the information about 'bmp-colors', 'bmp-table' and 'bmp-timer' options together with the 'bitmap' option are stored in the special LILO header of the bitmap image file by the lilo -E command. Another way works without these special header information: All the information about 'bmp-colors', 'bmp-table' and 'bmp-timer' options together with the 'bitmap' option are stored in the configuration file. Any use of the 'bmp-' options within the configuration file overrides the options stored in the bitmap file header. If lilo cannot find any of the 'bmp-' options, then default values are used.

bmp-colors=<fg>,<bg>,<sh>,<hfg>,<hbg>,<hsh>

Specifies the decimal values of the colors to be used for the menu display on a 'bitmap=' background. The list consists of 6 entries, 3 for normal text followed by 3 for highlighted text. The order of each triple is: foreground color, background color, shadow color. If background color is not specified, "transparent" is assumed. If shadow color is not specified, then "none" is assumed. The list entries are separated by commas, with no spaces.

bmp-retain

Option applies to all 'image=' and 'other=' sections. (See COMMON OPTIONS, below.)

bmp-table=<x>,<y>,<ncol>,<nrow>,<xsep>,<spill>

Specifies the location and layout of the menu table. <x>,<y> specify the starting x- and y-position of the upper left corner of the table in character coordinates: x in [1..80], y in [1..30]. <ncol> is the number of columns in the menu (1..5); and <nrow> is the number of rows (entries) in each column. If more than one column is specified, then <xsep> is the number of character columns between the leftmost characters in each column: (18..40), and <spill> is the number of entries in one column which must be filled before entries spill into the next column. <spill> must be .le. <nrow>. If pixel addressing is used, instead of character addressing, then any of <x>, <y>, or <xsep> may be specified with a 'p' suffix on the decimal value.

bmp-timer=<x>,<y>,<fg>,<bg>,<sh>

Optional specification of the 'timeout=' countdown timer. <x>,<y> specifies the character (or pixel) coordinate of the location of the timer the same as 'bmp-table=' above; and the color triple specifies the character color attributes the same as 'bmp-colors=' above, with the exception that the background color must be specified. If used to override the timer specification in a bitmap file, then the form 'bmp-timer = none' is acceptable. This will disable the timer display entirely.

boot=<boot-device>

Sets the name of the device (e.g. hard disk or partition) that contains the boot sector and where the new boot sector should be written to. Notice: The boot-device should be the device with the currently mounted root partition. A raid installation is initiated by specifying a RAID1 device as the boot device; e.g., "boot=/dev/md0".

On newer systems you need an unique ID for the boot device. If the boot sector should write to a partition you can use its UUID in the same manner is for the root options.

If your boot device is a hard disk you need a special ID, which is supported by udev. You find the right ID in the directory /dev/disks/by-id, i. e.:

```
    boot = /dev/disk/by-id/ata-SAMSUNG_SV1604N_S01FJ10X999999
```

change-rules

Defines boot-time changes to partition type numbers (`hiding').

```
change-rules

   reset

   type=DOS12

      normal=1

      hidden=0x11

   type=DOS16_small

      normal=4

      hidden=0x14

   type=DOS16_big

      normal=0x06

      hidden=0x16
```

The above excerpt from a configuration file specifies that all default change-rules are removed ("reset"), and the change-rules for three partition types are specified. Without the reset, the three types specified would have been added to the existing default change-rules. Normally, the default rules are sufficient. The strings which define the partition types are used in a change section (see below), with the suffixes "_normal" or "_hidden" appended. See section "Partition type change rules" of html/user_21-5.html inside the old documentation for more details.

compact

Tries to merge read requests for adjacent sectors into a single read request. This drastically reduces load time and keeps the map file smaller. Using `compact' is especially recommended when booting using a map file on a floppy disk.

default=<name>

Uses the specified image as the default boot image. If `default' is omitted, the image appearing first in the configuration file is used. See also, vmdefault below.

delay=<tsecs>

Specifies the number of tenths of a second the boot loader should wait before automatically booting a locked command line, a command line pre-stored by "lilo -R", or the default `image=' or `other='. When `delay' is non-zero, the boot loader will wait for an interrupt for the specified interval. If an interrupt is received, or is already waiting, the boot: prompt will be be issued, and no automatic boot will take place. The setting of CAPS LOCK or SCROLL LOCK, or any of the keys ALT, CTRL, or SHIFT, when held down, are taken as interrupts. This action is modified by specifying `prompt' (see below).

disk=<device-name>

Defines non-standard parameters for the specified disk. See section "Disk geometry" of html/user_21-5.html inside the old documentation for details. For versions of LILO prior to 22.5, the `bios=' parameter is quite useful for specifying how the BIOS has assigned device codes to your disks. For example,

```
       disk=/dev/sda

            bios=0x80

       disk=/dev/hda

            bios=0x81

       disk=/dev/sdb

            inaccessible
```

would say that your SCSI disk is the first BIOS disk (0x80), that your (primary master) IDE disk is the second BIOS disk (0x81), and that your second SCSI disk (perhaps a USB device) receives no device code, and is therefore inaccessible at boot time.

NOTE: Use of the 'bios=' option is largely obsolete beginning with LILO version 22.5, as the boot loader now identifies disks by 32-bit Volume-ID, and defers BIOS device code determination until boot time.

Other options include the specification of disk geometry; e.g.,

```
       disk=/dev/fd0

            sectors=18

            heads=2

            cylinders=80
```

probably only useful for floppy disks and loopback devices, because for hard disks the lba32 disk addressing option ignores disk geometry.

Developers who have implemented a disk driver for a new block storage device will have to indicate to LILO the maximum number of partitions on the device. This is in addition to making all of the necessary entries for the device in the "/dev" directory (with 'mknod'). The maximum number of partitions must be one of 63 (like an IDE disk), 31 (uncommon), 15 (like SCSI disks -- most common value), or 7 (like one array controller). An example specification would be:

```
     disk=/dev/userd0

          max-partitions=15
```

In cases where there is no kernel partition information available, such as on loopback devices, the 'disk=' specification may include paritition start information; viz.,

```
       disk=/dev/loop0

            bios=0x80			# use this BIOS code

            max-partitions=7		# declare partitionable

            paritition=/dev/loop1

                 start=63		# offset from sector 0

            paritition=/dev/loop2

                 start=102400		# offset from sector 0
```

disktab=<disktab-file>

Specifies the name of the disk parameter table. The map installer looks for /etc/disktab if `disktab' is omitted. The use of disktabs is discouraged.

el-torito-bootable-CD

Flag second stage loader to terminate disk emulation when booting from an El Torito Bootable CD. This option is used by the mkrescue utility when the "--iso" switch is specified.

fix-table

This allows lilo to adjust 3D addresses in partition tables. Each partition entry contains a 3D (cylinder/head/sector) and a linear address of the first and the last sector of the partition. If a partition is not track-aligned and if certain other operating systems (e.g. PC/MS-DOS) are using the same disk, they may change the 3D address. lilo can store its boot sector only on partitions where both address types correspond. lilo re-adjusts incorrect 3D start addresses if `fix-table' is set. WARNING: This does not guarantee that other operating systems may not attempt to reset the address later. It is also possible that this change has other, unexpected side-effects. The correct fix is to re-partition the drive with a program that does align partitions to tracks. Also, with some disks (e.g. some large EIDE disks with address translation enabled), under some circumstances, it may even be unavoidable to have conflicting partition table entries.

force-backup=<backup-file>

Operation is identical to backup= above, except an existing backup file is unconditionally overwritten if it exists.

geometric

Force disk addressing which is compatible with older versions of LILO. Geometric addressing uses cylinder/head/sector addresses, and is limited to disk cylinders up to 1023. If inaccessible cylinders are referenced, diagnostics will be issued at boot-install time, rather than boot-time. With a newer BIOS, use of 'lba32' is recommended.

ignore-table

tells lilo to ignore corrupt partition tables.

install=<user-interface>

Selects the user interface which will be seen at boot time. One of the following three options may be specified: text, menu, or bmp. The traditional LILO interface is `text'; but `menu' is now the default, unless the configuration file contains the `bitmap=' specification. The text interface is strictly a command-line interface as though the console were a dumb terminal. The menu interface is a text-based screen of the boot choices, with the option to enter additional command line parameters. And the bmp interface is a menu presented against a graphic screen, specified as a 640x480 BitMaP file of 16 or 256 colors. (See the 'lilo -E' switch for editing options). (Prior to LILO version 22.3, `install=' specified the user interface as a file in the `/boot' directory.)

large-memory

Normally any initial ramdisk (initrd) loaded with a kernel is loaded as high in memory as possible, but never above 15Mb. This is due to a BIOS limitation on older systems. On newer systems, this option enables using memory above 15Mb (up to a kernel imposed limit, around 768Mb) for passing the initrd to the kernel. The presence of this option merely indicates that your system does not have the old BIOS limitation. This switch (or its absence) is not passed to the kernel, and does not in any way affect the amount of physical memory which it will use. (See the kernel documentation for the kernel command line parameter "mem=" for limiting the memory used by the kernel.)

lba32

Generate 32-bit Logical Block Addresses instead of cylinder/head/sector addresses. If the BIOS supports packet addressing, then packet calls will be used to access the disk. This allows booting from any partition on disks with more than 1024 cylinders. If the BIOS does not support packet addressing, then 'lba32' addresses are translated to cylinder/head/sector ('geometric'), just as for 'linear'. All floppy disk references are retained in C:H:S form. Use of 'lba32' is recommended on all post-1998 systems. Beginning with LILO version 22, 'lba32' is the default disk addressing scheme.

linear

Generate 24-bit linear sector addresses instead of cylinder/head/sector (geometric) addresses. Linear addresses are translated at run time to geometric addresses, and are limited to cylinders <= 1023. When using `linear' with large disks, /sbin/lilo may generate references to inaccessible disk cylinders. 'lba32' avoids many of these pitfalls with its use of packet addressing, but requires a recent BIOS (post-1998). The 'linear' option is considered obsolete, and its use is strongly discouraged.

lock

Enables automatic recording of boot command lines as the defaults for the following boots. This way, lilo "locks" on a choice until it is manually overridden.

mandatory

The per-image password option `mandatory' (see below) applies to all images.

map=<map-file>

Specifies the location of the map file. If `map' is omitted, the file /boot/map is used. On machines with a pre-1998 BIOS, the EDD bios extensions which are required to support "lba32" disk sector addressing may not be present. In this case, the boot-loader will fall back automatically to "geometric" addressing; this fall back situation, or the specific use of "geometric" or "linear" addressing, will require the map file to be located within the first 1024 cylinders of the disk drive. This BIOS limitation is not present on post-1998 systems, most of which support the newer EDD disk BIOS calls.

menu-title=<title-string>

Specifies the title line (up to 37 characters) for the boot menu. This title replaces the default "LILO Boot Menu" title string. If menu is not installed as the boot loader (see install= option), then this line has no effect.

menu-scheme=<color-scheme>

The default color scheme of the boot menu may be overridden on VGA displays using this option. (The color scheme of MDA displays is fixed.) The general color-scheme string is of the form:

```
     <text>:<highlight>:<border>:<title>
```

where each entry is two characters which specify a foreground color and a background color. Only the first entry is required. The default highlight is the reverse of the text color; and the default border and title colors are the text color. Colors are specified using the characters kbgcrmyw, for blacK, Blue, Green, Cyan, Red, Magenta, Yellow, and White: upper case for intense (fg only), lower case for dim. Legal color-scheme strings would be

```
    menu-scheme=Wm     intense white on magenta

    menu-scheme=wr:bw:wr:Yr    the LILO default

    menu-scheme=Yk:kw    bright yellow on black
```

If menu is not installed as the boot loader, then this line has no effect.

message=<message-file>

specifies a file containing a message that is displayed before the boot prompt. No message is displayed while waiting for a shifting key after printing "LILO ". In the message, the FF character ([Ctrl L]) clears the local screen. This is undesirable when the menu boot loader is installed. The size of the message file is limited to 65535 bytes. The map file has to be rebuilt if the message file is changed or moved. 'message=' and 'bitmap=' are mutually exclusive.

nodevcache

(22.8) Disables pre-loading of the internal device cache. May be needed for Linux distributions which use non-standard device naming conventions; e.g., when the first IDE disk is not `/dev/hda'.

nokbdefault=<name>

(22.7.2) The named descriptor is taken to be the default boot image if no IBM-PC keyboard is present. If no serial interface ("serial=") is in use, then any "prompt" keyword and "timeout" value are bypassed, and default booting occurs as specified by "delay=". The keyboard detection codes cannot detect the presence or absence of a newer USB keyboard.

noraid

Disables the automatic marking of disk volumes which are components of RAID arrays as inaccessible. This allows the user to edit the disk= / inaccessible declarations into the configuration file himself. Without such declarations, duplicate Volume IDs will be overwritten, leading to confusing situations at boot-time, and possible failure to boot. The use of this keyword is generally not necessary.

nowarn

Disables warnings about possible future dangers.

optional

The per-image option `optional' (see below) applies to all images.

password=<password>

The per-image option `password=...' (see below) applies to all images. This option may prevent unattended booting, if the default image is `password=' protected at the default level `mandatory', which is a level higher than `restricted'.

prompt

Automatic booting (see `delay' above) will not take place unless a locked or pre-stored ("lilo -R") command line is present. Instead, the boot loader will issue the boot: prompt and wait for user input before proceeding (see timeout below). Unattended default image reboots are impossible if `prompt' is set and `timeout' is not, or the default image is password protected at a higher level than `restricted'.

raid-extra-boot=<option>

This option only has meaning for RAID1 installations. The <option> may be specified as none, auto, mbr, mbr-only, or a comma-separated list of devices; e.g., "/dev/hda,/dev/hdc6". Starting with LILO version 22.0, the boot record is normally written to the first sector of the RAID1 partition. On PARALLEL raid sets, no other boot records are needed. The default action is auto, meaning, automatically generate auxiliary boot records as needed on SKEWED raid sets. none means suppress generation of all auxiliary boot records. mbr-only suppresses generation of a boot record on the raid device, and forces compatibility with versions of LILO earlier than version 22.0 by writing boot records to all Master Boot Records (MBRs) of all disks which have partitions in the raid set. mbr is like mbr-only except the boot record on the RAID partition is not suppressed. Use of an explicit list of devices, forces writing of auxiliary boot records only on those devices enumerated, in addition to the boot record on the RAID1 device. Since the version 22 RAID1 codes will never automatically write a boot record on the MBR of device 0x80, if such a boot record is desired, this is one way to have it written. Use of mbr is the other way to force writing to the MBR of device 0x80.

restricted

The per-image password option `restricted' (see below) applies to all images.

serial=<parameters>

enables control from a serial line. The specified serial port is initialized and the boot loader is accepting input from it and from the PC's keyboard. Sending a break on the serial line corresponds to pressing a shift key on the console in order to get the boot loader's attention. All boot images should be password-protected if the serial access is less secure than access to the console, e.g. if the line is connected to a modem. The parameter string has the following syntax:

```
    <port>[,<bps>[<parity>[<bits>]]]
```

<port>: the number of the serial port, zero-based. 0 corresponds to COM1 alias /dev/ttyS0, etc. All four ports can be used (if present).

<bps>: the baud rate of the serial port. The following baud rates are supported: 110, 150, 300, 600, 1200, 2400(default), 4800, 9600, plus the extended rates 19200, 38400, and 57600(56000). 115200 is allowed, but may not work with all COMx port hardware.

<parity>: the parity used on the serial line. The boot loader ignores input parity and strips the 8th bit. The following (upper or lower case) characters are used to describe the parity: "n" for no parity, "e" for even parity and "o" for odd parity.

<bits>: the number of bits in a character. Only 7 and 8 bits are supported. Default is 8 if parity is "none", 7 if parity is "even" or "odd".

If `serial' is set, the value of `delay' is automatically raised to 20.

Example: "serial=0,2400n8" initializes COM1 with the default parameters.

single-key

This option specifies that boot images or 'other's are to be selected and launched with a single keystroke. Selection is based upon the first character of each name, which must be unique. This option should not be used with the menu or bitmap user interface ("install=").

static-BIOS-codes

Causes the operation of the boot installer and boot loader to bypass the use of Volume-ID information, and to revert to a mode of operation of versions of LILO from 22.4 backward. With Volume-ID booting (22.5 and later), the BIOS codes of disks are determined at boot time, not install time; hence they may be switched around, either by adding or removing disk(s) from the hardware configuration, or by using a BIOS menu to select the boot device. With the use of this option, BIOS codes of disks MUST be correctly specified at install time; either guessed correctly by LILO (which often fails on mixed IDE/SCSI systems), or explicitly specified with 'disk=/dev/XXX bios=0xYY' statements. The use of this option precludes any activity which may switch around the BIOS codes assigned to particular disk devices, as noted above.

In general, this option should never be used, except as a bug workaround.

suppress-boot-time-BIOS-data

This global option suppresses the boot-time real mode collection of BIOS data on systems which hang on certain BIOS calls. It is equivalent to using the boot-time switch 'nobd'. This option defeats the disk volume recognition and BIOS device code detection features of LILO on systems with more than one disk. Thus the use of this option will produce a strong cautionary message, which cannot be suppressed.

timeout=<tsecs>

sets a timeout (in tenths of a second) for keyboard input at the boot: prompt. "timeout" only has meaning if "prompt" is mentioned. If no key is pressed for the specified time, the default image is automatically booted. The default timeout is infinite.

unattended

(22.6) Alters the operation of the "timeout" parameter in a manner which is useful on noisy serial lines. Each typed (or noise) character restarts the "timeout" timer and a timeout will always boot the default descriptor, even if noise characters have appeared on the input line.

verbose=<number>

Turns on lots of progress reporting. Higher numbers give more verbose output. If -v is additionally specified on the lilo command line, the level is increased accordingly. The maximum verbosity level is 5.

vmdefault=<name>

The named boot image is used as the default boot if booting in "virtual" mode with a virtual monitor, such as VMware(tm). Thus a real mode boot and a virtual mode boot can be made to have different default boot images.

Additionally, the kernel configuration parameters append, ramdisk, read-only, read-write, root and vga can be set in the global options section. They are used as defaults if they aren't specified in the configuration sections of the respective kernel images.

## PER-IMAGE SECTION
A per-image section starts with either a line

```
    image=<pathname>
```

to indicate a file or device containing the boot image of a Linux kernel, or a line

```
    other=<device>
```

to indicate an arbitrary system to boot.

In the former case, if an image line specifies booting from a device, then one has to indicate the range of sectors to be mapped using

```
    range=<start>-<end>

    range=<start>+<nsec>

    range=<sector>
```

In the third case, 'nsec=1' is assumed.

## KERNEL OPTIONS (image=)
If the booted image is a Linux kernel, then one may pass command line parameters to this kernel.

addappend=<string>

The kernel parameters of this string are concatenated to the parameter(s) from an append= option (see below). The string of addappend must be enclosed within double quotes. Usually, the previous append= will set parameters common to all kernels by appearing in the global section of the configuration file and addappend= will be used to add local parameter(s) to an individual image. The addappend option may be used only once per "image=" section. If the string is a very long line, this line can be divided in more lines using "\" as last character of a line, e.g.

```
    addappend="noapic acpi=off pci=usepirqmask \

            pnpbios=off pnpacpi=off noisapnp"
```

append=<string>

Appends the options specified to the parameter line passed to the kernel. This is typically used to specify hardware parameters that can't be entirely auto-detected or for which probing may be dangerous. Multiple kernel parameters are separated by a blank space, and the string must be enclosed in double quotes. A local append= appearing withing an image= section overrides any global append= appearing in the global section of the configuration file. The append option may be used only once per "image=" section. To concatenate parameter strings, use "addappend=". Example:

```
     append="mem=96M hd=576,64,32 console=ttyS1,9600"
```

If the string is a very long line, this line can be divided in more lines using "\" as last character of a line. See example of addappend option.

initrd=<name>

Specifies the initial ramdisk image to be loaded with the kernel. The image will contain modules needed at boot time, such as network and scsi drivers. See man pages for mkinitrd(8).

literal=<string>

Like `append', but removes all other options (e.g. setting of the root device). 'literal' overrides all 'append' and 'addappend' options. Because vital options can be removed unintentionally with `literal', this option cannot be set in the global options section.

ramdisk=<size>

This specifies the size (e.g., "4096k") of the optional RAM disk. A value of zero indicates that no RAM disk should be created. If this variable is omitted, the RAM disk size configured into the boot image is used.

read-only

This specifies that the root file system should be mounted read-only. It may be specified as a global option. Typically, the system startup procedure re-mounts the root file system read-write later (e.g. after fsck'ing it).

read-write

This specifies that the root file system should be mounted read-write. It may be specified as a global option.

root=<root-device>

This specifies the device that should be mounted as root. It may be specified as a global option. If the special name current is used, the root device is set to the device on which the root file system is currently mounted. If the root has been changed with -r , the respective device is used. If the variable `root' is omitted, the root device setting contained in the running kernel image is used. Warning: This can induce to an unbootable system! The root filesystem may also be specified by a LABEL= or UUID= directive, as in '/etc/fstab'. In this case, the argument to root= must be enclosed in quotation marks, to avoid a syntax error on the second equal sign, e.g.:

```
     root="LABEL=MyDisk"

     root="UUID=5472fd8e-9089-4256-bcaa-ceab4f01a439"
```

Note: The command line root= parameter passed to the kernel will be: 'root=LABEL=MyDisk'; i.e., without the quotation marks. If the root= parameter is passed from the boot time boot: prompt, no quotes are used. The quotes are only there to satisfy the requirements of the boot-installer parser, which treats an equal sign as an operator. The kernel command line parser is very much simpler, and must not see any quotation marks. Simply stated, only use the quotation marks within /etc/lilo.conf.

vga=<mode>

This specifies the VGA text mode that should be selected when booting. It may be specified as a global option. The following values are recognized (case is ignored): normal: select normal 80x25 text mode.

extended (or ext): select 80x50 text mode.

ask: stop and ask for user input (at boot time).

<number>: use the corresponding text mode (can specify the number in decimal or in hex with the usual '0x' convention). A list of available modes can be obtained by booting with vga=ask and pressing [Enter].

If this variable is omitted, the VGA mode setting contained in the kernel image is used. (And that is set at compile time using the SVGA_MODE variable in the kernel Makefile, and can later be changed with the rdev(8) program.)

## ALTERNATE SYSTEM (other=)
Used to load systems other than Linux. The `other = <device>' specifies the boot sector of an alternate system contained on a device or disk partition; e.g., DOS on, say, `/dev/hda2', or a floppy on `/dev/fd0'. In the case of booting another system there are these options:

loader=<chain-loader>

This specifies the chain loader that should be used. It may also be specified as a global option. By default chain is used. This chain loader passes partition and drive information in the boot sector it loads only to DOS on FAT12 or FAT16, Windows on FAT16 or FAT32. (see also table=<letter> below).

table=<device>

This specifies the device that contains the partition table. The boot loader will pass default partition information to the booted operating system if this variable is omitted. (Some operating systems have other means to determine from which partition they have been booted. E.g., MS-DOS usually stores the geometry of the boot disk or partition in its boot sector.) Note that /sbin/lilo must be re-run if a partition table mapped referenced with `table' is modified.

change

This keyword starts a section which describes how primary partition IDs are changed, and how primary partitions are activated and deactivated. If change is omitted, change rules are generated as though the automatic keyword were specified. The keyword change alone, without any rules following, will suppress automatic change-rules. For example,

```
   other=/dev/hda2

      label=dos

      table=/dev/hda

      change

        automatic

        partition=/dev/hda1

           set=DOS12_hidden

           deactivate

        partition=/dev/hda2

           set=DOS16_big_normal

           activate
```

specifies that when primary partition /dev/hda2 is booted, automatic change-rules will be in effect; plus, partition 1, a DOS12 partition, will be set hidden, and deactivated. In addition, partition 2, will be set normal, and activated. Activation sets the boot-flag in the partition table. The automatic keyword may conflict with default change rules, so the set= lines above may be redundant.

boot-as=<bios>

This option (LILO version 22.5.1) indicates the BIOS device code which must be assigned to the specified drive in order for the "other=" operating system to boot. If the chain loader detects that another BIOS device code is assigned to this disk, then it will dynamically swap the assigned device code with the specified device code. This option is easier to specify than "map-drive=" and more general than "master-boot" in that any device code may be specified. Unlike "map-drive=", the determination whether to swap device codes is made at boot time, not install time. This is advantageous on systems where the BIOS presents a boot menu of devices, and will map disks to devices in different ways, depending upon the BIOS boot selection.

This option may be specified as a global option, in which case it applies to all "other=" sections unless overridden with a specific "master-boot" option. If one of "boot-as=" or "master-boot" is specified as a global option, it is better to specify "master-boot" as the global option, as it will not interfere with floppy disk BIOS device codes; "boot-as=" is then used as a local option to override "master-boot" as necessary.

master-boot

This flag (LILO version 22.5) indicates a DOS/Windows or other system which will only boot from BIOS device 0x80, the "C:" drive, or BIOS device 0, the A: drive. When this flag is specified, if this drive is not assigned device code 0x80 or 0 by the BIOS, then the chain loader will dynamically swap the device code actually assigned with device code 0x80 or 0 to make this drive appear to be the first hard or floppy drive, "C:" or "A:". This flag is easier to use than "map-drive=" (see below), and is preferred, if simple forcing of device code 0x80 is all that is required. It is also more general, in that the necessity to swap BIOS device codes is determined dynamically at boot-time, not at boot install-time, as with "map-drive=". It is slightly more powerful than "boot-as=", in that the device code which is assigned, 0 or 0x80, is determined dynamically.

This option may be specified as a global option, in which case it applies to all "other=" sections unless overridden with a specific "boot-as=" option.

map-drive=<num>

Maps BIOS calls for the specified drive to the device code specified on the next line as to=<num>. This mapping is useful for booting operating systems, such as DOS, from the second hard drive. The following, swaps the C: and D: drives,

```
   map-drive=0x80

      to=0x81

   map-drive=0x81

      to=0x80
```

This option is largely rendered obsolete by "boot-as=", introduced with LILO version 22.5.

unsafe

Do not access the boot sector at map creation time. This disables some sanity checks, including a partition table check. If the boot sector is on a fixed-format floppy disk device, using UNSAFE avoids the need to put a readable disk into the drive when running the map installer. If the boot sector is on a hard drive, the BIOS device code of the drive will have to be specified explicitly with "disk=/dev/XXXX bios=0x8X inaccessible" in the configuration file. `unsafe' and `table' (explicit or implicit) are mutually incompatible.

## COMMON DESCRIPTOR OPTIONS (image= & other=)
In both the image= and other= cases, the following options apply.

bypass

No password is required to boot this image. Used to indicate that the global password does not apply to this `image=' or `other='. See 'password=' below.

label=<name>

The boot loader uses the main file name (without its path) of each image specification to identify that image. A different name can be used by setting the variable `label'.

alias=<name>

A second name for the same entry can be used by specifying an alias.

bmp-retain

The bitmap graphic (install=bmp) is retained when control is passed to the loaded kernel image, or other= bootloader; i.e., the screen is not blanked to alphanumeric mode before starting the kernel. This feature is considered EXPERIMENTAL, for those users working with startup splash screens.

fallback=<command-line>

Specifies a string that is stored as the default command line if the current image is booted. This is useful when experimenting with kernels which may crash before allowing interaction with the system. If using the fallback option, the next reboot (e.g. triggered by a manual reset or by a watchdog timer) will load a different (supposedly stable) kernel. The command line stored by the fallback mechanism is cleared by removing or changing the default command line with the -R option, which should be a part of the boot startup scripts.

lock

(See above.)

optional

Omit the image if it is not available at map creation time. It may be specified as a global option. This is useful to specify test kernels that are not always present.

password=<password>

Protect the `image=' or `other=' with a password (or passphrase). It may be specified as a global option. The interpretation of the `password=' setting is modified by the words `mandatory', `restricted', and `bypass' (see below).

The password may be specified in the config-file (less secure) or entered at the time the boot loader is installed. To request interactive entry of the password, it should be specified: password="". Passwords entered interactively are not required to be entered again if the boot installer is re-run. They are cached, in hashed form, in a companion file to the config-file, default name: /etc/lilo.conf.crc. If the config-file is updated, a warning message will be issued telling you to re-run lilo -p to force re-creation of the password cache file.

mandatory

A password is required to boot this image. This is the default. May be used on a single `image=' or `other=' to override a different global setting.

nokbdisable

(22.7.2) The specified descriptor is not bootable if the IBM-PC keyboard is not present. This option is really only useful if the "serial=" boot terminal is in use. With no keyboard (and no serial terminal) attached, selecting a boot descriptor other than the default is impossible. See nokbdefault above.

restricted

A password is only required to boot the image if kernel parameters are specified on the command line (e.g. 'single'). May be used on a single `image=' or `other=' to override a different global setting.

vmwarn

If booting under a virtual monitor such as VMware(tm), the image with this label will cause a cautionary warning to be issued at boot time, and user intervention will be required to continue or to abort the boot process.

vmdisable

If booting under a virtual monitor, the image with this label will not be displayed as a boot option. The image is only bootable in real mode. See vmdefault above.

## SEE ALSO
lilo(8), mkinitrd(8), mknod(1), mkrescue(8), rdev(8).


lircd.conf

package: lirc

title: lircd.conf(5)

summary: lirc main configuration file

text:
# lircd.conf(5)

## NAME
lircd.conf - lirc main configuration file

## DESCRIPTION
The file has two purposes: to provide timing information to the driver so it can decode the data to button presses, and to provide a mapping from button presses to key symbols used by lircd(8).

The basic structure is a list of remote blocks. Whitespace and line breaks are used as delimiters.

If the comment character (#) appears as the first character on a line the rest of the line is ignored.

## REMOTE BLOCKS
Remote blocks are either normal or raw.

Normal remote blocks begin with begin remote and ends with end remote. The first part of the block describes the basic properties of the remote, see REMOTE DESCRIPTION SECTION. Following this is a codes section, which is delimited by begin codes and end codes.

Each line in a codes section contains the name of a button on the remote followed by a hexadecimal data value matching the data part of the IR frame (see REMOTE DESCRIPTION SECTION). You may not assign the same name to two buttons in the same remote section.

Raw remote blocks are identical to normal blocks besides the codes section which is a list of button descriptions enclosed by begin raw_codes and end raw_codes.

A raw button description begins with the parameter name followed by the name of the button. The button description ends with the next button description or the end of the raw_codes block. The lines in between is a list of decimal numbers describing the signal sent by that button. The first number indicates the duration of the first pulse in microseconds. The second number indicates the duration of the space which follows it. Pulse and space durations alternate for as long as is necessary. The last duration should represent a pulse.

## REMOTE DESCRIPTION SECTION
Each line in this section contains a parameter followed by the value or values that should be assigned to that parameter. Parameters are optional unless otherwise stated.

All values are decimal integers that are either dimensionless or have units of microseconds unless otherwise stated. Hexadecimal numbers should be prefixed by 0x. If the remote does not have a particular "feature," then the line may be omitted. The button code is sent just after the pre signal and just before the post signal.

Some parameters describe the bits in the IR protocol. The frame is normally defined like

|header|plead|pre data|pre|data|post|post data|ptrail|foot|gap|

where most parameters defaults to 0. Some parameters change the overall frame layout e. g., the repeat parameter.

include ”<path>”

Include the given path using normal include semantics. If the path is relative, it's interpreted relative to the main lircd.conf file. <path> must be enclosed in double quotes. It can contain a glob(3) pattern in which case all matching files are included.

manual_sort <1|0>

Normally, lircd tries to sort multiple remotes so the one which decodes fastest are used first. Setting manual_sort to 1 in any remote disables this and uses the remotes in the order they are listed in lircd.conf or as the alphanumerically sorted filenames in lircd.conf.d.

name <remote name>

The unique name assigned to the remote control (may not contain whitespace). Within a single file all names must be unique. Parameter is mandatory.

suppress_repeat <repeats>

Suppress a given number of repeats for all buttons in this remote. Defaults to 0, which means that no repeats are suppressed. Note that lircrc has a corresponding repeat parameter which can be used to suppress repeats for specific button/client combinations.

flags <flag1><|flag2>...

Flags are special text strings which describe various properties of the remote and determine the semantics of some of the following fields. Multiple flags should be separated by the pipe(|) symbol. See FLAGS.

driver <driver name>

For lirccode drivers which does not have timing information the optional driver attribute names the driver which is required to use this remote.

bits <number of data bits>

The number of data bits in the hexadecimal codes which describe each button (decimal integer).

eps <relative error tolerance>

The relative error tolerance for received signals in percent. By default, irrecord set this to 30 (i. e., 30%).

aeps <absolute error tolerance>

The absolute error tolerance for received signals (microseconds). The default is the hardcoded driver dependent resolution value. By default irrecord sets this to 100.

header <phead> <shead>

The initial pulse and space sent (microseconds).

three <pthree> <sthree>

Only used by RC-MM remotes

two <ptwo> <stwo>

Only used by RC-MM remotes

one <pone> <sone>

The pulse and space lengths representing a one.

zero <pzero> <szero>

The pulse and space lengths representing a zero.

ptrail <trailing pulse>

A trailing pulse, immediately following the post_data.

plead <leading pulse>

A leading pulse, immediately after the header.

foot <pfoot> <sfoot>

A pulse and space, immediately following the trailing pulse.

repeat <prepeat> <srepeat>

A pulse and space that replaces everything between leading pulse and the trailing pulse, whenever a signal is repeated. The foot is not sent, and the header is not sent unless the REPEAT_HEADER flag is present.

pre_data_bits <number of pre_data_bits>

The number of bits in the pre_data code.

pre_data <hexadecimal number>

Hexadecimal code indicating the sequence of ones and zeros immediately following the leading pulse.

post_data_bits <number of post data bits>

The number of bits in the post_data code.

post_data <hexadecimal number>

Hexadecimal code indicating the sequence of ones and zeros immediately following the post signal.

pre <ppre> <spre>

A pulse and space immediately following the pre_data.

post <ppost> <spost>

A pulse and space immediately following the button code.

gap <gap length>

A (typically long) space which follows the trailing pulse.

repeat_gap <repeat_gap length>

A gap immediately following the trailing pulse, and preceding a repetition of the same code that's due to a the same press of the button.

min_repeat <minimum number of repetitions>

The minimum times a signal is repeated when sent. Note that 0 means the signal is sent only once. Not used when receiving.

toggle_bit <bit to toggle>

A bit of the pre_data, code, or post_data that is toggled between one and zero each time a button is pressed. This parameter is obsoleted by toggle_bit_mask and should be used in new configs.

toggle_bit_mask <hexadecimal mask>

Bits which are toggled between one and zero each time a button is pressed. The mask is applied to the concatenated value of pre data - data - post_data.

repeat_mask <mask>

Mask defines which bits are inverted for repeats.

frequency <hertz>

Remote carrier frequency, defaults to 38000.

duty_cycle <on time>

The percentage of time during a pulse that infrared light is being sent. This is an integer between 1-100 inclusive. default is 50.

## FLAGS
Flags are values set in the flags parameter.

RC5

The remote uses the RC5 protocol.

RC6

The remote uses the RC6 protocol.

RCMM

The remote uses the RC-MM protocol.

SHIFT_ENC

Obsolete flag, now a synonym for RC5. The position of the pulse (before or after the space) determines whether the bit is a one or a zero.

SPACE_ENC

A one and a zero can be distinguished by the length of the spaces, used by the NEC protocol and others.

REVERSE

Reverses the bit order of the pre_data, the post_data and the codes (e.g., 0x123 becomes 0xC48). If this flag is present, the least significant bit is sent first.

NO_HEAD_REP

The header is not sent when a signal (the button is held down) is repeated even though there is no special repeat code.

NO_FOOT_REP

The foot is not sent when a signal is repeated (the button is held down) even though there is no special repeat code .

CONST_LENGTH

The total signal length is always constant. The gap length now represents the length of the entire signal, and the actual gap at the end of the signal is adjusted accordingly.

RAW_CODES

The codes are in raw format.

REPEAT_HEADER

Send the header when the signal is repeated even though the remote has a special repeat code.

## DISCLAIMER
LIRC was designed to collect IR data and save it in a private, compact, yet human readable format with the purpose of being able to re-transmit (or re-recognize) these signals. It was not designed with the goal of providing a well documented and tested configuration file format that could be used e.g., to generate arbitrary IR signals or to convert them to other formats. The configuration file should thus not be considered a public interface to LIRC.

This manpage should be understood with this in mind. It was authored by reading the code of LIRC, and does not constitute an authoritative specification of the behavior of LIRC and its configuration file. Also, some less commonly used flags and parameters are not documented.

## SEE ALSO
lircd(8)

irrecord(1)

http://en.wikipedia.org/wiki/RC-5

http://www.sbprojects.com/knowledge/ir/


lircrc

title: lircrc(5)

text:
# lircrc(5)

## NAME
lircrc - application-specific remotes signals configuration

## DESCRIPTION
lircrc is the last LIRC configuration point in the flow of events from the kernel to the application. It provides a way to translate the application-agnostic events which lircd makes available on /var/run/lirc/lircd to application-specific strings. The translation is invoked by LIRC-aware applications by using the the lirc_code2char() routine in the lirc_client library.

The lircrc event mapping is not only mapping from a remote event to an application string. It also supports a variety of functionality such as repeat suppression, modes, long keypresses and button sequences.

The default location for lircrc is ~/.config/lircrc with a global fallback in /etc/lirc/lircrc. Many applications which uses the lircrc translations have private locations for the file.

The programmatic interface to the lircrc functionality is described in the Client API manual, see below

The file format is described in the configuration manual, see below.

## SEE ALSO
http://lirc.org/html/configure.html#lircrc_format

Description of the lircrc file format.

http://lirc.org/html/lirc_client.html

Client API, the programmatic interface to the lircrc files.


sensors.conf

title: sensors.conf(5)

summary: libsensors configuration file

text:
# sensors.conf(5)

## NAME
sensors.conf - libsensors configuration file

## DESCRIPTION
sensors.conf describes how libsensors, and so all programs using it, should translate the raw readings from the kernel modules to real-world values.

## SEMANTICS
On a given system, there may be one or more hardware monitoring chips. Each chip may have several features. For example, the LM78 monitors 7 voltage inputs, 3 fans and one temperature. Feature names are standardized. Typical feature names are in0, in1, in2... for voltage inputs, fan1, fan2, fan3... for fans and temp1, temp2, temp3... for temperature inputs.

Each feature may in turn have one or more sub-features, each representing an attribute of the feature: input value, low limit, high limit, alarm, etc. Sub-feature names are standardized as well. For example, the first voltage input (in0) would typically have sub-features in0_input (measured value), in0_min (low limit), in0_max (high limit) and in0_alarm (alarm flag). Which sub-features are actually present depend on the exact chip type.

The sensors.conf configuration file will let you configure each chip, feature and sub-feature in a way that makes sense for your system.

The rest of this section describes the meaning of each configuration statement.

### CHIP STATEMENT
A chip statement selects for which chips all following compute, label, ignore and set statements are meant. A chip selection remains valid until the next chip statement. Example:

chip "lm78-*" "lm79-*"

If a chip matches at least one of the chip descriptions, the following configuration lines are examined for it, otherwise they are ignored.

A chip description is built from several elements, separated by dashes. The first element is the chip type, the second element is the name of the bus, and the third element is the hexadecimal address of the chip. Such chip descriptions are printed by sensors(1) as the first line for every chip.

The name of the bus is either isa, pci, virtual, spi-*, i2c-N or mdio with N being a bus number as bound with a bus statement. This list isn't necessarily exhaustive as support for other bus types may be added in the future.

You may substitute the wildcard operator * for every element. Note however that it wouldn't make any sense to specify the address without the bus type, so the address part is plain omitted when the bus type isn't specified. Here is how you would express the following matches:

LM78 chip at address 0x2d on I2C bus 1

lm78-i2c-1-2d

LM78 chip at address 0x2d on any I2C bus

lm78-i2c-*-2d

LM78 chip at address 0x290 on the ISA bus

lm78-isa-0290

Any LM78 chip on I2C bus 1

lm78-i2c-1-*

Any LM78 on any I2C bus

lm78-i2c-*-*

Any LM78 chip on the ISA bus

lm78-isa-*

Any LM78 chip

lm78-*

Any chip at address 0x2d on I2C bus 1

*-i2c-1-2d

Any chip at address 0x290 on the ISA bus

*-isa-0290

If several chip statements match a specific chip, they are all considered.

### LABEL STATEMENT
A label statement describes how a feature should be called. Features without a label statement are just called by their feature name. Applications can use this to label the readings they present. Example:

label in3 "+5V"

The first argument is the feature name. The second argument is the feature description.

Note that you must use the raw feature name, which is not necessarily the one displayed by "sensors" by default. Use "sensors -u" to see the raw feature names. Same applies to all other statement types below.

### IGNORE STATEMENT
An ignore statement is a hint that a specific feature should be ignored - probably because it returns bogus values (for example, because a fan or temperature sensor is not connected). Example:

ignore fan1

The only argument is the feature name. Please note that this does not disable anything in the actual sensor chip; it simply hides the feature in question from libsensors users.

### COMPUTE STATEMENT
A compute statement describes how a feature's raw value should be translated to a real-world value, and how a real-world value should be translated back to a raw value again. This is most useful for voltage sensors, because in general sensor chips have a limited range and voltages outside this range must be divided (using resistors) before they can be monitored. Example:

compute in3 ((6.8/10)+1)*@, @/((6.8/10)+1)

The example above expresses the fact that the voltage input is divided using two resistors of values 6.8 Ohm and 10 Ohm, respectively. See the VOLTAGE COMPUTATION DETAILS section below for details.

The first argument is the feature name. The second argument is an expression which specifies how a raw value must be translated to a real-world value; `@' stands here for the raw value. This is the formula which will be applied when reading values from the chip. The third argument is an expression that specifies how a real-world value should be translated back to a raw value; `@' stands here for the real-world value. This is the formula which will be applied when writing values to the chip. The two formulas are obviously related, and are separated by a comma.

A compute statement applies to all sub-features of the target feature for which it makes sense. For example, the above example would affect sub-features in3_min and in3_max (which are voltage values) but not in3_alarm (which is a boolean flag.)

The following operators are supported in compute statements:

+ - * / ( ) ^ `

^x means exp(x) and `x means ln(x). You may use the name of sub-features in these expressions; current readings are substituted. You should be careful though to avoid circular references.

If at any moment a translation between a raw and a real-world value is called for, but no compute statement applies, a one-on-one translation is used instead.

### SET STATEMENT
A set statement is used to write a sub-feature value to the chip. Of course not all sub-feature values can be set that way, in particular input values and alarm flags can not. Valid sub-features are usually min/max limits. Example:

set in3_min 5 * 0.95

set in3_max 5 * 1.05

The example above basically configures the chip to allow a 5% deviance for the +5V power input.

The first argument is the feature name. The second argument is an expression which determines the written value. If there is an applying compute statement, this value is fed to its third argument to translate it to a raw value.

You may use the name of sub-features in these expressions; current readings are substituted. You should be careful though to avoid circular references.

Please note that set statements are only executed by sensors(1) when you use the -s option. Typical graphical sensors applications do not care about these statements at all.

### BUS STATEMENT
A bus statement binds the description of an I2C or SMBus adapter to a bus number. This makes it possible to refer to an adapter in the configuration file, independent of the actual correspondence of bus numbers and actual adapters (which may change from moment to moment). Example:

bus "i2c-0" "SMBus PIIX4 adapter at e800"

The first argument is the bus number. It is the literal text i2c-, followed by a number. As there is a dash in this argument, it must always be quoted.

The second argument is the adapter name, it must match exactly the adapter name as it appears in /sys/class/i2c-adapter/i2c-*/name. It should always be quoted as well as it will most certainly contain spaces or dashes.

The bus statements may be scattered randomly throughout the configuration file; there is no need to place the bus line before the place where its binding is referred to. Still, as a matter of good style, we suggest you place all bus statements together at the top of your configuration file.

Running sensors --bus-list will generate these lines for you.

In the case where multiple configuration files are used, the scope of each bus statement is the configuration file it was defined in. This makes it possible to have bus statements in all configuration files which will not unexpectedly interfere with each other.

### STATEMENT ORDER
Statements can go in any order, however it is recommended to put `set fanX_div' statements before `set fanX_min' statements, in case a driver doesn't preserve the fanX_min setting when the fanX_div value is changed. Even if the driver does, it's still better to put the statements in this order to avoid accuracy loss.

## VOLTAGE COMPUTATION DETAILS
Most voltage sensors in sensor chips have a range of 0 to 4.08 V. This is generally sufficient for the +3.3V and CPU supply voltages, so the sensor chip reading is the actual voltage.

Other supply voltages must be scaled with an external resistor network. The driver reports the value at the chip's pin (0 - 4.08 V), and the userspace application must convert this raw value to an actual voltage. The compute statements provide this facility.

Unfortunately the resistor values vary among motherboard types. Therefore you have to figure out the correct resistor values for your own motherboard.

For positive voltages (typically +5V and +12V), two resistors are used, with the following formula:

R1 = R2 * (Vs/Vin - 1)

where:

R1 and R2 are the resistor values

Vs is the actual voltage being monitored

Vin is the voltage at the pin

This leads to the following compute formula:

compute inX @*((R1/R2)+1), @/(((R1/R2)+1)

Real-world formula for +5V and +12V would look like:

compute in3 @*((6.8/10)+1), @/((6.8/10)+1)

compute in4 @*((28/10)+1), @/((28/10)+1)

For negative voltages (typically -5V and -12V), two resistors are used as well, but different boards use different strategies to bring the voltage value into the 0 - 4.08 V range. Some use an inverting amplifier, others use a positive reference voltage. This leads to different computation formulas. Note that most users won't have to care because most modern motherboards make little use of -12V and no use of -5V so they do not bother monitoring these voltage inputs.

Real-world examples for the inverting amplifier case:

compute in5 -@*(240/60), -@/(240/60)

compute in6 -@*(100/60), -@/(100/60)

Real-world examples for the positive voltage reference case:

compute in5 @*(1+232/56) - 4.096*232/56, (@ + 4.096*232/56)/(1+232/56)

compute in6 @*(1+120/56) - 4.096*120/56, (@ + 4.096*120/56)/(1+120/56)

Many recent monitoring chips have a 0 - 2.04 V range, so scaling resistors are even more needed, and resistor values are different.

There are also a few chips out there which have internal scaling resistors, meaning that their value is known and doesn't change from one motherboard to the next. For these chips, the driver usually handles the scaling so it is transparent to the user and no compute statements are needed.

## TEMPERATURE CONFIGURATION
On top of the usual features, temperatures can have two specific sub-features: temperature sensor type (tempX_type) and hysteresis values (tempX_max_hyst, tempX_crit_hyst etc.).

### THERMAL SENSOR TYPES
Available thermal sensor types:

1

PII/Celeron Diode

2

3904 transistor

3

thermal diode

4

thermistor

5

AMD AMDSI

6

Intel PECI

For example, to set temp1 to thermistor type, use:

set temp1_type 4

Only certain chips support thermal sensor type change, and even these usually only support some of the types above. Please refer to the specific driver documentation to find out which types are supported by your chip.

In theory, the BIOS should have configured the sensor types correctly, so you shouldn't have to touch them, but sometimes it isn't the case.

### THERMAL HYSTERESIS MECHANISM
Many monitoring chips do not handle the high and critical temperature limits as simple limits. Instead, they have two values for each limit, one which triggers an alarm when the temperature rises and another one which clears the alarm when the temperature falls. The latter is typically a few degrees below the former. This mechanism is known as hysteresis.

The reason for implementing things that way is that high temperature alarms typically trigger an action to attempt to cool the system down, either by scaling down the CPU frequency, or by kicking in an extra fan. This should normally let the temperature fall in a timely manner. If this was clearing the alarm immediately, then the system would be back to its original state where the temperature rises and the alarm would immediately trigger again, causing an undesirable tight fan on, fan off loop. The hysteresis mechanism ensures that the system is really cool before the fan stops, so that it will not have to kick in again immediately.

So, in addition to tempX_max, many chips have a tempX_max_hyst sub-feature. Likewise, tempX_crit often comes with tempX_crit_hyst. tempX_emerg_hyst, tempX_min_hyst and tempX_lcrit_hyst exist too but aren't as common. Example:

set temp1_max 60

set temp1_max_hyst 56

The hysteresis mechanism can be disabled by giving both limits the same value.

Note that it is strongly recommended to set the hysteresis value after the limit value it relates to in the configuration file. Implementation details on the hardware or driver side may cause unexpected results if the hysteresis value is set first.

## BEEPS
Some chips support alarms with beep warnings. When an alarm is triggered you can be warned by a beeping signal through your computer speaker. On top of per-feature beep flags, there is usually a master beep control switch to enable or disable beeping globally. Enable beeping using:

set beep_enable 1

or disable it using:

set beep_enable 0

## WHICH STATEMENT APPLIES
If more than one statement of the same kind applies at a certain moment, the last one in the configuration file is used. So usually, you should put more general chip statements at the top, so you can overrule them below.

## SYNTAX
Comments are introduced by hash marks. A comment continues to the end of the line. Empty lines, and lines containing only whitespace or comments are ignored. Other lines have one of the below forms. There must be whitespace between each element, but the amount of whitespace is unimportant. A line may be continued on the next line by ending it with a backslash; this does not work within a comment, NAME or NUMBER.

bus NAME NAME NAME chip NAME-LIST

label NAME NAME

compute NAME EXPR , EXPR

ignore NAME

set NAME EXPR

A NAME is a string. If it only contains letters, digits and underscores, it does not have to be quoted; in all other cases, you must use double quotes around it. Within quotes, you can use the normal escape-codes from C.

A NAME-LIST is one or more NAME items behind each other, separated by whitespace.

A EXPR is of one of the below forms:

NUMBER NAME

@

EXPR + EXPR

EXPR - EXPR

EXPR * EXPR

EXPR / EXPR

- EXPR

^ EXPR

` EXPR

( EXPR )

A NUMBER is a floating-point number. `10', `10.4' and `.4' are examples of valid floating-point numbers; `10.' or `10E4' are not valid.

## FILES
/etc/sensors3.conf

/etc/sensors.conf

The system-wide libsensors(3) configuration file. /etc/sensors3.conf is tried first, and if it doesn't exist, /etc/sensors.conf is used instead.

/etc/sensors.d

A directory where you can put additional libsensors configuration files. Files found in this directory will be processed in alphabetical order after the default configuration file. Files with names that start with a dot are ignored.

## SEE ALSO
libsensors(3)

## AUTHOR
Frodo Looijaard and the lm_sensors group https://hwmon.wiki.kernel.org/lm_sensors


logwatch.conf

package: logwatch

title: logwatch.conf(5)

text:
# logwatch.conf(5)

## NAME
logwatch.conf, ignore.conf, override.conf - logwatch configuration files

## DESCRIPTION
logwatch.conf - ( /etc/logwatch/conf/logwatch.conf ) - can contain the local configuration options. The list of valid settings and their default values are in /usr/share/logwatch/default.conf/logwatch.conf.

ignore.conf - ( /etc/logwatch/conf/ignore.conf ) is the list of regular expressions. The set of logs decribed by this set is ignored by logwatch.

override.conf - ( /etc/logwatch/conf/override.conf ) contains the settings which overrides the standard configuration of specific log files or services. The syntax is the same as in log/service files.

## FILES
/etc/logwatch/conf/logwatch.conf /etc/logwatch/conf/logwatch.conf /etc/logwatch/conf/logwatch.conf /usr/share/logwatch/default.conf/logwatch.conf

## SEE ALSO
logwatch(8)


lrzip.conf

package: lrzip

title: lrzip.conf(5)

summary: Configuration File for lrzip

text:
# lrzip.conf(5)

## NAME
lrzip.conf - Configuration File for lrzip

## DESCRIPTION
This file if used, will be read by the lrzip program, parsed, and options passed to the program. Some options may be overridden on the command line. Others are fixed.

The configuration file must be called lrzip.conf. The lrzip program will search for the file automatically in one of three places:

```
$PWD - Current Directory
/etc/lrzip
$HOME/./lrzip
```

```
Parameters are set in PARAMETER=VALUE fashion where any line
beginning with a # or that is blank will be ignored.
Parameter values are not case sensitive.
```

## CONFIG FILE EXAMPLE

```
# This is a comment.
# Compression Window size in 100MB. Normally selected by program.
# WINDOW = 5
# Compression Level 1-9 (7 Default).
# COMPRESSIONLEVEL = 7
# Unlimited Ram Compression
# UNLIMITED = YES
# Compression Method, rzip, gzip, bzip2, lzo, or lzma (default), zpaq.
# COMPRESSIONMETHOD = LZMA
# Perform LZO Test. Default = YES (-T option, NO)
# LZOTEST = NO
# Hash Check on decompression, YES
# HASHCHECK = YES
# Show HASH value on Compression even if Verbose is off, YES
# SHOWHASH = YES
# Default output directory
# OUTPUTDIRECTORY = location
# Verbosity, Yes or Max
# VERBOSITY = MAX
# Show Progress as file is parsed, YES, NO (yes is default)
# SHOWPROGRESS = NO
# Set Niceness. 19 is default. -20 to 19 is the allowable range
# NICE = 19
# Keep broken or damaged output files, YES
# KEEPBROKEN = YES
# Delete source file after compression
# this parameter and value are case sensitive
# value must be YES to activate
# DELETEFILES = NO
# Replace existing lrzip file when compressing
# this parameter and value are case sensitive
# value must be YES to activate
# REPLACEFILE = NO
# Select Temporary Directory when stdin/stdout or Test file is used
# TMPDIR = /tmp
```

## NOTES
Be careful when using DELETEFILES or REPLACEFILE as no warning will be given and lrzip will simply delete the source or replace the output file!

## SEE ALSO
lrzip(1)


ltrace.conf

package: ltrace

title: ltrace.conf(5)

summary: Configuration file for ltrace(1).

text:
# ltrace.conf(5)

## NAME
ltrace.conf - Configuration file for ltrace(1).

## DESCRIPTION
This manual page describes ltrace.conf, a file that describes prototypes of functions in binaries for ltrace(1) to use. Ltrace needs this information to display function call arguments.

Each line of a configuration file describes at most a single item. Lines composed entirely of white space are ignored, as are lines starting with semicolon or hash characters (comment lines). Described items can be either function prototypes, or definitions of type aliases.

## PROTOTYPES
A prototype describes return type and parameter types of a single function. The syntax is as follows:

[function] LENS NAME ([LENS{,LENS}]);

NAME is the (mangled) name of a symbol. In the elementary case, LENS is simply a type. Both lenses and types are described below. The function keyword, if present, has no effect. It can be used to force a line to be interpreted as a function prototype when the return type is a keyword that would start a different type of line (such as import).

For example, a simple function prototype might look like this:

int kill(int,int);

Despite the apparent similarity with C, ltrace.conf is really its own language that's only somewhat inspired by C.

## TYPES
Ltrace understands a range of primitive types. Those are interpreted according to C convention native on a given architecture. E.g. ulong is interpreted as 4-byte unsigned integer on 32-bit GNU/Linux machine, but 8-byte unsigned integer on 64-bit GNU/Linux machine.

void

Denotes that a function does not return anything. Can be also used to construct a generic pointer, i.e. pointer-sized number formatted in hexadecimal format.

char

8-bit quantity rendered as a character

ushort,short

Denotes unsigned or signed short integer.

uint,int

Denotes unsigned or signed integer.

ulong,long

Denotes unsigned or signed long integer.

float

Denotes floating point number with single precision.

double

Denotes floating point number with double precision.

Besides primitive types, the following composed types are possible:

struct([LENS{,LENS}])

Describes a structure with given types as fields, e.g. struct(int,int,float). Alignment is computed as customary on the architecture. Custom alignment (e.g. packed structs) and bit-fields are not supported. It's also not possible to differentiate between structs and non-POD C++ classes, for arches where it makes a difference.

array(LENS,EXPR)

Describes array of length EXPR, which is composed of types described by LENS, e.g. array(int, 6). Note that in C, arrays in role of function argument decay into pointers. Ltrace currently handles this automatically, but for full formal correctness, any such arguments should be described as pointers to arrays.

LENS*

Describes a pointer to a given type, e.g. char* or int***. Note that the former example actually describes a pointer to a character, not a string. See below for string lens, which is applicable to these cases.

## LENSES
Lenses change the way that types are described. In the simplest case, a lens is directly a type. Otherwise a type is decorated by the lens. Ltrace understands the following lenses:

oct(TYPE)

The argument, which should be an integer type, is formatted in base-8.

hex(TYPE)

The argument, which should be an integer or floating point type, is formatted in base-16. Floating point arguments are converted to double and then displayed using the %a fprintf modifier.

hide(TYPE)

The argument is not shown in argument list.

bool(TYPE)

Arguments with zero value are shown as "false", others are shown as "true".

bitvec(TYPE)

Underlying argument is interpreted as a bit vector and a summary of bits set in the vector is displayed. For example if bits 3,4,5 and 7 of the bit vector are set, ltrace shows <3-5,7>. Empty bit vector is displayed as <>. If there are more bits set than unset, inverse is shown instead: e.g. ~<0> when a number 0xfffffffe is displayed. Full set is thus displayed ~<>. If the underlying type is integral, then bits are shown in their natural big-endian order, with LSB being bit 0. E.g. bitvec(ushort) with value 0x0102 would be displayed as <1,8>, irrespective of underlying byte order.

For other data types (notably structures and arrays), the underlying data is interpreted byte after byte. Bit 0 of first byte has number 0, bit 0 of second byte number 8, and so on. Thus bitvec(struct(int)) is endian sensitive, and will show bytes comprising the integer in their memory order. Pointers are first dereferenced, thus bitvec(array(char, 32)*) is actually a pointer to 256-bit bit vector.

string(TYPE)

string[EXPR]

string

The first form of the argument is canonical, the latter two are syntactic sugar. In the canonical form, the function argument is formatted as string. The TYPE can have either of the following forms: X*, or array(X,EXPR), or array(X,EXPR)*. X is either char for normal strings, or an integer type for wide-character strings. If an array is given, the length will typically be a zero expression (but doesn't have to be). Using argument that is plain array (i.e. not a pointer to array) makes sense e.g. in C structs, in cases like struct(string(array(char, 6))), which describes the C type struct {char s[6];}.

Because simple C-like strings are pretty common, there are two shorthand forms. The first shorthand form (with brackets) means the same as string(array(char, EXPR)*). Plain string without an argument is then taken to mean the same as string[zero].

Note that char* by itself describes a pointer to a char. Ltrace will dereference the pointer, and read and display the single character that it points to.

enum(NAME[=VALUE]{,NAME[=VALUE]})

enum[TYPE](NAME[=VALUE]{,NAME[=VALUE]})

This describes an enumeration lens. If an argument has any of the given values, it is instead shown as the corresponding NAME. If a VALUE is omitted, the next consecutive value following after the previous VALUE is taken instead. If the first VALUE is omitted, it's 0 by default. TYPE, if given, is the underlying type. It is thus possible to create enums over shorts or longs—arguments that are themselves plain, non-enum types in C, but whose values can be meaningfully described as enumerations. If omitted, TYPE is taken to be int.

## TYPE ALIASES
A line in config file can, instead of describing a prototype, create a type alias. Instead of writing the same enum or struct on many places (and possibly updating when it changes), one can introduce a name for such type, and later just use that name:

typedef NAME = LENS;

## IMPORT DIRECTIVES
It's possible for config files to import definitions from other config files. A line of the form:

import "FILENAME";

will make all definitions from FILENAME.conf available in the current file. The imported file is searched for in the same directories as when looking up a config file corresponding to a library; see ltrace(1) for details.

## RECURSIVE STRUCTURES
Ltrace allows you to express recursive structures. Such structures are expanded to the depth described by the parameter -A. To declare a recursive type, you first have to introduce the type to ltrace by using forward declaration. Then you can use the type in other type definitions in the usual way:

typedef NAME = struct;

typedef NAME = struct(NAME can be used here)

For example, consider the following singy-linked structure and a function that takes such list as an argument:

typedef int_list = struct;

typedef int_list = struct(int, int_list*);

void ll(int_list*);

Such declarations might lead to an output like the following:

ll({ 9, { 8, { 7, { 6, ... } } } }) = <void>

Ltrace detects recursion and will not expand already-expanded structures. Thus a doubly-linked list would look like the following:

typedef int_list = struct;

typedef int_list = struct(int, int_list*, int_list*);

With output e.g. like:

ll({ 9, { 8, { 7, { 6, ..., ... }, recurse^ }, recurse^ }, nil })

The "recurse^" tokens mean that given pointer points to a structure that was expanded in the previous layer. Simple "recurse" would mean that it points back to this object. E.g. "recurse^^^" means it points to a structure three layers up. For doubly-linked list, the pointer to the previous element is of course the one that has been just expanded in the previous round, and therefore all of them are either recurse^, or nil. If the next and previous pointers are swapped, the output adjusts correspondingly:

ll({ 9, nil, { 8, recurse^, { 7, recurse^, { 6, ..., ... } } } })

## EXPRESSIONS
Ltrace has support for some elementary expressions. Each expression can be either of the following:

NUM

An integer number.

argNUM

Value of NUM-th argument. The expression has the same value as the corresponding argument. arg1 refers to the first argument, arg0 to the return value of the given function.

retval

Return value of function, same as arg0.

eltNUM

Value of NUM-th element of the surrounding structure type. E.g. struct(ulong,array(int,elt1)) describes a structure whose first element is a length, and second element an array of ints of that length.

zero

zero(EXPR)

Describes array which extends until the first element, whose each byte is 0. If an expression is given, that is the maximum length of the array. If NUL terminator is not found earlier, that's where the array ends.

## PARAMETER PACKS
Sometimes the actual function prototype varies slightly depending on the exact parameters given. For example, the number and types of printf parameters are not known in advance, but ltrace might be able to determine them in runtime. This feature has wider applicability, but currently the only parameter pack that ltrace supports is printf-style format string itself:

format

When format is seen in the parameter list, the underlying string argument is parsed, and GNU-style format specifiers are used to determine what the following actual arguments are. E.g. if the format string is "%s %d\n", it's as if the format was replaced by string, string, int.

## RETURN ARGUMENTS
C functions often use one or more arguments for returning values back to the caller. The caller provides a pointer to storage, which the called function initializes. Ltrace has some support for this idiom.

When a traced binary hits a function call, ltrace first fetches all arguments. It then displays left portion of the argument list. Only when the function returns does ltrace display right portion as well. Typically, left portion takes up all the arguments, and right portion only contains return value. But ltrace allows you to configure where exactly to put the dividing line by means of a + operator placed in front of an argument:

int asprintf(+string*, format);

Here, the first argument to asprintf is denoted as return argument, which means that displaying the whole argument list is delayed until the function returns:

a.out->asprintf( <unfinished ...>

libc.so.6->malloc(100) = 0x245b010

[... more calls here ...]

<... asprintf resumed> "X=1", "X=%d", 1) = 5

It is currently not possible to have an "inout" argument that passes information in both directions.

## EXAMPLES
In the following, the first is the C prototype, and following that is ltrace configuration line.

void func_charp_string(char str[]);

void func_charp_string(string);

enum e_foo {RED, GREEN, BLUE};

void func_enum(enum e_foo bar);

void func_enum(enum(RED,GREEN,BLUE)); - or -

typedef e_foo = enum(RED,GREEN,BLUE);

void func_enum(e_foo);

void func_arrayi(int arr[], int len);

void func_arrayi(array(int,arg2)*,int);

struct S1 {float f; char a; char b;};

struct S2 {char str[6]; float f;};

struct S1 func_struct(int a, struct S2, double d);

struct(float,char,char) func_struct(int, struct(string(array(char, 6)),float), double);

## AUTHOR
Petr Machata <pmachata@redhat.com>


ltxml-query

package: ltxml

title: ltxml-query(5)

summary: LT NSL query language

text:
# ltxml-query(5)

## NAME
ltnsl-query - LT NSL query language

## DESCRIPTION
The material below may be out of date: consult LT XML documentation please.

LT NSL queries are patterns on items (SGML/XML elements) to select. A query describes a path from the root of the document to the desired element and is basically a path based with terms separated by / as follows:

<query> := <term> ('/' <term>)*

<term> := <bTerm> '*'?

<bTerm> := <aTerm> ( '|' <aTerm> )*

<aTerm> := <GI> <cond>?

<GI> := <elementName> | '.'

<cond> := '[' <index>|<atests>|<index> <atests>']'

<index> := <number>

<atests> := <atest> (' ' <atest>)*

<atest> := <aname> ( [ '=' | "!=' ] <aval>)?

Aname and aval are as per SGML, except that if the -r flag is given, aval is a regular expression.

<term>s which consist of a number of <bTerm>s separated by '|' match against any element which matches one of the <bTerms>.

A GI of . matches any tag. A condition with an index matches only the index'th sub-element of the enclosing element. Attribute tests are not exhaustive, and will match against both explicitly present and defaulted attribute values, using string equality. Bare anames are satisfied by ANY value, explicit or defaulted. Terms ending with * match any number of links in the chain, including 0.

## SEE ALSO
ltxml(1)

## AUTHOR
Henry Thompson (ht@cogsci.ed.ac.uk)

David McKelvie (dmck@cogsci.ed.ac.uk)

Language Technology Group, Human Communication Research Centre, Edinburgh University,

2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND

Tel:(44) 131 650-4630

Fax:(44) 131 650-4587 email: dmck@cogsci.ed.ac.uk

Comments, suggestions, and bug reports are always welcome.


lvm.conf

title: lvm.conf(5)

summary: Configuration file for LVM2

text:
# lvm.conf(5)

## NAME
lvm.conf — Configuration file for LVM2

## SYNOPSIS
/etc/lvm/lvm.conf

## DESCRIPTION
lvm.conf is loaded during the initialisation phase of lvm(8). This file can in turn lead to other files being loaded - settings read in later override earlier settings. File timestamps are checked between commands and if any have changed, all the files are reloaded.

For a description of each lvm.conf(5) setting, run:

lvmconfig --typeconfig default --withcomments --withspaces

The settings defined in lvm.conf can be overridden by any of these extended configuration methods:

direct config override on command line

The --config ConfigurationString command line option takes the ConfigurationString as direct string representation of the configuration to override the existing configuration. The ConfigurationString is of exactly the same format as used in any LVM configuration file.

profile config

A profile is a set of selected customizable configuration settings that are aimed to achieve a certain characteristics in various environments or uses. It's used to override existing configuration. Normally, the name of the profile should reflect that environment or use.

There are two groups of profiles recognised: command profiles and metadata profiles.

The command profile is used to override selected configuration settings at global LVM command level - it is applied at the very beginning of LVM command execution and it is used throughout the whole time of LVM command execution. The command profile is applied by using the --commandprofile ProfileName command line option that is recognised by all LVM2 commands.

The metadata profile is used to override selected configuration settings at Volume Group/Logical Volume level - it is applied independently for each Volume Group/Logical Volume that is being processed. As such, each Volume Group/Logical Volume can store the profile name used in its metadata so next time the Volume Group/Logical Volume is processed, the profile is applied automatically. If Volume Group and any of its Logical Volumes have different profiles defined, the profile defined for the Logical Volume is preferred. The metadata profile can be attached/detached by using the lvchange and vgchange commands and their --metadataprofile ProfileName and --detachprofile options or the --metadataprofile option during creation when using vgcreate or lvcreate command. The vgs and lvs reporting commands provide -o vg_profile and -o lv_profile output options to show the metadata profile currently attached to a Volume Group or a Logical Volume.

The set of options allowed for command profiles is mutually exclusive when compared to the set of options allowed for metadata profiles. The settings that belong to either of these two sets can't be mixed together and LVM tools will reject such profiles.

LVM itself provides a few predefined configuration profiles. Users are allowed to add more profiles with different values if needed. For this purpose, there's the command_profile_template.profile (for command profiles) and metadata_profile_template.profile (for metadata profiles) which contain all settings that are customizable by profiles of certain type. Users are encouraged to copy these template profiles and edit them as needed. Alternatively, the lvmconfig --file <ProfileName.profile> --type profilable-command <section> or lvmconfig --file <ProfileName.profile> --type profilable-metadata <section> can be used to generate a configuration with profilable settings in either of the type for given section and save it to new ProfileName.profile (if the section is not specified, all profilable settings are reported).

The profiles are stored in /etc/lvm/profile directory by default. This location can be changed by using the config/profile_dir setting. Each profile configuration is stored in ProfileName.profile file in the profile directory. When referencing the profile, the .profile suffix is left out.

tag config

See tags configuration setting description below.

When several configuration methods are used at the same time and when LVM looks for the value of a particular setting, it traverses this config cascade from left to right:

direct config override on command line → command profile config → metadata profile config → tag config → lvmlocal.conf → lvm.conf

No part of this cascade is compulsory. If there's no setting value found at the end of the cascade, a default value is used for that setting. Use lvmconfig to check what settings are in use and what the default values are.

## SYNTAX
This section describes the configuration file syntax.

Whitespace is not significant unless it is within quotes. This provides a wide choice of acceptable indentation styles. Comments begin with # and continue to the end of the line. They are treated as whitespace.

Here is an informal grammar:

file = value*

A configuration file consists of a set of values.

value = section | assignment

A value can either be a new section, or an assignment.

section = identifier '{' value* '}'

A section groups associated values together. If the same section is encountered multiple times, the contents of all instances are concatenated together in the order of appearance.

It is denoted by a name and delimited by curly brackets.

e.g. backup {

...

}

assignment = identifier '=' ( array | type )

An assignment associates a type with an identifier. If the identifier contains forward slashes, those are interpreted as path delimiters. The statement section/key = value is equivalent to section { key = value }. If multiple instances of the same key are encountered, only the last value is used (and a warning is issued).

e.g. level = 7

array = '[' ( type ',')* type ']' | '[' ']'

Inhomogeneous arrays are supported.

Elements must be separated by commas.

An empty array is acceptable.

type = integer|float|string

integer = [0-9]*

float = [0-9]*'.'[0-9]*

string = '"' .* '"'

Strings with spaces must be enclosed in double quotes, single words that start with a letter can be left unquoted.

## SETTINGS
The lvmconfig command prints the LVM configuration settings in various ways. See the man page lvmconfig(8).

Command to print a list of all possible config settings, with their default values:

lvmconfig --type default

Command to print a list of all possible config settings, with their default values, and a full description of each as a comment:

lvmconfig --type default --withcomments

Command to print a list of all possible config settings, with their current values (configured, non-default values are shown):

lvmconfig --type current

Command to print all config settings that have been configured with a different value than the default (configured, non-default values are shown):

lvmconfig --type diff

Command to print a single config setting, with its default value, and a full description, where "Section" refers to the config section, e.g. global, and "Setting" refers to the name of the specific setting, e.g. umask:

lvmconfig --type default --withcomments Section/Setting

## FILES
/etc/lvm/lvm.conf

/etc/lvm/lvmlocal.conf

/etc/lvm/archive

/etc/lvm/backup

/etc/lvm/cache/.cache

/etc/lvm/profile

/run/lock/lvm

## SEE ALSO
lvm(8), lvmconfig(8)


lxc-usernet

package: lxc-core

title: lxc-usernet(5)

text:
# lxc-usernet(5)

## NAME
lxc-usernet - unprivileged user network administration file.

## DESCRIPTION
/etc/lxc/lxc-usernet controls the limits which the program lxc-user-nic places on network interfaces which an unprivileged user may create.

### CONFIGURATION
This file consists of multiple entries, one per line, of the form:

user type bridge number

or

@group type bridge number

Where

user

is the username to whom this entry applies.

@group

is the groupname to which this entry applies.

type

is the type of network interface being allowed. Only veth is currently supported.

bridge

is the bridge to which the network interfaces may be attached, for instance lxcbr0.

number

is the number or quota of network interfaces of the given type which the given user or group may attach to the given bridge, for instance 2.

Since a user can be specified both by username as well as one or more usergroups, it is possible that several configuration lines enable that user to create network interfaces. In such cases, any interfaces create are counted towards the quotas of the user or group in the order in which they appear in the file. If the quota of one line is full, the rest will be parsed until one is found or the end of the file.

## SEE ALSO
lxc(1), lxc-user-nic(1)

## AUTHOR
Daniel Lezcano <daniel.lezcano@free.fr>


lxc.conf

title: lxc.conf(5)

summary: Configuration files for LXC.

text:
# lxc.conf(5)

## NAME
lxc.conf - Configuration files for LXC.

## DESCRIPTION
LXC configuration is split in two parts. Container configuration and system configuration.

### CONTAINER CONFIGURATION
The container configuration is held in the config stored in the container's directory.

A basic configuration is generated at container creation time with the default's recommended for the chosen template as well as extra default keys coming from the default.conf file.

That default.conf file is either located at /etc/lxc/default.conf or for unprivileged containers at ~/.config/lxc/default.conf.

Details about the syntax of this file can be found in: lxc.container.conf(5)

### SYSTEM CONFIGURATION
The system configuration is located at /etc/lxc/lxc.conf or ~/.config/lxc/lxc.conf for unprivileged containers.

This configuration file is used to set values such as default lookup paths and storage backend settings for LXC.

Details about the syntax of this file can be found in: lxc.system.conf(5)

## SEE ALSO
lxc(1), lxc.container.conf(5), lxc.system.conf(5), lxc-usernet(5)

## AUTHOR
Stéphane Graber <stgraber@ubuntu.com>