systemd-debug-generator

title: systemd-debug-generator(8)

text:
# systemd-debug-generator(8)

## NAME
systemd-debug-generator - Generator for enabling a runtime debug shell and masking specific units at boot

## SYNOPSIS
/usr/lib/systemd/system-generators/systemd-debug-generator

## DESCRIPTION
systemd-debug-generator is a generator that provides some debugging functionality.

systemd-debug-generator implements systemd.generator(7).

## KERNEL COMMAND LINE
systemd-debug-generator understands the following kernel command line parameters:

systemd.mask=, rd.systemd.mask=

These options take a unit name as argument. The unit specified is masked for the runtime (i.e. for this session — from boot to shutdown), similarly to the effect of systemctl(1)'s mask command. This is useful to boot with certain units removed from the initial boot transaction for debugging system startup. May be specified more than once. The option prefixed with "rd." is honored only in the initrd, while the one without prefix is only honored on the host. Added in version 215.

systemd.wants=, rd.systemd.wants=

These options take a unit name as argument. A start job for this unit is added to the initial transaction. This is useful to start one or more additional units at boot. May be specified more than once. The option prefixed with "rd." is honored only in the initrd, while the one that is not prefixed only on the host. Added in version 215.

systemd.debug_shell, rd.systemd.debug_shell, systemd.default_debug_tty=, rd.systemd.default_debug_tty=

If the systemd.debug_shell or rd.systemd.debug_shell option is specified, the debug shell service "debug-shell.service" is pulled into the boot transaction and a debug shell will be spawned during early boot. By default, /dev/tty9 is used, but a specific tty can also be specified, either with or without the /dev/ prefix. To set the tty to use without enabling the debug shell, the systemd.default_debug_tty= option can be used which also takes a tty with or without the /dev/ prefix. Note that the shell may also be turned on persistently by enabling it with systemctl(1)'s enable command. The options prefixed with "rd." are honored only in the initrd, while the ones without prefix are only honored on the host. Added in version 215.

systemd.break=, rd.systemd.break=

Takes one of pre-udev, pre-basic, pre-mount, or pre-switch-root (the default for the "rd." option). It also accepts multiple values separated by comma (","). These options allow one to pause the boot process at a certain point and spawn a debug shell. After exiting this shell, the system will resume booting. The option prefixed with "rd." is honored only in the initrd, while the one without prefix is only honored on the host. Table 1. Available breakpoints

Breakpoints

Description

Can be used in the initrd

Can be used on the host

pre-udev

Before starting to process kernel uevents, i.e., before systemd-udevd.service starts.

✓

✓

pre-basic

Before leaving early boot and regular services start, i.e., before basic.target is reached.

✓

✓

pre-mount

Before the root filesystem is mounted, i.e., before sysroot.mount starts.

✓

✗

pre-switch-root

Before switching from the initrd to the real root.

✓

✗

Added in version 258.

## SYSTEM CREDENTIALS
systemd.extra-unit.*

Credentials prefixed with "systemd.extra-unit." specify additional units to add to the final system. Note that these additional units are added to both the initrd and the final system. ConditionPathExists=!/etc/initrd-release can be used to make sure the unit is conditioned out in the initrd. Note that this can also be used to mask units, by simply specifying an empty value. Added in version 256.

systemd.unit-dropin.*

Credentials prefixed with "systemd.unit-dropin." add drop-ins for the corresponding units in the final system. Each credential must be suffixed with the full unit name including the unit extension. Its contents must be a valid unit drop-in file. Optionally, the unit name may be followed with "~", followed by the drop-in name without the ".conf" suffix. If not specified, the name of the generated drop-in will be "50-credential.conf". Note that these additional drop-ins are added to both the initrd and the final system. Added in version 256.

## SEE ALSO
systemd(1), systemctl(1), kernel-command-line(7), systemd.system-credentials(7), bootup(7)


systemd-environment-d-generator

package: systemd

title: systemd-environment-d-generator(8)

text:
# systemd-environment-d-generator(8)

## NAME
systemd-environment-d-generator, 30-systemd-environment-d-generator - Load variables specified by environment.d

## SYNOPSIS
/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator

## DESCRIPTION
systemd-environment-d-generator is a systemd.environment-generator(7) that reads environment configuration specified by environment.d(5) configuration files and passes it to the systemd(1) user manager instance.

## SEE ALSO
systemd(1), systemctl(1), systemd.environment-generator(7), systemd.generator(7)

branch: sisyphus


systemd-factory-reset

title: systemd-factory-reset(8)

text:
# systemd-factory-reset(8)

## NAME
systemd-factory-reset, systemd-factory-reset-request.service, systemd-factory-reset-complete.service, systemd-factory-reset.socket, systemd-factory-reset@.service - Request or complete a factory reset operation, or query current factory reset mode

## SYNOPSIS
/usr/lib/systemd/systemd-factory-reset

systemd-factory-reset-request.service

systemd-factory-reset-complete.service

systemd-factory-reset.socket

systemd-factory-reset@.service

## DESCRIPTION
systemd-factory-reset is a tool that can query the current factory reset state, request factory request operations or complete them.

Some of the functionality is also available via the /run/systemd/io.systemd.FactoryReset Varlink service (implemented via the systemd-factory-reset.socket/systemd-factory-reset@.service units).

See Factory Reset[1] for an overview of the factory reset logic.

## COMMANDS
The /usr/lib/systemd/systemd-factory-reset executable may also be invoked from the command line, taking one of the following command arguments:

status

Report current factory reset state. Reports one of "unsupported" (if the OS does not support a factory reset logic), "unspecified" (if no factory reset was requested, but it wasn't turned off explicitly either), "off" (if the factory reset logic was explicitly turned off via the kernel command line option), "on" (if the factory reset is currently enabled and executed), "complete" (if the factory reset logic ran during the current boot but is complete now), "pending" (if a factory reset has been requested for the next boot). Returns with an exit status of 0 if the factory reset mechanism is currently not in effect, 10 if a factory reset is currently being executed, or 11 if it is pending for the next boot.

Added in version 258.

request

Request a factory reset operation to be executed on next boot. Note that this is a relatively low-level operation. The primary interface for requesting a factory reset operation is by starting the factory-reset.target unit.

This sets the FactoryResetRequest EFI variable, see below.

This operation is executed when the systemd-factory-reset-request.service unit is started (which is typically one of the services hooked into and ordered before factory-reset.target).

Added in version 258.

cancel

Cancel any previously requested (but not yet executed) factory reset operation. Added in version 258.

complete

Mark an ongoing factory reset operation as complete. This operation is executed when the systemd-factory-reset-complete.service unit is started (which is typically one of the services hooked into and ordered after factory-reset-now.target).

Added in version 258.

## OPTIONS
The following options are understood:

--retrigger

When used with the complete command retriggers all block devices, which might result in auto-discovered devices being usable that previously weren't because the factory reset logic was in place. Added in version 258.

--quiet, -q

Suppresses the state output of status, but still sets the exit status as documented. Added in version 258.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## EFI VARIABLES
The following EFI variable is set and read by systemd-factory-reset, under the vendor UUID "8cf2644b-4b0b-428f-9387-6d876050dc67", for communication between this boot and the next.

FactoryResetRequest

Set whenever a factory reset is requested from the next boot, deleted once the factory reset is complete. Contains JSON data describing the requesting OS, in order to avoid confusion in multi-boot systems. Added in version 258.

## SEE ALSO
systemd(1), systemd-factory-reset-generator(8), systemd.special(7), Factory Reset[1]

## NOTES
1.

Factory Reset

https://systemd.io/FACTORY_RESET


systemd-factory-reset-generator

title: systemd-factory-reset-generator(8)

summary: Pull factory\-reset\-now.target into the initial boot transaction when factory reset has been requested

text:
# systemd-factory-reset-generator(8)

## NAME
systemd-factory-reset-generator - Pull factory-reset-now.target into the initial boot transaction when factory reset has been requested

## SYNOPSIS
/usr/lib/systemd/system-generators/systemd-factory-reset-generator

## DESCRIPTION
systemd-factory-reset-generator is a generator that pulls factory-reset-now.target into the initial boot transaction when the factory reset operation has been requested, either via the systemd.factory_reset= kernel command line option or via the FactoryResetRequest EFI variable.

systemd-factory-reset-generator implements systemd.generator(7).

## SEE ALSO
systemd(1), systemd-factory-reset(8), Factory Reset[1]

## NOTES
1.

Factory Reset

https://systemd.io/FACTORY_RESET


systemd-fsck@.service

title: systemd-fsck@.service(8)

summary: File system checker logic

text:
# systemd-fsck@.service(8)

## NAME
systemd-fsck@.service, systemd-fsck-root.service, systemd-fsck-usr.service, systemd-fsck - File system checker logic

## SYNOPSIS
systemd-fsck@.service

systemd-fsck-root.service

systemd-fsck-usr.service

/usr/lib/systemd/systemd-fsck

## DESCRIPTION
systemd-fsck@.service, systemd-fsck-root.service, and systemd-fsck-usr.service are services responsible for file system checks. They are instantiated for each device that is configured for file system checking. systemd-fsck-root.service and systemd-fsck-usr.service are responsible for file system checks on the root and /usr file system, respectively, but only if the root filesystem was not checked in the initrd. systemd-fsck@.service is used for all other file systems and for the root file system in the initrd.

These services are started at boot if passno in /etc/fstab for the file system is set to a value greater than zero, but only if it is also configured to be mounted at boot (i.e. without "noauto" option). The file system check for root is performed before the other file systems. Other file systems may be checked in parallel, except when they are on the same rotating disk.

systemd-fsck does not know any details about specific filesystems, and simply executes file system checkers specific to each filesystem type (fsck.type). These checkers will decide if the filesystem should actually be checked based on the time since last check, number of mounts, unclean unmount, etc.

systemd-fsck-root.service and systemd-fsck-usr.service will activate reboot.target if fsck(8) returns the "System should reboot" condition, or emergency.target if fsck returns the "Filesystem errors left uncorrected" condition.

systemd-fsck@.service will fail if fsck(8) returns either the "System should reboot" or the "Filesystem errors left uncorrected" condition. For filesystems listed in /etc/fstab without "nofail" or "noauto" options, local-fs.target will then activate emergency.target.

## KERNEL COMMAND LINE
systemd-fsck understands these kernel command line parameters:

fsck.mode=

One of "auto", "force", "skip". Controls the mode of operation. The default is "auto", and ensures that file system checks are done when the file system checker deems them necessary. "force" unconditionally results in full file system checks. "skip" skips any file system checks. Added in version 186.

fsck.repair=

One of "preen", "yes", "no". Controls the mode of operation. The default is "preen", and will automatically repair problems that can be safely fixed. "yes" will answer yes to all questions by fsck and "no" will answer no to all questions. Added in version 213.

## CREDENTIALS
systemd-fsck supports the service credentials logic as implemented by ImportCredential=/LoadCredential=/SetCredential= (see systemd.exec(5) for details). The following credentials are used when passed in:

fsck.mode, fsck.repair

The contents of the credentials are parsed as same as the kernel command line options with the same name. See above for more details. Added in version 258.

Note that by default the systemd-fsck@.service, systemd-fsck-root.service, and systemd-fsck-usr.service unit files are set up to inherit both fsck.mode and fsck.repair credentials from the service manager.

## SEE ALSO
systemd(1), fsck(8), systemd-quotacheck@.service(8), fsck.btrfs(8), fsck.cramfs(8), fsck.ext4(8), fsck.fat(8), fsck.hfsplus(8), fsck.minix(8), fsck.ntfs(8), fsck.xfs(8)


systemd-fstab-generator

title: systemd-fstab-generator(8)

summary: Unit generator for /etc/fstab

text:
# systemd-fstab-generator(8)

## NAME
systemd-fstab-generator - Unit generator for /etc/fstab

## SYNOPSIS
/usr/lib/systemd/system-generators/systemd-fstab-generator

## DESCRIPTION
systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded. This will instantiate mount and swap units as necessary.

The passno field is treated like a simple boolean, and the ordering information is discarded. However, if the root file system is checked, it is checked before all the other file systems.

See systemd.mount(5) and systemd.swap(5) for more information about special /etc/fstab mount options this generator understands.

One special topic is handling of symbolic links. Historical init implementations supported symlinks in /etc/fstab. Because mount units will refuse mounts where the target is a symbolic link, this generator will resolve any symlinks as far as possible when processing /etc/fstab in order to enhance backwards compatibility. If a symlink target does not exist at the time that this generator runs, it is assumed that the symlink target is the final target of the mount.

systemd-fstab-generator implements systemd.generator(7).

## KERNEL COMMAND LINE
systemd-fstab-generator understands the following kernel command line parameters:

fstab=, rd.fstab=

Takes a boolean argument. Defaults to "yes". If "no", causes the generator to ignore any mounts or swap devices configured in /etc/fstab. rd.fstab= is honored only in the initrd, while fstab= is honored by both the main system and the initrd. Added in version 186.

root=

Configures the operating system's root filesystem to mount when running in the initrd. This accepts a device node path (usually /dev/disk/by-uuid/... or /dev/disk/by-label/... or similar), or the special values "gpt-auto", "gpt-auto-force", "dissect", "dissect-force", "fstab", "tmpfs", "bind:...", and "off". Set to "gpt-auto", "gpt-auto-force", "dissect", "dissect-force" to explicitly request automatic root file system discovery, implemented in systemd-gpt-auto-generator(8).

Use "fstab" to explicitly request automatic root file system discovery via the initrd /etc/fstab rather than via kernel command line.

Use "tmpfs" in order to mount a tmpfs(5) file system as root file system of the OS. This is useful in combination with mount.usr= (see below) in order to combine a volatile root file system with a separate, immutable /usr/ file system. Also see systemd.volatile= below.

Use "bind:..." to bind mount another directory as operating system root filesystems (added in v258). Expects an absolute path name referencing an existing directory within the initrd's file hierarchy to boot into. Since the resulting root file system is supposed to behave like a regular OS root, the bind mount is established with the dev, suid and exec options (i.e. the nodev, nosuid and noexec flags that would otherwise be inherited from the file system the source directory resides on, such as /run/, are cleared), unless overridden via rootflags=.

Set to "off" to turn off mounting of a root file system.

Note that further root= values may be supported, implemented in additional packages.

Added in version 217.

rootfstype=

Takes the root filesystem type that will be passed to the mount command. rootfstype= is honored by the initrd. Added in version 217.

rootflags=

Takes the root filesystem mount options to use. rootflags= is honored by the initrd. Note that unlike most kernel command line options this setting does not override settings made in configuration files (specifically: the mount option string in /etc/fstab). See systemd-remount-fs.service(8).

Added in version 217.

mount.usr=

Takes the /usr/ filesystem to be mounted by the initrd. If mount.usrfstype= or mount.usrflags= is set, then the mount configured via mount.usr= will default to the the same value set in root=. Set to "dissect" to explicitly request automatic /usr/ file system discovery, implemented in systemd-gpt-auto-generator(8).

Set to "off" to turn off mounting of a separate /usr/ file system.

mount.usr= is honored by the initrd.

Added in version 217.

mount.usrfstype=

Takes the /usr/ filesystem type that will be passed to the mount command. If mount.usr= or mount.usrflags= is set, then mount.usrfstype= will default to the value set in rootfstype=. Otherwise, this value will be read from the /usr/ entry in /etc/fstab on the root filesystem.

mount.usrfstype= is honored by the initrd.

Added in version 217.

mount.usrflags=

Takes the /usr/ filesystem mount options to use. If mount.usr= or mount.usrfstype= is set, then mount.usrflags= will default to the value set in rootflags=. Otherwise, this value will be read from the /usr/ entry in /etc/fstab on the root filesystem.

mount.usrflags= is honored by the initrd.

Added in version 217.

roothash=, usrhash=

These options are primarily read by systemd-veritysetup-generator(8). When set this indicates that the root file system (or /usr/) shall be mounted from Verity volumes with the specified hashes. If these kernel command line options are set the root (or /usr/) file system is thus mounted from a device mapper volume /dev/mapper/root (or /dev/mapper/usr). Added in version 251.

systemd.volatile=

Controls whether the system shall boot up in volatile mode. Takes a boolean argument or the special value state. If false (the default), this generator makes no changes to the mount tree and the system is booted up in normal mode.

If true the generator ensures systemd-volatile-root.service(8) is run in the initrd. This service changes the mount table before transitioning to the host system, so that a volatile memory file system ("tmpfs") is used as root directory, with only /usr/ mounted into it from the configured root file system, in read-only mode. This way the system operates in fully stateless mode, with all configuration and state reset at boot and lost at shutdown, as /etc/ and /var/ will be served from the (initially unpopulated) volatile memory file system.

If set to state the generator will leave the root directory mount point unaltered, however will mount a "tmpfs" file system to /var/. In this mode the normal system configuration (i.e. the contents of "/etc/") is in effect (and may be modified during system runtime), however the system state (i.e. the contents of "/var/") is reset at boot and lost at shutdown.

If this setting is set to "overlay" the root file system is set up as "overlayfs" mount combining the read-only root directory with a writable "tmpfs", so that no modifications are made to disk, but the file system may be modified nonetheless with all changes being lost at reboot.

Note that in none of these modes the root directory, /etc/, /var/ or any other resources stored in the root file system are physically removed. It's thus safe to boot a system that is normally operated in non-volatile mode temporarily into volatile mode, without losing data.

Note that with the exception of "overlay" mode, enabling this setting will only work correctly on operating systems that can boot up with only /usr/ mounted, and are able to automatically populate /etc/, and also /var/ in case of "systemd.volatile=yes".

Also see root=tmpfs above, for a method to combine a "tmpfs" file system with a regular /usr/ file system (as configured via mount.usr=). The main distinction between systemd.volatile=yes, and root=tmpfs in combination mount.usr= is that the former operates on top of a regular root file system and temporarily obstructs the files and directories above its /usr/ subdirectory, while the latter does not hide any files, but simply mounts a unpopulated tmpfs as root file system and combines it with a user picked /usr/ file system.

Added in version 233.

systemd.swap=

Takes a boolean argument or enables the option if specified without an argument. If disabled, causes the generator to ignore any swap devices configured in /etc/fstab. Defaults to enabled. Added in version 246.

systemd.mount-extra=WHAT:WHERE[:FSTYPE[:OPTIONS]], rd.systemd.mount-extra=WHAT:WHERE[:FSTYPE[:OPTIONS]]

Specifies the mount unit. Takes at least two and at most four fields separated with a colon (":"). Each field is handled as the corresponding fstab field. This option can be specified multiple times. rd.systemd.mount-extra= is honored only in the initrd, while systemd.mount-extra= is honored by both the main system and the initrd. In the initrd, the mount point (and also source path if the mount is bind mount) specified in systemd.mount-extra= is prefixed with /sysroot/. Example:

```
systemd.mount-extra=/dev/sda1:/mount-point:ext4:rw,noatime
```

Added in version 254.

systemd.swap-extra=WHAT[:OPTIONS], rd.systemd.swap-extra=WHAT[:OPTIONS]

Specifies the swap unit. Takes the block device to be used as a swap device, and optionally takes mount options followed by a colon (":"). This option can be specified multiple times. rd.systemd.swap-extra= is honored only in the initrd, while systemd.swap-extra= is honored by both the main system and the initrd. Example:

```
systemd.swap-extra=/dev/sda2:x-systemd.makefs
```

Added in version 254.

## SYSTEM CREDENTIALS
fstab.extra

This credential may contain addition mounts to establish, in the same format as fstab(5), with one mount per line. It is read in addition to /etc/fstab. Added in version 254.

## SEE ALSO
systemd(1), fstab(5), systemd.mount(5), systemd.swap(5), systemd-cryptsetup-generator(8), systemd-gpt-auto-generator(8), kernel-command-line(7), Known Environment Variables[1]

## NOTES
1.

Known Environment Variables

https://systemd.io/ENVIRONMENT/


systemd-getty-generator

title: systemd-getty-generator(8)

text:
# systemd-getty-generator(8)

## NAME
systemd-getty-generator - Generator for enabling getty instances on the console

## SYNOPSIS
/usr/lib/systemd/system-generators/systemd-getty-generator

## DESCRIPTION
systemd-getty-generator is a generator that automatically instantiates serial-getty@.service on the kernel consoles, if they can function as ttys and are not provided by the virtual console subsystem. It will also instantiate serial-getty@.service instances for virtualizer consoles, if execution in a virtualized environment is detected. If execution in a container environment is detected, it will instead enable console-getty.service for /dev/console, and container-getty@.service instances for additional container pseudo TTYs as requested by the container manager (see Container Interface[1]). This should ensure that the user is shown a login prompt at the right place, regardless of which environment the system is started in. For example, it is sufficient to redirect the kernel console with a kernel command line argument such as console= to get both kernel messages and a getty prompt on a serial TTY. See The kernel's command-line parameters[2] for more information on the console= kernel parameter.

systemd-getty-generator implements systemd.generator(7).

Further information about configuration of gettys can be found in systemd for Administrators, Part XVI: Gettys on Serial Consoles (and Elsewhere)[3].

## KERNEL COMMAND LINE
systemd-getty-generator understands the following kernel-command-line(7) parameters:

systemd.getty_auto=

This kernel command line option may be used to control the execution mode of the generator. Takes an optional boolean argument. Since v258, this also takes comma-separated list of special values: "credential", "container", "console", and "builtin". When "credential" is specified, the two credentials getty.ttys.serial and getty.ttys.container will be parsed. See System Credentials section below for more details.

When "container" is specified, console-getty.service and container-getty@.service will be enabled when the system is running in a container. This option will be ignored when the system is not in a container.

When "console" is specified, serial-getty@.service for active kernel consoles will be enabled. This option will be ignored when the system is running in a container.

When "builtins" is specified, serial-getty@.service for available virtualizer consoles will be enabled. This option will be ignored when the system is running in a container.

When yes, the above four options will be enabled. When no, all options are disabled and no service will be enabled. When the kernel command line option is specified without an argument, defaults to yes. The generator is enabled by default, and a false value may be used to disable it.

Added in version 250.

## ENVIRONMENT
$SYSTEMD_GETTY_AUTO

This environment variable may be used to control the execution mode of the generator. Takes the same value as systemd.getty_auto= kernel command line option. Added in version 250.

## SYSTEM CREDENTIALS
getty.auto

The system credential may be used to control the execution mode of the generator. Takes the same value as systemd.getty_auto= kernel command line option. Added in version 258.

getty.ttys.serial, getty.ttys.container

These system credentials may be used to spawn additional login prompts on selected TTYs. The two credentials should contain a newline-separated list of TTY names to spawn instances of serial-getty@.service (in case of getty.ttys.serial) and container-getty@.service (in case of getty.ttys.container) on. Any lines starting with a "#" will be ignored. Added in version 254.

## SEE ALSO
systemd(1), kernel-command-line(7), systemd.system-credentials(7), agetty(8)

## NOTES
1.

Container

Interface

https://systemd.io/CONTAINER_INTERFACE

2.

The kernel's command-line parameters

https://docs.kernel.org/admin-guide/kernel-parameters.html

3.

systemd for Administrators, Part XVI: Gettys on Serial Consoles (and Elsewhere)

https://0pointer.de/blog/projects/serial-console.html


systemd-gpt-auto-generator

title: systemd-gpt-auto-generator(8)

text:
# systemd-gpt-auto-generator(8)

## NAME
systemd-gpt-auto-generator - Generator for automatically discovering and mounting root, /home/, /srv/, /var/ and /var/tmp/ partitions, as well as discovering and enabling swap partitions, based on GPT partition type GUIDs

## SYNOPSIS
/usr/lib/systemd/system-generators/systemd-gpt-auto-generator

## DESCRIPTION
systemd-gpt-auto-generator is a unit generator that automatically discovers the root partition, /home/, /srv/, /var/, /var/tmp/, the EFI System Partition (ESP), the Extended Boot Loader Partition (XBOOTLDR), and swap partitions and creates mount and swap units for them, based on the partition type GUIDs of GUID partition tables (GPT). See UEFI Specification[1], chapter 5 for more details. It implements the Discoverable Partitions Specification[2].

Note that this generator has no effect on non-GPT systems. It will also not create mount point configuration for directories which already contain files or if the mount point is explicitly configured in fstab(5). Additionally no unit will be created for the ESP or the XBOOTLDR partition if mount entries are found in the /boot/ or /efi/ hierarchies in fstab(5).

If the units this generator creates are overridden, for example by units in directories with higher precedence, drop-ins and additional dependencies created by this generator might still be used.

When run in the initial RAM disk (initrd) this generator can automatically search for the root file system. Specifically:

•It will look for the root partition on the same physical disk where the EFI System Partition (ESP) is located. Note that support from the boot loader is required for this to work: the EFI variable LoaderDevicePartUUID of the 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f vendor UUID is used to determine from which partition (and hence disk) the system was booted. If the boot loader does not set this variable, this generator will not be able to detect the root partition. See the Boot Loader Interface[3] for details.

•Alternatively, it will look for the root file system on a loopback block device whose ".lo_name" field is set to one of the literal strings "rootdisk" or "rootdisk.raw". This field can be set via losetup's --loop-ref= string. For images downloaded via systemd-import-generator(8) make sure to set the "blockdev" option and set the local name string to "rootdisk" to achieve this effect. Note that discovery of the root file system on loopback block devices like this is only done if "root=gpt-auto" or "root=dissect" is specified explicitly on the kernel command line, unlike the discovery based on the boot loader reported ESP which is also enabled if no "root=" parameter is specified at all. (The latter relies on systemd-udevd.service's /dev/gpt-auto-root block device symlink generation).

When run on the host system (i.e. after successfully transitioning out of the initrd into the root filesystem) this generator will look for all other partitions on the same physical disk as the root partition. For this discovery, boot loader support is not required. Moreover, it is not required that the root partition was automatically discovered by the initrd (as described above) for the discovery of the non-root file partitions to take place. Or in other words: automatic discovery of the root file system and of the non-root file systems are independent operations, that do not rely on each other, and are done during two distinct phases of the boot process (one in the initrd, the other after). These partitions will not be searched for on systems where the root file system is distributed on multiple disks, for example via btrfs RAID.

The root partition can be configured explicitly by symlinking /run/systemd/volatile-root to /dev/block/$major:$minor. This is especially useful if the root mount has been replaced by some form of volatile file system (overlayfs).

systemd-gpt-auto-generator is useful for centralizing file system configuration in the partition table and making configuration in /etc/fstab or on the kernel command line unnecessary.

This generator looks for the partitions based on their partition type GUID. The following partition type GUIDs are identified:

Table 1. Partition Type GUIDs

Partition Type

GUID

Name

Mount Point

Explanation

SD_GPT_ROOT_X86_64

4f68bce3-e8cd-4db1-96e7-fbcaf984b709

Root Partition (x86-64)

/

The first partition with this type UUID, located on the same disk as the ESP used for booting, is used as the root file system / on AMD64 / 64-bit x86 systems.

SD_GPT_ROOT_ARM64

b921b045-1df0-41c3-af44-4c6f280d3fae

Root Partition (64-bit ARM)

/

The first partition with this type UUID, located on the same disk as the ESP used for booting, is used as the root file system / on AArch64 / 64-bit ARM systems.

SD_GPT_ROOT_ALPHA SD_GPT_ROOT_ARC SD_GPT_ROOT_ARM SD_GPT_ROOT_ARM64 SD_GPT_ROOT_IA64 SD_GPT_ROOT_LOONGARCH64 SD_GPT_ROOT_MIPS SD_GPT_ROOT_MIPS64 SD_GPT_ROOT_MIPS_LE SD_GPT_ROOT_MIPS64_LE SD_GPT_ROOT_PARISC SD_GPT_ROOT_PPC SD_GPT_ROOT_PPC64 SD_GPT_ROOT_PPC64_LE SD_GPT_ROOT_RISCV32 SD_GPT_ROOT_RISCV64 SD_GPT_ROOT_S390 SD_GPT_ROOT_S390X SD_GPT_ROOT_TILEGX SD_GPT_ROOT_X86 SD_GPT_ROOT_X86_64 SD_GPT_USR_ALPHA SD_GPT_USR_ARC SD_GPT_USR_ARM SD_GPT_USR_IA64 SD_GPT_USR_LOONGARCH64 SD_GPT_USR_MIPS_LE SD_GPT_USR_MIPS64_LE SD_GPT_USR_PARISC SD_GPT_USR_PPC SD_GPT_USR_PPC64 SD_GPT_USR_PPC64_LE SD_GPT_USR_RISCV32 SD_GPT_USR_RISCV64 SD_GPT_USR_S390 SD_GPT_USR_S390X SD_GPT_USR_TILEGX SD_GPT_USR_X86

...

Root partitions for other architectures

/

The first partition with the type UUID matching the architecture, located on the same disk as the ESP used for booting, is used as the root file system /. For the full list and constant values, see Discoverable Partitions Specification[2].

SD_GPT_HOME

933ac7e1-2eb4-4f13-b844-0e14e2aef915

Home Partition

/home/

The first partition with this type UUID on the same disk as the root partition is mounted to /home/.

SD_GPT_SRV

3b8f8425-20e0-4f3b-907f-1a25a76f98e8

Server Data Partition

/srv/

The first partition with this type UUID on the same disk as the root partition is mounted to /srv/.

SD_GPT_VAR

4d21b016-b534-45c2-a9fb-5c16e091fd2d

Variable Data Partition

/var/

The first partition with this type UUID on the same disk as the root partition is mounted to /var/ — under the condition its partition UUID matches the first 128 bit of the HMAC-SHA256 of the GPT type uuid of this partition keyed by the machine ID of the installation stored in machine-id(5). This can be generated using systemd-id128(1).

SD_GPT_TMP

7ec6f557-3bc5-4aca-b293-16ef5df639d1

Temporary Data Partition

/var/tmp/

The first partition with this type UUID on the same disk as the root partition is mounted to /var/tmp/.

SD_GPT_SWAP

0657fd6d-a4ab-43c4-84e5-0933c84b4f4f

Swap

n/a

All partitions with this type UUID on the same disk as the root partition are used as swap.

SD_GPT_ESP

c12a7328-f81f-11d2-ba4b-00a0c93ec93b

EFI System Partition (ESP)

/efi/ or /boot/

The first partition with this type UUID located on the same disk as the root partition is mounted to /boot/ or /efi/, see below.

SD_GPT_XBOOTLDR

bc13c2ff-59e6-4262-a352-b275fd6f7172

Extended Boot Loader Partition

/boot/

The first partition with this type UUID located on the same disk as the root partition is mounted to /boot/, see below.

This generator understands the following attribute flags for partitions:

Table 2. Partition Attribute Flags

Flag

Value

Applicable to

Explanation

SD_GPT_FLAG_READ_ONLY

0x1000000000000000

/, /home/, /srv/, /var/, /var/tmp/, Extended Boot Loader Partition

Partition is mounted read-only

SD_GPT_FLAG_NO_AUTO

0x8000000000000000

/, /home/, /srv/, /var/, /var/tmp/, Extended Boot Loader Partition

Partition is not mounted automatically

SD_GPT_FLAG_NO_BLOCK_IO_PROTOCOL

0x0000000000000002

EFI System Partition (ESP)

Partition is not mounted automatically

The

/home/, /srv/, /var/, /var/tmp/ and swap partitions may be encrypted in LUKS format. In this case, a device mapper device is set up under the names /dev/mapper/home, /dev/mapper/srv, /dev/mapper/var, /dev/mapper/tmp or /dev/mapper/swap. Note that this might create conflicts if the same partition is listed in /etc/crypttab with a different device mapper device name.

When systemd is running in the initrd the / partition may be encrypted with LUKS as well. In this case, a device mapper device is set up under the name /dev/mapper/root, and a sysroot.mount is set up that mounts the device under /sysroot. For more information, see bootup(7).

Mount and automount units for the EFI System Partition (ESP) and Extended Boot Loader Partition (XBOOTLDR) are generated on EFI systems. If the disk contains an XBOOTLDR partition, as defined in the Boot Loader Specification[4], it is made available at /boot/. This generator creates an automount unit; the mount will only be activated on-demand when accessed. The mount point will be created if necessary.

The ESP is mounted to /boot/ if that directory exists and is not used for XBOOTLDR, and otherwise to /efi/. Same as for /boot/, an automount unit is used. The mount point will be created if necessary.

No configuration is created for mount points that are configured in fstab(5) or when the target directory contains files.

When using this generator in conjunction with btrfs file systems, make sure to set the correct default subvolumes on them, using btrfs subvolume set-default.

If the system was booted via systemd-stub(7) and the stub reported to userspace that the kernel image was measured to a TPM2 PCR, then any discovered root and /var/ volume identifiers (and volume encryption key in case it is encrypted) will be automatically measured into PCR 15 on activation, via systemd-pcrfs@.service(8).

Mount constraint metadata contained in the file systems is validated by pulling in systemd-validatefs@.service(8) for generated mounts.

systemd-gpt-auto-generator implements systemd.generator(7).

## KERNEL COMMAND LINE
systemd-gpt-auto-generator understands the following kernel command line parameters:

systemd.gpt_auto, rd.systemd.gpt_auto

Those options take an optional boolean argument, and default to yes. The generator is enabled by default, and a false value may be used to disable it (e.g. "systemd.gpt_auto=0"). Added in version 242.

systemd.image_policy=

Takes an image dissection policy string as argument (as per systemd.image-policy(7)), and allows enforcing a policy on dissection and use of the automatically discovered GPT partition table entries. Note that the specified image policy is not taken into account for automatic root or /usr/ file system discovery unless root=dissect/mount.usr=dissect (or root=dissect-force) are specified. (The policy will always be applied to the other auto-discoverable partition types.)

Added in version 254.

systemd.image_filter=

Takes an image dissection filter string as argument (as per systemd.image-filter(7)), and allows enforcing a set of globbing patterns on the partition matching of the automatically discovered GPT partition table entries. Note that the specified image filter is not taken into account for automatic root or /usr/ file system discovery unless root=dissect/mount.usr=dissect (or root=dissect-force) are specified. (The filter will always be applied to the other auto-discoverable partition types.)

Added in version 258.

root=, rootfstype=, rootflags=

When root= is used with the special value "gpt-auto", basic automatic discovery of the root partition based on the GPT partition type is enabled. Use of the root partition is delayed until factory reset mode is left, in case it is enabled during the current boot. See Factory Reset[5] for more information on that. If "gpt-auto-force" is specified automatic discovery of the root partition is enabled, ignoring any factory reset mode. If root= is set to the special value "dissect" full automatic discovery of the root partition based on GPT partition information is enabled. This is a superset of root=gpt-auto, as it automatically configures Verity partitions (including signature-based setup) following the logic defined for that in the Discoverable Partitions Specification[6]. Moreover it takes the configured image policy and image filter into account for all partition types, including the root file system. "root=dissect" will wait for the factory reset phase to be completed if it is in effect before activating the root file system. Use "root=dissect-force" to ignore the factory reset phase and activate the root file system immediately.

Any other value (i.e. besides "gpt-auto", "gpt-auto-force", "dissect", "dissect-force") disables automatic root file system discovery.

If root= is not specified at all on the kernel command line automatic discovery of the root partition via the ESP reported by the boot loader is also enabled (taking factory reset state into account, i.e. equivalent to "root=gpt-auto"), however in this case discovery based on the loopback block device ".lo_name" field is not enabled.

The rootfstype= and rootflags= options are used to select the file system type and options when the root file system is automatically discovered.

Added in version 242.

mount.usr=, mount.usrfstype=, mount.usrflags=

Similar to root=, rootfstype=, rootflags= (see above), but applies to the /usr/ partition instead. Note that the "gpt-auto", "gpt-auto-force", "dissect-force" settings that root= understands are not supported by mount.usr= (however "dissect" is). Also note that automatic partition discovery for /usr/ must be enabled explicitly, unlike the discovery for the root file system, which is enabled if no root= parameter is passed at all.

Added in version 258.

rw, ro

Mount the root partition read-write or read-only initially. Note that unlike most kernel command line options these settings do not override configuration in the file system, and the file system may be remounted later. See systemd-remount-fs.service(8).

Added in version 242.

systemd.swap=

Takes a boolean argument or enables the option if specified without an argument. If disabled, automatic discovery of swap partition(s) based on GPT partition type is disabled. Defaults to enabled. Added in version 254.

## SEE ALSO
systemd(1), systemd.mount(5), systemd.swap(5), systemd-fstab-generator(8), systemd-cryptsetup@.service(8), systemd-pcrfs@.service(8), systemd-validatefs@.service(8), machine-id(5), cryptsetup(8), fstab(5), btrfs(8)

## NOTES
1.

UEFI Specification

https://uefi.org/specifications

2.

Discoverable Partitions Specification

https://uapi-group.org/specifications/specs/discoverable_partitions_specification

3.

Boot Loader Interface

https://systemd.io/BOOT_LOADER_INTERFACE

4.

Boot Loader Specification

https://uapi-group.org/specifications/specs/boot_loader_specification

5.

Factory Reset

https://systemd.io/FACTORY_RESET

6.

Discoverable Partitions Specification

https://uapi-group.org/specifications/specs/discoverable_partitions_specification/


systemd-hibernate-resume-generator

title: systemd-hibernate-resume-generator(8)

text:
# systemd-hibernate-resume-generator(8)

## NAME
systemd-hibernate-resume-generator - Unit generator for resume= kernel parameter

## SYNOPSIS
/usr/lib/systemd/system-generators/systemd-hibernate-resume-generator

## DESCRIPTION
systemd-hibernate-resume-generator is a generator that initiates the procedure to resume the system from hibernation. When resume= kernel command line option or HibernateLocation EFI variable is detected, it enables the systemd-hibernate-resume.service(8) unit, which will instruct the kernel to resume the system from the hibernation image.

## KERNEL COMMAND LINE
systemd-hibernate-resume-generator understands the following kernel command line parameters:

resume=

Takes a path to the resume device. Both persistent block device paths like /dev/disk/by-foo/bar and fstab(5)-style specifiers like "FOO=bar" are supported. Added in version 217.

resume_offset=

Takes the page offset of the swap space from the resume device. Defaults to "0". Added in version 254.

resumeflags=

Takes the resume device mount options to use. Defaults rootflags= if not specified. Added in version 243.

noresume

Do not try to resume from hibernation. If this parameter is present, resume= is ignored. Added in version 240.

## SEE ALSO
systemd(1), systemd-hibernate-resume.service(8), kernel-command-line(7)


systemd-hibernate-resume.service

title: systemd-hibernate-resume.service(8)

summary: Resume from hibernation

text:
# systemd-hibernate-resume.service(8)

## NAME
systemd-hibernate-resume.service, systemd-hibernate-clear.service, systemd-hibernate-resume - Resume from hibernation

## SYNOPSIS
systemd-hibernate-resume.service

systemd-hibernate-clear.service

/usr/lib/systemd/systemd-hibernate-resume

## DESCRIPTION
systemd-hibernate-resume.service initiates the resume from hibernation.

systemd-hibernate-resume only supports the in-kernel hibernation implementation, see Swap suspend[1]. Internally, it works by writing the major:minor of selected device node to /sys/power/resume, along with the offset in memory pages (/sys/power/resume_offset) if supported.

The resume device node is either passed directly through arguments, or automatically acquired from kernel command line options and/or HibernateLocation EFI variable. The latter will normally be cleared by systemd-hibernate-resume.service on resumption. If a stale variable is detected, it would be cleared by systemd-hibernate-clear.service.

Failing to initiate a resume is not an error condition. It may mean that there was no resume image (e. g. if the system has been simply powered off and not hibernated). In such cases, the boot is ordinarily continued.

## SEE ALSO
systemd(1), systemd-hibernate-resume-generator(8)

## NOTES
1.

Swap suspend

https://docs.kernel.org/power/swsusp.html


systemd-hostnamed.service

title: systemd-hostnamed.service(8)

text:
# systemd-hostnamed.service(8)

## NAME
systemd-hostnamed.service, systemd-hostnamed - Daemon to control system hostname from programs

## SYNOPSIS
systemd-hostnamed.service

/usr/lib/systemd/systemd-hostnamed

## DESCRIPTION
systemd-hostnamed.service is a system service that may be used to change the system's hostname and related machine metadata from user programs. It is automatically activated on request and terminates itself when unused.

It currently offers access to five variables:

•The current hostname (Example: "dhcp-192-168-47-11")

•The static (configured) hostname (Example: "lennarts-computer")

•The pretty hostname (Example: "Lennart's Computer")

•A suitable icon name for the local host (Example: "computer-laptop")

•A chassis type (Example: "tablet")

The static hostname is stored in /etc/hostname, see hostname(5) for more information. The pretty hostname, chassis type, and icon name are stored in /etc/machine-info, see machine-info(5).

The tool hostnamectl(1) is a command line client to this service.

See org.freedesktop.hostname1(5) and org.freedesktop.LogControl1(5) for a description of the D-Bus API.

## SEE ALSO
systemd(1), hostname(5), machine-info(5), hostnamectl(1), sethostname(2), org.freedesktop.hostname1(5)


systemd-integritysetup-generator

title: systemd-integritysetup-generator(8)

text:
# systemd-integritysetup-generator(8)

## NAME
systemd-integritysetup-generator - Unit generator for integrity protected block devices

## SYNOPSIS
/usr/lib/systemd/system-generators/systemd-integritysetup-generator

## DESCRIPTION
systemd-integritysetup-generator is a generator that translates /etc/integritytab entries into native systemd units early at boot. This will create systemd-integritysetup@.service(8) units as necessary.

systemd-integritysetup-generator implements systemd.generator(7).

## SEE ALSO
systemd(1), systemd-integritysetup@.service(8), integritysetup(8)


systemd-integritysetup@.service

title: systemd-integritysetup@.service(8)

summary: Disk integrity protection logic

text:
# systemd-integritysetup@.service(8)

## NAME
systemd-integritysetup@.service, systemd-integritysetup - Disk integrity protection logic

## SYNOPSIS
systemd-integritysetup@.service

/usr/lib/systemd/systemd-integritysetup

## DESCRIPTION
systemd-integritysetup@.service is a service responsible for setting up integrity protected block devices. It should be instantiated for each device that requires integrity protection.

At early boot and when the system manager configuration is reloaded, entries from integritytab(5) are converted into systemd-integritysetup@.service units by systemd-integritysetup-generator(8).

systemd-integritysetup@.service calls systemd-integritysetup.

## COMMANDS
The following commands are understood by systemd-integritysetup:

attach volume device [key-file|-] [option(s)|-]

Create a block device volume using device. See integritytab(5) and Kernel dm-integrity[1] documentation for details. Added in version 250.

detach volume

Detach (destroy) the block device volume. Added in version 250.

help

Print short information about command syntax. Added in version 250.

## SEE ALSO
systemd(1), integritytab(5), systemd-integritysetup-generator(8), integritysetup(8)

## NOTES
1.

Kernel dm-integrity

https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html


systemd-journald.service

title: systemd-journald.service(8)

summary: Journal service

text:
# systemd-journald.service(8)

## NAME
systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket, systemd-journald-audit.socket, systemd-journald@.service, systemd-journald@.socket, systemd-journald-varlink@.socket, systemd-journald - Journal service

## SYNOPSIS
systemd-journald.service

systemd-journald.socket

systemd-journald-dev-log.socket

systemd-journald-audit.socket

systemd-journald@.service

systemd-journald@.socket

systemd-journald-varlink@.socket

/usr/lib/systemd/systemd-journald

## DESCRIPTION
systemd-journald is a system service that collects and stores logging data. It creates and maintains structured, indexed journals based on logging information that is received from a variety of sources:

•Kernel log messages, via kmsg

•Simple system log messages, via the libc syslog(3) call

•Structured system log messages via the native Journal API, see sd_journal_print(3) and Native Journal Protocol[1]

•Standard output and standard error of service units. For further details see below.

•Audit records, originating from the kernel audit subsystem

The daemon will implicitly collect numerous metadata fields for each log messages in a secure and unfakeable way. See systemd.journal-fields(7) for more information about the collected metadata.

Log data collected by the journal is primarily text-based but can also include binary data where necessary. Individual fields making up a log record stored in the journal may be up to 2⁶⁴-1 bytes in size.

The journal service stores log data either persistently below /var/log/journal or in a volatile way below /run/log/journal/ (in the latter case, it is lost at reboot). By default, log data is stored persistently if /var/log/journal/ exists during boot, with an implicit fallback to volatile storage otherwise. Use Storage= in journald.conf(5) to configure where log data is placed, independently of the existence of /var/log/journal/.

Note that journald will initially use volatile storage, until a call to journalctl --flush (or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the conditions mentioned above). This is done automatically on boot via "systemd-journal-flush.service".

On systems where /var/log/journal/ does not exist yet but where persistent logging is desired (and the default journald.conf is used), it is sufficient to create the directory, and ensure it has the correct access modes and ownership:

```
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
```

See journald.conf(5) for information about the configuration of this service.

## STREAM LOGGING
The systemd service manager invokes all service processes with standard output and standard error connected to the journal by default. This behaviour may be altered via the StandardOutput=/StandardError= unit file settings, see systemd.exec(5) for details. The journal converts the log byte stream received this way into individual log records, splitting the stream at newline ("\n", ASCII 10) and NUL bytes.

If systemd-journald.service is stopped, the stream connections associated with all services are terminated. Further writes to those streams by the service will result in EPIPE errors. In order to react gracefully in this case, it is recommended that programs logging to standard output/error ignore such errors. If the SIGPIPE UNIX signal handler is not blocked or turned off, such write attempts will also result in such process signals being generated, see signal(7). To mitigate this issue, systemd service manager explicitly turns off the SIGPIPE signal for all invoked processes by default (this may be changed for each unit individually via the IgnoreSIGPIPE= option, see systemd.exec(5) for details). After the standard output/standard error streams have been terminated they may not be recovered until the services they are associated with are restarted. Note that during normal operation, systemd-journald.service stores copies of the file descriptors for those streams in the service manager. If systemd-journald.service is restarted using systemctl restart or equivalent operation instead of a pair of separate systemctl stop and systemctl start commands (or equivalent operations), these stream connections are not terminated and survive the restart. It is thus safe to restart systemd-journald.service, but stopping it is not recommended.

Note that the log record metadata for records transferred via such standard output/error streams reflect the metadata of the peer the stream was originally created for. If the stream connection is passed on to other processes (such as further child processes forked off the main service process), the log records will not reflect their metadata, but will continue to describe the original process. This is different from the other logging transports listed above, which are inherently record based and where the metadata is always associated with the individual record.

In addition to the implicit standard output/error logging of services, stream logging is also available via the systemd-cat(1) command line tool.

Currently, the number of parallel log streams systemd-journald will accept is limited to 4096. When this limit is reached further log streams may be established but will receive EPIPE right from the beginning.

## JOURNAL NAMESPACES
Journal 'namespaces' are both a mechanism for logically isolating the log stream of projects consisting of one or more services from the rest of the system and a mechanism for improving performance. Multiple journal namespaces may exist simultaneously, each defining its own, independent log stream managed by its own instance of systemd-journald. Namespaces are independent of each other, both in the data store and in the IPC interface. By default, only a single "default namespace exists, managed by systemd-journald.service (and its associated socket units). Additional namespaces are created by starting an instance of the systemd-journald@.service service template. The instance name is the namespace identifier, which is a short string used for referencing the journal namespace. Service units may be assigned to a specific journal namespace through the LogNamespace= unit file setting, see systemd.exec(5) for details. The --namespace= switch of journalctl(1) may be used to view the log stream of a specific namespace. If the switch is not used the log stream of the default namespace is shown, i.e. log data from other namespaces is not visible.

Services associated with a specific log namespace may log via syslog(3), the native logging protocol of the journal and via stdout/stderr; the logging from all three transports is associated with the namespace.

By default, only the default namespace will collect kernel and audit log messages.

The systemd-journald instance of the default namespace is configured through /etc/systemd/journald.conf (see below), while the other instances are configured through /etc/systemd/journald@NAMESPACE.conf. The journal log data for the default namespace is placed in /var/log/journal/MACHINE_ID (see below) while the data for the other namespaces is located in /var/log/journal/MACHINE_ID.NAMESPACE.

## SIGNALS
SIGUSR1

Request that journal data from /run/ is flushed to /var/ in order to make it persistent (if this is enabled). This must be used after /var/ is mounted, as otherwise log data from /run/ is never flushed to /var/ regardless of the configuration. Use the journalctl --flush command to request flushing of the journal files, and wait for the operation to complete. See journalctl(1) for details. Added in version 186.

SIGUSR2

Request immediate rotation of the journal files. Use the journalctl --rotate command to request journal file rotation, and wait for the operation to complete. Added in version 186.

SIGRTMIN+1

Request that all unwritten log data is written to disk. Use the journalctl --sync command to trigger journal synchronization, and wait for the operation to complete. Added in version 228.

SIGHUP

Upon reception of the SIGHUP process signal systemd-journald will reload its configuration values and update the kernel log buffer and journals to reflect the new configuration. If ReadKmsg= has changed, the kernel log buffer will be flushed and updated as part of the reload. The active journal (e.g., persistent, volatile) will continue to be used with the updated configuration. However, if the storage mode has changed from persistent to volatile and the current journal in use is the persistent journal, then the active journal will be switched to the volatile journal. Added in version 258.

## CREDENTIALS
systemd-journald supports the service credentials logic as implemented by ImportCredential=/LoadCredential=/SetCredential= (see systemd.exec(5) for details). The following credentials are used when passed in:

journal.forward_to_socket

May contain a socket address to which logs should be forwarded. See ForwardToSocket= in journald.conf(5). Added in version 256.

journal.storage

May be used to specify where journal files should be stored. See Storage= in journald.conf(5). Added in version 256.

## KERNEL COMMAND LINE
A few configuration parameters from journald.conf may be overridden on the kernel command line:

systemd.journald.forward_to_syslog=, systemd.journald.forward_to_kmsg=, systemd.journald.forward_to_console=, systemd.journald.forward_to_wall=

Enables/disables forwarding of collected log messages to syslog, the kernel log buffer, the system console or wall. See journald.conf(5) for information about these settings.

Added in version 186.

systemd.journald.max_level_store=, systemd.journald.max_level_syslog=, systemd.journald.max_level_kmsg=, systemd.journald.max_level_console=, systemd.journald.max_level_wall=, systemd.journald.max_level_socket=

Controls the maximum log level of messages that are stored in the journal, forwarded to syslog(3), kmsg, the console, wall(1), or a socket. This kernel command line options override the settings of the same names in the journald.conf(5) file. Added in version 232.

Note that these kernel command line options are only honoured by the default namespace, see above.

## ACCESS CONTROL
Journal files are, by default, owned and readable by the "systemd-journal" system group but are not writable. Adding a user to this group thus enables them to read the journal files.

By default, each user, with a UID outside the range of system users, dynamic service users, and the nobody user, will get their own set of journal files in /var/log/journal/. See Users, Groups, UIDs and GIDs on systemd systems[2] for more details about UID ranges. These journal files will not be owned by the user, however, in order to avoid that the user can write to them directly. Instead, file system ACLs are used to ensure the user gets read access only.

Additional users and groups may be granted access to journal files via file system access control lists (ACL). Distributions and administrators may choose to grant read access to all members of the "wheel" and "adm" system groups with a command such as the following:

```
# setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/
```

Note that this command will update the ACLs both for existing journal files and for future journal files created in the /var/log/journal/ directory.

## FILES
/etc/systemd/journald.conf

Configure systemd-journald behavior. See journald.conf(5). Added in version 206.

/run/log/journal/machine-id/*.journal, /run/log/journal/machine-id/*.journal~, /var/log/journal/machine-id/*.journal, /var/log/journal/machine-id/*.journal~

systemd-journald writes entries to files in /run/log/journal/machine-id/ or /var/log/journal/machine-id/ with the ".journal" suffix. If the daemon is stopped uncleanly, or if the files are found to be corrupted, they are renamed using the ".journal~" suffix, and systemd-journald starts writing to a new file. /run/ is used when /var/log/journal is not available, or when Storage=volatile is set in the journald.conf(5) configuration file. When systemd-journald ceases writing to a journal file, it will be renamed to "original-name@suffix.journal" (or "original-name@suffix.journal~"). Such files are "archived" and will not be written to any more.

In general, it is safe to read or copy any journal file (active or archived). journalctl(1) and the functions in the sd-journal(3) library should be able to read all entries that have been fully written.

systemd-journald will automatically remove the oldest archived journal files to limit disk use. See SystemMaxUse= and related settings in journald.conf(5).

Added in version 206.

/dev/kmsg, /dev/log, /run/systemd/journal/dev-log, /run/systemd/journal/socket, /run/systemd/journal/stdout

Sockets and other file node paths that systemd-journald will listen on and are visible in the file system. In addition to these, systemd-journald can listen for audit events using netlink(7), depending on whether "systemd-journald-audit.socket" is enabled or not. Added in version 228.

If journal namespacing is used these paths are slightly altered to include a namespace identifier, see above.

## SEE ALSO
systemd(1), journalctl(1), journald.conf(5), systemd.journal-fields(7), sd-journal(3), systemd-coredump(8), setfacl(1), sd_journal_print(3), pydoc systemd.journal

## NOTES
1.

Native Journal Protocol

https://systemd.io/JOURNAL_NATIVE_PROTOCOL

2.

Users, Groups, UIDs and GIDs on systemd systems

https://systemd.io/UIDS-GIDS


systemd-localed.service

title: systemd-localed.service(8)

summary: Locale bus mechanism

text:
# systemd-localed.service(8)

## NAME
systemd-localed.service, systemd-localed - Locale bus mechanism

## SYNOPSIS
systemd-localed.service

/usr/lib/systemd/systemd-localed

## DESCRIPTION
systemd-localed.service is a system service that may be used as mechanism to change the system locale settings, as well as the console key mapping and default X11 key mapping. systemd-localed is automatically activated on request and terminates itself when it is unused.

The tool localectl(1) is a command line client to this service.

See org.freedesktop.locale1(5) and org.freedesktop.LogControl1(5) for a description of the D-Bus API.

## SEE ALSO
systemd(1), locale.conf(5), vconsole.conf(5), localectl(1), loadkeys(1), org.freedesktop.locale1(5)


systemd-logind.service

title: systemd-logind.service(8)

summary: Login manager

text:
# systemd-logind.service(8)

## NAME
systemd-logind.service, systemd-logind - Login manager

## SYNOPSIS
systemd-logind.service

/usr/lib/systemd/systemd-logind

## DESCRIPTION
systemd-logind is a system service that manages user logins. It is responsible for:

•Keeping track of users and sessions, their processes and their idle state. This is implemented by allocating a systemd slice unit for each user below user.slice, and a scope unit below it for each concurrent session of a user. Also, a per-user service manager is started as system service instance of user@.service for each logged in user.

•Generating and managing session IDs. If auditing is available and an audit session ID is already set for a session, then this ID is reused as the session ID. Otherwise, an independent session counter is used.

•Providing polkit[1]-based access for users for operations such as system shutdown or sleep

•Implementing a shutdown/sleep inhibition logic for applications

•Handling of power/sleep hardware keys

•Multi-seat management

•Session switch management

•Device access management for users

•Automatic spawning of text logins (gettys) on virtual console activation and user runtime directory management

•Scheduled shutdown

•Sending "wall" messages

User sessions are registered with logind via the pam_systemd(8) PAM module.

See logind.conf(5) for information about the configuration of this service.

See sd-login(3) for information about the basic concepts of logind such as users, sessions and seats.

See org.freedesktop.login1(5) and org.freedesktop.LogControl1(5) for information about the D-Bus APIs systemd-logind provides.

For more information see Inhibitor Locks[2].

If you are interested in writing a display manager that makes use of logind, please have look at Writing Display Managers[3]. If you are interested in writing a desktop environment that makes use of logind, please have look at Writing Desktop Environments[4].

## SIGNAL
SIGHUP

Reloads the service configuration file.

## SEE ALSO
systemd(1), systemd-user-sessions.service(8), loginctl(1), logind.conf(5), pam_systemd(8), sd-login(3), org.freedesktop.login1(5)

## NOTES
1.

polkit

https://www.freedesktop.org/wiki/Software/polkit

2.

Inhibitor Locks

https://systemd.io/INHIBITOR_LOCKS

3.

Writing Display Managers

https://systemd.io/WRITING_DISPLAY_MANAGERS

4.

Writing Desktop Environments

https://systemd.io/WRITING_DESKTOP_ENVIRONMENTS


systemd-loop@.service

title: systemd-loop@.service(8)

summary: Attach a loopback block device

text:
# systemd-loop@.service(8)

## NAME
systemd-loop@.service - Attach a loopback block device

## SYNOPSIS
systemd-loop@path.service

## DESCRIPTION
systemd-loop@.service is a template service that may be used to automatically attach a loopback block device at boot (or later). Its instance string may reference an (escaped) file system path pointing to a disk image to attach as loopback block device. Use systemd-escape(1)'s --path to properly escape a file system path.

This unit invokes systemd-dissect --attach --quiet --loop-ref-auto on the specified files, see systemd-dissect(1) for details.

## SEE ALSO
systemd(1), systemd-dissect(1), systemd-import-generator(8)


systemd-machine-id-commit.service

title: systemd-machine-id-commit.service(8)

summary: Commit a transient machine ID to disk

text:
# systemd-machine-id-commit.service(8)

## NAME
systemd-machine-id-commit.service - Commit a transient machine ID to disk

## SYNOPSIS
systemd-machine-id-commit.service

## DESCRIPTION
systemd-machine-id-commit.service is an early boot service responsible for committing transient /etc/machine-id files to a writable disk file system. See machine-id(5) for more information about machine IDs.

This service is started after local-fs.target in case /etc/machine-id is a mount point of its own (usually from a memory file system such as "tmpfs") and /etc is writable. The service will invoke systemd-machine-id-setup --commit, which writes the current transient machine ID to disk and unmount the /etc/machine-id file in a race-free manner to ensure that file is always valid and accessible for other processes. See systemd-machine-id-setup(1) for details.

The main use case of this service are systems where /etc/machine-id is read-only and initially not initialized. In this case, the system manager will generate a transient machine ID file on a memory file system, and mount it over /etc/machine-id, during the early boot phase. This service is then invoked in a later boot phase, as soon as /etc/ has been remounted writable and the ID may thus be committed to disk to make it permanent.

## SEE ALSO
systemd(1), systemd-machine-id-setup(1), machine-id(5), systemd-firstboot(1)


systemd-makefs@.service

title: systemd-makefs@.service(8)

text:
# systemd-makefs@.service(8)

## NAME
systemd-makefs@.service, systemd-mkswap@.service, systemd-growfs@.service, systemd-growfs-root.service, systemd-makefs, systemd-growfs - Creating and growing file systems on demand

## SYNOPSIS
systemd-makefs@device.service

systemd-mkswap@device.service

systemd-growfs@mountpoint.service

systemd-growfs-root.service

/usr/lib/systemd/systemd-makefs

/usr/lib/systemd/systemd-growfs

## DESCRIPTION
systemd-makefs@.service, systemd-mkswap@.service, systemd-growfs@.service, and systemd-growfs-root.service are used to implement the x-systemd.makefs and x-systemd.growfs options in fstab(5), see systemd.mount(5). They are instantiated for each device for which the file system or swap structure needs to be initialized, and for each mount point where the file system needs to be grown.

These services are started at boot, either right before or right after the mount point or swap device are used.

systemd-makefs knows very little about specific file systems and swap devices, and after checking that the block device does not already contain a file system or other content, it will execute binaries specific to each filesystem type (/sbin/mkfs.type or /sbin/mkswap). For certain file system types (currently ext2/ext3/ext4(5), btrfs(5), xfs(5), f2fs, vfat) and for swap devices, it will configure reasonable defaults and set the file system label and UUID based on the device name.

systemd-growfs knows very little about specific file systems and swap devices, and will instruct the kernel to grow the mounted filesystem to full size of the underlying block device. Nevertheless, it needs to know the ioctl(2) number specific to each file system, so only certain types are supported. Currently: ext4(5), btrfs(5), xfs(5), and dm-crypt partitions (see cryptsetup(8)).

If the creation of a file system or swap device fails, the mount point or swap is failed too. If the growing of a file system fails, a warning is emitted.

## SEE ALSO
systemd(1), systemd.mount(5), systemd-fstab-generator(8), systemd-repart(8), mkfs.btrfs(8), mkfs.cramfs(8), mkfs.ext4(8), mkfs.fat(8), mkfs.hfsplus(8), mkfs.minix(8), mkfs.ntfs(8), mkfs.xfs(8)


systemd-modules-load.service

title: systemd-modules-load.service(8)

summary: Load kernel modules at boot

text:
# systemd-modules-load.service(8)

## NAME
systemd-modules-load.service, systemd-modules-load - Load kernel modules at boot

## SYNOPSIS
systemd-modules-load.service

/usr/lib/systemd/systemd-modules-load

## DESCRIPTION
systemd-modules-load.service is an early boot service that loads kernel modules. It reads static configuration from files in /usr/ and /etc/, but also runtime configuration from /run/ and the kernel command line (see below).

See modules-load.d(5) for information about the configuration format of this service and paths where configuration files can be created.

## KERNEL COMMAND LINE
systemd-modules-load.service understands the following kernel command line parameters:

modules_load=, rd.modules_load=

Takes a comma-separated list of kernel modules to statically load during early boot. The option prefixed with "rd." is read in the initrd only. Added in version 187.

## SEE ALSO
systemd(1), modules-load.d(5)


systemd-oomd.service

title: systemd-oomd.service(8)

summary: A userspace out\-of\-memory (OOM) killer

text:
# systemd-oomd.service(8)

## NAME
systemd-oomd.service, systemd-oomd - A userspace out-of-memory (OOM) killer

## SYNOPSIS
systemd-oomd.service

/usr/lib/systemd/systemd-oomd

## DESCRIPTION
systemd-oomd is a system service that uses cgroups-v2 and pressure stall information (PSI) to monitor and take corrective action before an OOM occurs in the kernel space.

You can enable monitoring and actions on units by setting ManagedOOMSwap= and ManagedOOMMemoryPressure= in the unit configuration, see systemd.resource-control(5). systemd-oomd retrieves information about such units from systemd(1) when it starts and watches for subsequent changes.

Cgroups of units with ManagedOOMSwap= or ManagedOOMMemoryPressure= set to kill will be monitored. systemd-oomd periodically polls PSI statistics for the system and those cgroups to decide when to take action. If the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it. Note that only descendant cgroups are eligible candidates for killing; the unit with its property set to kill is not a candidate (unless one of its ancestors set their property to kill). Also only leaf cgroups and cgroups with memory.oom.group set to 1 are eligible candidates; see OOMPolicy= in systemd.service(5).

oomctl(1) can be used to list monitored cgroups and pressure information.

See oomd.conf(5) for more information about the configuration of this service.

See org.freedesktop.oom1(5) and org.freedesktop.LogControl1(5) for a description of the D-Bus API.

## SYSTEM REQUIREMENTS AND CONFIGURATION
The system must be running systemd with a full unified cgroup hierarchy for the expected cgroups-v2 features. Furthermore, memory accounting must be turned on for all units monitored by systemd-oomd. The easiest way to turn on memory accounting is by ensuring the value for DefaultMemoryAccounting= is set to true in systemd-system.conf(5).

The kernel must be compiled with PSI support. This is available in Linux 4.20 and above.

It is highly recommended for the system to have swap enabled for systemd-oomd to function optimally. With swap enabled, the system spends enough time swapping pages to let systemd-oomd react. Without swap, the system enters a livelocked state much more quickly and may prevent systemd-oomd from responding in a reasonable amount of time. See "In defence of swap: common misconceptions"[1] for more details on swap. Any swap-based actions on systems without swap will be ignored. While systemd-oomd can perform pressure-based actions on such a system, the pressure increases will be more abrupt and may require more tuning to get the desired thresholds and behavior.

Be aware that if you intend to enable monitoring and actions on user.slice, user-$UID.slice, or their ancestor cgroups, it is highly recommended that your programs be managed by the systemd user manager to prevent running too many processes under the same session scope (and thus avoid a situation where memory intensive tasks trigger systemd-oomd to kill everything under the cgroup). If you're using a desktop environment like GNOME or KDE, it already spawns many session components with the systemd user manager.

## USAGE RECOMMENDATIONS
ManagedOOMSwap= works with the system-wide swap values, so setting it on the root slice -.slice, and allowing all descendant cgroups to be eligible candidates may make the most sense.

ManagedOOMMemoryPressure= tends to work better on the cgroups below the root slice. For units which tend to have processes that are less latency sensitive (e.g. system.slice), a higher limit like the default of 60% may be acceptable, as those processes can usually ride out slowdowns caused by lack of memory without serious consequences. However, something like user@$UID.service may prefer a much lower value like 40%.

## OPTIONS
--dry-run

Do a dry run of systemd-oomd: when a kill is triggered, print it to the log instead of killing the cgroup. Added in version 253.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## SIGNALS
SIGHUP

Upon reception of the SIGHUP process signal systemd-oomd will reload its configuration file. Added in version 258.

## SEE ALSO
systemd(1), systemd-system.conf(5), systemd.resource-control(5), oomd.conf(5), oomctl(1), org.freedesktop.oom1(5)

## NOTES
1.

"In defence of swap: common misconceptions"

https://chrisdown.name/2018/01/02/in-defence-of-swap.html


systemd-pcrlock

title: systemd-pcrlock(8)

text:
# systemd-pcrlock(8)

## NAME
systemd-pcrlock, systemd-pcrlock-file-system.service, systemd-pcrlock-firmware-code.service, systemd-pcrlock-firmware-config.service, systemd-pcrlock-machine-id.service, systemd-pcrlock-make-policy.service, systemd-pcrlock-secureboot-authority.service, systemd-pcrlock-secureboot-policy.service - Analyze and predict TPM2 PCR states and generate an access policy from the prediction

## SYNOPSIS
/usr/lib/systemd/systemd-pcrlock [OPTIONS...]

## DESCRIPTION
Note: this command is experimental for now. While it is likely to become a regular component of systemd, it might still change in behaviour and interface.

systemd-pcrlock is a tool that may be used to analyze and predict TPM2 PCR measurements, and generate TPM2 access policies from the prediction which it stores in a TPM2 NV index (i.e. in the TPM2 non-volatile memory). This may then be used to restrict access to TPM2 objects (such as disk encryption keys) to system boot-ups in which only specific, trusted components are used.

systemd-pcrlock uses as input for its analysis and prediction:

•The UEFI firmware TPM2 event log (i.e. /sys/kernel/security/tpm0/binary_bios_measurements) of the current boot.

•The userspace TPM2 event log (i.e. /run/log/systemd/tpm2-measure.log) of the current boot.

•The current PCR state of the TPM2 chip.

•Boot component definition files (*.pcrlock and *.pcrlock.d/*.pcrlock, see systemd.pcrlock(5)) that each define expected measurements for one component of the boot process, permitting alternative variants for each. (Variants may be used to bless multiple kernel versions or boot loader versions at the same time.)

It uses these inputs to generate a combined event log, validating it against the PCR states. It then attempts to recognize event log records and matches them against the defined components. For each PCR where this can be done comprehensively (i.e. where all listed records and all defined components have been matched) this may then be used to predict future PCR measurements, taking the alternative variants defined for each component into account. This prediction may then be converted into a TPM2 access policy (consisting of TPM2 PolicyPCR and PolicyOR items), which is then stored in an NV index in the TPM2. This may be used to then lock secrets (such as disk encryption keys) to these policies (via a TPM2 PolicyAuthorizeNV policy).

Use tools such as systemd-cryptenroll(1) or systemd-repart(8) to bind disk encryption to such a systemd-pcrlock TPM2 policy. Specifically, see the --tpm2-pcrlock= switches of these tools.

The access policy logic requires a TPM2 device that implements the "PolicyAuthorizeNV" command, i.e. implements TPM 2.0 version 1.38 or newer.

## COMMANDS
The following commands are understood:

log

This reads the combined TPM2 event log, validates it, matches it against the current PCR values, and outputs both in tabular form. Combine with --json= to generate output in JSON format. Added in version 255.

cel

This reads the combined TPM2 event log and writes it to STDOUT in TCG Canonical Event Log Format (CEL-JSON)[1]. Added in version 255.

list-components

Shows a list of component definitions and their variants, i.e. the *.pcrlock files discovered in /var/lib/pcrlock.d/, /usr/lib/pcrlock.d/, and the other supported directories. See systemd.pcrlock(5) for details on these files and the full list of directories searched. Added in version 255.

predict

Predicts the PCR state on future boots. This will analyze the TPM2 event log as described above, recognize components, and then generate all possible resulting PCR values for all combinations of component variants. Note that no prediction is made for PCRs whose value does not match the event log records, for which unrecognized measurements are discovered or for which components are defined that cannot be found in the event log. This is a safety measure to ensure that any generated access policy can be fulfilled correctly on current and future boots. Added in version 255.

make-policy

This predicts the PCR state for future boots, much like the predict command above. It then uses this data to generate a TPM2 access policy which it stores in a TPM2 NV index. The prediction and information about the used TPM2 and its NV index are written to /var/lib/systemd/pcrlock.json. The NV index is allocated on first invocation, and updated on subsequent invocations.

The NV index contents may be changed (and thus the policy stored in it updated) by providing an access PIN. This PIN is normally generated automatically and stored in encrypted form (with an access policy binding it to the NV index itself) in the aforementioned JSON policy file. This PIN may be chosen by the user, via the --recovery-pin= switch. If specified it may be used as alternative path of access to update the policy.

If the new prediction matches the old this command terminates quickly and executes no further operation. (Unless --force is specified, see below.)

Starting with v256, a copy of the /var/lib/systemd/pcrlock.json policy file is encoded in a credential (see systemd-creds(1) for details) and written to the EFI System Partition or XBOOTLDR partition, in the /loader/credentials/ subdirectory. There it is picked up at boot by systemd-stub(7) and passed to the invoked initrd, where it can be used to unlock the root file system (which typically contains /var/, which is where the primary copy of the policy is located, which hence cannot be used to unlock the root file system). The credential file is named after the boot entry token of the installation (see bootctl(1)), which is configurable via the --entry-token= switch, see below.

Added in version 255.

remove-policy

Removes a previously generated policy. Deletes the /var/lib/systemd/pcrlock.json file, and deallocates the NV index. Added in version 255.

is-supported

Checks if the local TPM2 supports all functionality for systemd-pcrlock to work correctly. This does similar tests as systemd-analyze has-tpm2, but also checks for supported of the TPM2 operations requires by systemd-pcrlock. Outputs one of "no", "partial" (in case some parts of TPM2 support are available in hardware, firmware, OS, but not complete), "obsolete" (if TPM2 support is available in hardware, firmware and OS, but the operations required for systemd-pcrlock are missing), "yes". Returns an exit status of zero if full support is available, otherwise non-zero. If combined with --quiet, suppresses the output of the string.

Currently, this checks for support for the PolicAuthorizeNV TPM2 command, as well as for support of the SHA-256 hash algorithm.

Added in version 258.

lock-firmware-code, unlock-firmware-code

Generates/removes .pcrlock files based on the TPM2 event log of the current boot covering all records for PCRs 0 ("platform-code") and 2 ("external-code"). This operation allows locking the boot process to the current version of the firmware of the system and its extension cards. This operation should only be used if the system vendor does not provide suitable pcrlock data ahead of time.

Note that this data only matches the current version of the firmware. If a firmware update is applied this data will be out-of-date and any access policy generated from it will no longer pass. It is thus recommended to invoke unlock-firmware-code before doing a firmware update, followed by make-policy to refresh the policy.

systemd-pcrlock lock-firmware-code is invoked automatically at boot via the systemd-pcrlock-firmware-code.service unit, if enabled. This ensures that an access policy managed by systemd-pcrlock is automatically locked to the new firmware version whenever the policy has been relaxed temporarily, in order to cover for firmware updates, as described above.

The files are only generated from the event log if the event log matches the current TPM2 PCR state.

This writes/removes the files /var/lib/pcrlock.d/250-firmware-code-early.pcrlock.d/generated.pcrlock and /var/lib/pcrlock.d/550-firmware-code-late.pcrlock.d/generated.pcrlock.

Added in version 255.

lock-firmware-config, unlock-firmware-config

This is similar to lock-firmware-code/unlock-firmware-code but locks down the firmware configuration, i.e. PCRs 1 ("platform-config") and 3 ("external-config"). This functionality should be used with care as in most scenarios a minor firmware configuration change should not invalidate access policies to TPM2 objects. Also note that some systems measure unstable and unpredictable information (e.g. current CPU voltages, temperatures, as part of SMBIOS data) to these PCRs, which means this form of lockdown cannot be used reliably on such systems. Use this functionality only if the system and hardware is well known and does not suffer by these limitations, for example in virtualized environments.

Use unlock-firmware-config before making firmware configuration changes. If the systemd-pcrlock-firmware-config.service unit is enabled it will automatically generate a pcrlock file from the new measurements.

This writes/removes the files /var/lib/pcrlock.d/250-firmware-config-early.pcrlock.d/generated.pcrlock and /var/lib/pcrlock.d/550-firmware-config-late.pcrlock.d/generated.pcrlock.

Added in version 255.

lock-secureboot-policy, unlock-secureboot-policy

Generates/removes a .pcrlock file based on the SecureBoot policy currently enforced. This looks at the SecureBoot, PK, KEK, db, dbx, dbt, dbr EFI variables and predicts their measurements to PCR 7 ("secure-boot-policy") on the next boot. Use unlock-firmware-config before applying SecureBoot policy updates. If the systemd-pcrlock-secureboot-policy.service unit is enabled it will automatically generate a pcrlock file from the policy discovered.

This writes/removes the file /var/lib/pcrlock.d/230-secureboot-policy.pcrlock.d/generated.pcrlock.

Added in version 255.

lock-secureboot-authority, unlock-secureboot-authority

Generates/removes a .pcrlock file based on the SecureBoot authorities used to validate the boot path. SecureBoot authorities are the specific SecureBoot database entries that where used to validate the UEFI PE binaries executed at boot. This looks at the event log of the current boot, and uses relevant measurements on PCR 7 ("secure-boot-policy"). This writes/removes the file /var/lib/pcrlock.d/620-secureboot-authority.pcrlock.d/generated.pcrlock.

Added in version 255.

lock-gpt [DEVICE], unlock-gpt

Generates/removes a .pcrlock file based on the GPT partition table of the specified disk. If no disk is specified automatically determines the block device backing the root file system. This locks the state of the disk partitioning of the booted medium, which firmware measures to PCR 5 ("boot-loader-config"). This writes/removes the file /var/lib/pcrlock.d/600-gpt.pcrlock.d/generated.pcrlock.

Added in version 255.

lock-pe [BINARY], unlock-pe

Generates/removes a .pcrlock file based on the specified PE binary. This is useful for predicting measurements the firmware makes to PCR 4 ("boot-loader-code") if the specified binary is part of the UEFI boot process. Use this on boot loader binaries and suchlike. Use lock-uki (see below) for PE binaries that are unified kernel images (UKIs). Expects a path to the PE binary as argument. If not specified, reads the binary from STDIN instead.

The pcrlock file to write must be specified via the --pcrlock= switch.

Added in version 255.

lock-uki [UKI], unlock-uki

Generates/removes a .pcrlock file based on the specified UKI PE binary. This is useful for predicting measurements the firmware makes to PCR 4 ("boot-loader-code"), and systemd-stub(7) makes to PCR 11 ("kernel-boot"), if the specified UKI is booted. This is a superset of lock-pe. Expects a path to the UKI PE binary as argument. If not specified, reads the binary from STDIN instead.

The pcrlock file to write must be specified via the --pcrlock= switch.

Added in version 255.

lock-machine-id, unlock-machine-id

Generates/removes a .pcrlock file based on /etc/machine-id. This is useful for predicting measurements systemd-pcrmachine.service(8) makes to PCR 15 ("system-identity"). This writes/removes the file /var/lib/pcrlock.d/820-machine-id.pcrlock.

Added in version 255.

lock-file-system [PATH], unlock-file-system [PATH]

Generates/removes a .pcrlock file based on file system identity. This is useful for predicting measurements systemd-pcrfs@.service(8) makes to PCR 15 ("system-identity") for the root and /var/ file systems. This writes/removes the files /var/lib/pcrlock.d/830-root-file-system.pcrlock and /var/lib/pcrlock.d/840-file-system-path.pcrlock.

Added in version 255.

lock-kernel-cmdline [FILE], unlock-kernel-cmdline

Generates/removes a .pcrlock file based on /proc/cmdline (or the specified file if given). This is useful for predicting measurements the Linux kernel makes to PCR 9 ("kernel-initrd"). This writes/removes the file /var/lib/pcrlock.d/710-kernel-cmdline.pcrlock/generated.pcrlock.

Added in version 255.

lock-kernel-initrd FILE, unlock-kernel-initrd

Generates/removes a .pcrlock file based on a kernel initrd cpio archive. This is useful for predicting measurements the Linux kernel makes to PCR 9 ("kernel-initrd"). Do not use for systemd-stub(7) UKIs, as the initrd is combined dynamically from various sources and hence does not take a single input, like this command. This writes/removes the file /var/lib/pcrlock.d/720-kernel-initrd.pcrlock/generated.pcrlock.

Added in version 255.

lock-raw [FILE], unlock-raw

Generates/removes a .pcrlock file based on raw binary data. The data is either read from the specified file or from STDIN (if none is specified). This requires that --pcrs= is specified. The generated .pcrlock file is written to the file specified via --pcrlock= or to STDOUT (if none is specified). Added in version 255.

## OPTIONS
The following options are understood:

--raw-description

When displaying the TPM2 event log do not attempt to decode the records to provide a friendly event log description string. Instead, show the binary payload data in escaped form. Added in version 255.

--pcr=

Specifies the PCR number to use. May be specified more than once to select multiple PCRs. This is used by lock-raw and lock-pe to select the PCR to lock against.

If used with predict and make-policy this will override which PCRs to include in the prediction and policy. If unspecified this defaults to PCRs 0-5, 7, 11-15. Note that these commands will not include any PCRs in the prediction/policy (even if specified explicitly) if there are measurements in the event log that do not match the current PCR value, or there are unrecognized measurements in the event log, or components define measurements not seen in the event log.

Added in version 255.

--nv-index=

Specifies the NV index to store the policy in. Honoured by make-policy. If not specified, the command will automatically pick a free NV index. Added in version 255.

--components=

Takes a path to read *.pcrlock and *.pcrlock.d/*.pcrlock files from. May be used more than once to specify multiple such directories. If not specified, defaults to /etc/pcrlock.d/, /run/pcrlock.d/, /var/lib/pcrlock.d/, /usr/local/lib/pcrlock.d/, /usr/lib/pcrlock.d/. Added in version 255.

--location=

Takes either a string or a colon-separated pair of strings. Configures up to which point in the sorted list of defined components to analyze/predict PCRs to. Typically, the systemd-pcrlock tool is invoked from a fully booted system after boot-up and before shutdown. This means various components that are defined for shutdown have not been measured yet, and should not be searched for. This option allows one to restrict which components are considered for analysis (taking only components before some point into account, ignoring components after them). The expected string is ordered against the filenames of the components defined. Any components with a lexicographically later name are ignored. This logic applies to the log, predict, and make-policy verbs. If a colon-separated pair of strings are specified then they select which phases of the boot to include in the prediction/policy. The first string defines where the first prediction shall be made, and the second string defines where the last prediction shall be made. All such predictions are then combined into one set. If used with list-components the selected location range will be highlighted in the component list.

Defaults to "760-:940-", which means the policies generated by default will basically cover the whole runtime of the OS userspace, from the initrd (as "760-" closely follows 750-enter-initrd.pcrlock) until (and including) the main runtime of the system (as "940-" is closely followed by 950-shutdown.pcrlock). See systemd.pcrlock(5) for a full list of well-known components, that illustrate where this range is placed by default.

Added in version 255.

--recovery-pin=

Takes one of "hide", "show" or "query". Defaults to "hide". Honoured by make-policy. If "query", will query the user for a PIN to unlock the TPM2 NV index with. If no policy was created before, this PIN is used to protect the newly allocated NV index. If a policy has been created before, the PIN is used to unlock write access to the NV index. If either "hide" or "show" is used, a PIN is automatically generated, and — only in case of "show" — displayed on screen. Regardless if user supplied or automatically generated, it is stored in encrypted form in the policy metadata file. The recovery PIN may be used to regain write access to an NV index in case the access policy became out of date. Added in version 255.

--pcrlock=

Takes a file system path as argument. If specified, configures where to write the generated pcrlock data to. Honoured by the various lock-* commands. If not specified, a default path is generally used, as documented above. Added in version 255.

--policy=

Takes a file system path as argument. If specified, configures where to write pcrlock policy metadata to. If not specified, defaults to /var/lib/systemd/pcrlock.json. Added in version 255.

--force

If specified with make-policy, the predicted policy will be written to the NV index even if it is detected to be the same as the previously stored one. Added in version 255.

--entry-token=

Sets the boot entry token to use for the file name for the pcrlock policy credential in the EFI System Partition or XBOOTLDR partition. See the bootctl(1) option of the same regarding expected values. This switch has an effect on the make-policy command only. Added in version 256.

--quiet

If specified suppresses output when invoked for is-supported. Added in version 258.

--json=MODE

Shows output formatted as JSON. Expects one of "short" (for the shortest possible output without any redundant whitespace or line breaks), "pretty" (for a pretty version of the same, with indentation and line breaks) or "off" (to turn off JSON output, the default).

--no-pager

Do not pipe output into a pager.

-h, --help

Print a short help text and exit.

--version

Print a short version string and exit.

## EXIT STATUS
On success, 0 is returned, a non-zero failure code otherwise.

## SEE ALSO
systemd(1), systemd.pcrlock(5), systemd-cryptenroll(1), systemd-cryptsetup@.service(8), systemd-repart(8), systemd-pcrmachine.service(8), systemd-creds(1), systemd-stub(7), bootctl(1)

## NOTES
1.

TCG Canonical Event Log Format (CEL-JSON)

https://trustedcomputinggroup.org/resource/canonical-event-log-format/