diff --git a/man/systemctl.xml b/man/systemctl.xml index e3776fb277..e54dd22aae 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -1535,13 +1535,27 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err kexec - Shut down and reboot the system via kexec. This is equivalent to - systemctl start kexec.target --job-mode=replace-irreversibly --no-block. This command is - asynchronous; it will return after the reboot operation is enqueued, without waiting for it to - complete. + Shut down and reboot the system via kexec. This command will load a + kexec kernel if one wasn't loaded yet or fail. A kernel may be loaded earlier by a separate step, + this is particularly useful if a custom initrd or additional kernel commandline options are + desired. The can be used to continue without a kexec kernel, i.e. to + perform a normal reboot. The final reboot step is equivalent to + systemctl start kexec.target --job-mode=replace-irreversibly --no-block. + - This command honors and in a similar way - as halt. + To load a kernel, an enumeration is performed following the + Boot Loader Specification, + and the default boot entry is loaded. For this step to succeed, the system must be using UEFI + and the boot loader entries must be configured appropriately. bootctl list + may be used to list boot entries, see + bootctl1. + + + This command is asynchronous; it will return after the reboot operation is enqueued, + without waiting for it to complete. + + This command honors and similarly + to halt. diff --git a/man/systemd-gpt-auto-generator.xml b/man/systemd-gpt-auto-generator.xml index e176d32d9c..23f1235551 100644 --- a/man/systemd-gpt-auto-generator.xml +++ b/man/systemd-gpt-auto-generator.xml @@ -185,15 +185,16 @@ - The /home/, /srv/, /var/ and - /var/tmp/ 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 and - /dev/mapper/tmp. Note that this might create conflicts if the same partition is - listed in /etc/crypttab with a different device mapper device name. + 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 in LUKS - format as well. In this case, a device mapper device is set up under the 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 bootup7. diff --git a/man/systemd-repart.xml b/man/systemd-repart.xml index cd5d4631db..c18b2eb754 100644 --- a/man/systemd-repart.xml +++ b/man/systemd-repart.xml @@ -84,15 +84,17 @@ existing partition of a specific type is then assigned the second configuration file declaring the same type, and so on. After this iterative assigning is complete any left-over existing partitions that have no matching configuration file are considered "foreign" and left as they are. And any configuration - files for which no partition currently exists are understood as a request to create such a - partition. + files for which no partition currently exists are understood as a request to create such a partition. + - Taking the size constraints and weights declared in the configuration files into - account, all partitions that shall be created are now allocated to the disk, taking up all free space, - always respecting the size and padding requests. Similarly, existing partitions that should be grown - are grown. New partitions are always appended to the end of the partition table, taking the first - partition table slot whose index is greater than the indexes of all existing partitions. Partition - table slots are never reordered and thus partition numbers are ensured to remain stable. Note that this + Partitions that shall be created are now allocated on the disk, taking the size + constraints and weights declared in the configuration files into account. Free space is used within the + limits set by size and padding requests. In addition, existing partitions that should be grown are + grown. New partitions are always appended to the end of the partition table, taking the first partition + table slot whose index is greater than the indexes of all existing partitions. Partitions are never + reordered and thus partition numbers remain stable. When partitions are created, they are placed in the + smallest area of free space that is large enough to satisfy the size and padding limits. This means + that partitions might have different order on disk than in the parition table. Note that this allocation happens in memory only, the partition table on disk is not updated yet. All existing partitions for which configuration files exist and which currently have no diff --git a/man/systemd.target.xml b/man/systemd.target.xml index 604b14e438..f6508256e3 100644 --- a/man/systemd.target.xml +++ b/man/systemd.target.xml @@ -26,30 +26,33 @@ Description - A unit configuration file whose name ends in - .target encodes information about a target unit - of systemd, which is used for grouping units and as well-known - synchronization points during start-up. + A unit configuration file whose name ends in .target encodes information about a + target unit of systemd. Target units are used to group units and to set synchronization points for + ordering dependencies with other unit files. This unit type has no specific options. See - systemd.unit5 - for the common options of all unit configuration files. The common - configuration items are configured in the generic [Unit] and - [Install] sections. A separate [Target] section does not exist, - since no target-specific options may be configured. + systemd.unit5 for the + common options of all unit configuration files. The common configuration items are configured in the + generic [Unit] and [Install] sections. A separate [Target] section does not exist, since no + target-specific options may be configured. - Target units do not offer any additional functionality on - top of the generic functionality provided by units. They exist - merely to group units via dependencies (useful as boot targets), - and to establish standardized names for synchronization points - used in dependencies between units. Among other things, target - units are a more flexible replacement for SysV runlevels in the - classic SysV init system. (And for compatibility reasons special - target units such as runlevel3.target exist - which are used by the SysV runlevel compatibility code in systemd. - See - systemd.special7 - for details). + Target units do not offer any additional functionality on top of the generic functionality provided + by units. They merely group units, allowing a single target name to be used in Wants= + and Requires= settings to establish a dependency on a set of units defined by the + target, and in Before= and After= settings to establish ordering. + Targets establish standardized names for synchronization points during boot and shutdown. Importantly, + see systemd.special7 + for examples and descriptions of standard systemd targets. + + Target units provide a more flexible replacement for SysV runlevels in the classic SysV init + system. For compatibility reasons special target units such as runlevel3.target + exist which are used by the SysV runlevel compatibility code in systemd, see + systemd.special7 for + details. + + Note that a target unit file must not be empty, lest it be considered a masked unit. It is + recommended to provide a [Unit] section which includes informative Description= and + Documentation= options. @@ -68,14 +71,18 @@ DefaultDependencies=no is set: - Target units will automatically complement all - configured dependencies of type Wants= or - Requires= with dependencies of type - After= unless DefaultDependencies=no - is set in the specified units. Note that Wants= or - Requires= must be defined in the target unit itself — if - you for example define Wants=some.target in - some.service, the automatic ordering will not be added. + Target units will automatically complement all configured dependencies of type + Wants= or Requires= with dependencies of type + After= unless DefaultDependencies=no is set in the specified + units. + + Note that the reverse is not true. For example, defining in + some.service will not automatically add the + ordering dependency for some.service. + Instead, some.service should use the primary synchronization function of target + type units, by setting a specific or + ordering dependency in its .service unit file. + Target units automatically gain Conflicts= and Before= dependencies against