morgan/systemd
1
0
Fork 0
mirror of https://github.com/morgan9e/systemd synced 2026-04-14 00:14:32 +09:00
Code Issues Packages Projects Releases Wiki Activity

man: better tags, more links, minor grammar and formatting improvements

Browse Source 
Closes https://github.com/systemd/systemd/issues/35751.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
2025-05-28 15:20:50 +02:00
parent acf3bdf813
commit b082968d19
27 changed files with 150 additions and 124 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
man/busctl.xml
View File

@@ -149,7 +149,7 @@
<listitem><para>Wait for a signal. Takes an object path, interface name, and signal name. To suppress
output of the returned data, use the <option>--quiet</option> option. The service name may be
omitted, in which case busctl will match signals from any sender.</para>
omitted, in which case <command>busctl</command> will match signals from any sender.</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
</varlistentry>

3
man/coredump.conf.xml
View File

@@ -113,7 +113,8 @@
<term><varname>EnterNamespace=</varname></term>
<listitem><para>For processes belonging to a PID namespace, controls whether
<command>systemd-coredump</command> shall attempt to process core dumps on the host, using debug
<citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>
shall attempt to process core dumps on the host, using debug
information from the file system hierarchy (i.e. the mount namespace) of the process that
crashed. Access to the process' file system hierarchy might be necessary to generate a fully
symbolized backtrace. If set to <literal>yes</literal>, <command>systemd-coredump</command> will

14
man/networkctl.xml
View File

@@ -422,7 +422,8 @@ s - Service VLAN, m - Two-port MAC Relay (TPMR)
was created, so changing [VLAN] <varname>Id=</varname> will not take effect if the matching VLAN
interface already exists. To apply such settings, the interfaces need to be removed manually before
reload. Also note that even if a <filename>.netdev</filename> file is removed,
<command>systemd-networkd</command> does not remove the existing netdev corresponding to the file.
<citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
does not remove the existing netdev corresponding to the file.
</para>
<para>If a new, modified, or removed <filename>.network</filename> file is found, then all
@@ -449,9 +450,9 @@ s - Service VLAN, m - Two-port MAC Relay (TPMR)
<para>If <option>--drop-in=</option> is specified, edit the drop-in file instead of
the main configuration file. Unless <option>--no-reload</option> is specified,
<command>systemd-networkd</command> will be reloaded after the edit of the
<filename>.network</filename> or <filename>.netdev</filename> files finishes.
The same applies for <filename>.link</filename> files and
<citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
will be reloaded after the edit of the <filename>.network</filename> or <filename>.netdev</filename>
files finishes. The same applies for <filename>.link</filename> files and
<citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
Note that the changed link settings are not automatically applied after reloading.
To achieve that, trigger uevents for the corresponding interface. Refer to
@@ -520,8 +521,9 @@ s - Service VLAN, m - Two-port MAC Relay (TPMR)
<replaceable>BOOL</replaceable>
</term>
<listitem>
<para>Notify <filename>systemd-networkd.service</filename> that the persistent storage for the
service is ready. This is called by
<para>Notify
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
that the persistent storage for the service is ready. This is called by
<filename>systemd-networkd-persistent-storage.service</filename>. Usually, this command should not
be called manually by users or administrators.</para>

2
man/os-release.xml
View File

@@ -343,7 +343,7 @@
<listitem><para><literal>lts</literal> is for long term support releases of the system, suitable
for production use and supported for an extended period of time. Generally, LTS releases
continue to receive support even if newer major releases of the distribution are available.
Examples include Ubuntu 24.04, Debian 12 Bookworm and RHEL 9.4.</para></listitem>
Examples include Ubuntu 24.04, Debian 12 Bookworm, and RHEL 9.4.</para></listitem>
<listitem><para><literal>development</literal> is for unstable versions of the system,
unsuitable for production use, such as alpha, beta, or rolling unstable releases. Examples

39
man/repart.d.xml
View File

@@ -516,7 +516,7 @@
<literal>/</literal>, both the directory and its contents are excluded.</para>
<para><varname>ExcludeFilesTarget=</varname> is like <varname>ExcludeFiles=</varname> except that
instead of excluding the path on the host from being copied into the partition, it exclude any files
instead of excluding the path on the host from being copied into the partition, it excludes any files
and directories from being copied into the given path in the partition.</para>
<para>When
@@ -612,10 +612,10 @@
<varname>MakeDirectories=</varname> and <varname>CopyFiles=</varname>.</para>
<para>Note that this option only takes effect if the target filesystem supports subvolumes, such as
<literal>btrfs</literal>.</para>
<citerefentry project="url"><refentrytitle url="https://btrfs.readthedocs.io/en/latest/btrfs.html">btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
<para>Note that this option is only supported in combination with <option>--offline=yes</option>
since btrfs-progs 6.11 or newer.</para>
since <filename>btrfs-progs</filename> 6.11 or newer.</para>
<xi:include href="version-info.xml" xpointer="v255"/></listitem>
</varlistentry>
@@ -632,7 +632,7 @@
</para>
<para>Note that this option is only supported in combination with <option>--offline=yes</option>
since btrfs-progs 6.11 or newer.</para>
since <filename>btrfs-progs</filename> 6.11 or newer.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
@@ -868,7 +868,9 @@
<para>Note that this setting is only taken into account when the filesystem configured with
<varname>Format=</varname> supports compression (
<citerefentry project="url"><refentrytitle url="https://btrfs.readthedocs.io/en/latest/btrfs.html">btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
squashfs, erofs). Here's an incomplete list of compression algorithms supported by the filesystems
squashfs,
<citerefentry project='man-pages'><refentrytitle>erofs</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
Here's an incomplete list of compression algorithms supported by the filesystems
known to <command>systemd-repart</command>:</para>
<table>
@@ -954,29 +956,30 @@
target for some other supplement definition. A target cannot have more than one supplement partition
associated with it.</para>
<para>For example, distributions can use this to implement <varname>$BOOT</varname> as defined in
the <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification/">Boot Loader
<para>For example, distributions can use this to implement <varname>$BOOT</varname> as defined in the
<ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification/">Boot Loader
Specification</ulink>. Distributions may prefer to use the ESP as <varname>$BOOT</varname> whenever
possible, but to adhere to the spec XBOOTLDR must sometimes be used instead. So, they should create
two definitions: the first defining an ESP big enough to hold just the bootloader, and a second for
the XBOOTLDR that's sufficiently large to hold kernels and configured as a supplement for the ESP.
Whenever possible, <command>systemd-repart</command> will try to merge the two definitions to create
one large ESP, but if that's not allowable due to the existing conditions on disk a small ESP and a
large XBOOTLDR will be created instead.</para>
Whenever possible,
<citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
will try to merge the two definitions to create one large ESP, but if that's not allowable due to the
existing conditions on disk a small ESP and a large XBOOTLDR will be created instead.</para>
<para>As another example, distributions can also use this to seamlessly share a single
<filename>/home</filename> partition in a multi-boot scenario, while preferring to keep
<filename>/home</filename> on the root partition by default. Having a <filename>/home</filename>
partition separated from the root partition entails some extra complexity: someone has to decide how
to split the space between the two partitions. On the other hand, it allows a user to share their
home area between multiple installed OSs (i.e. via <citerefentry><refentrytitle>systemd-homed.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>). Distributions should create two definitions:
the first for a root partition that takes up some relatively small percentage of the disk, and the
second as a supplement for the first to create a <filename>/home</filename> partition that takes up
all the remaining free space. On first boot, if <command>systemd-repart</command> finds an existing
<filename>/home</filename> partition on disk, it'll un-merge the definitions and create just a small
root partition. Otherwise, the definitions will be merged and a single large root partition will be
created.</para>
home area between multiple installed OSs (i.e. via
<citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>).
Distributions should create two definitions: the first for a root partition that takes up some
relatively small percentage of the disk, and the second as a supplement for the first to create a
<filename>/home</filename> partition that takes up all the remaining free space. On first boot, if
<command>systemd-repart</command> finds an existing <filename>/home</filename> partition on disk,
it'll un-merge the definitions and create just a small root partition. Otherwise, the definitions
will be merged and a single large root partition will be created.</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
</varlistentry>

12
man/systemctl.xml
View File

@@ -2298,11 +2298,13 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
<listitem>
<para>When system shutdown or sleep state is requested, this option controls checking of inhibitor
locks. It takes one of <literal>auto</literal>, <literal>yes</literal> or
<literal>no</literal>. Defaults to <literal>auto</literal>, which means logind will perform the
check and respect active inhibitor locks, but systemctl will only do a client-side check for
interactive invocations (i.e. from a TTY), so that a more friendly and informative error can be
returned to users. <literal>no</literal> disables both the systemctl and logind checks.</para>
locks. It takes one of <literal>auto</literal>, <literal>yes</literal>, and <literal>no</literal>.
Defaults to <literal>auto</literal>, which means logind will perform the check and respect active
inhibitor locks, but <command>systemctl</command> will only do a client-side check for interactive
invocations (i.e. from a TTY), so that a more friendly and informative error can be returned to
users. <literal>no</literal> disables the checks both in <command>systemctl</command> and
<citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
<para>Applications can establish inhibitor locks to prevent certain important operations (such as
CD burning) from being interrupted by system shutdown or sleep. Any user may take these locks and

7
man/systemd-boot.xml
View File

@@ -430,9 +430,10 @@
<term><varname>LoaderDevicePartUUID</varname></term>
<listitem><para>Contains the partition UUID of the partition the boot loader has been started from on
the current boot (usually a EFI System Partition). Set by the boot loader. (Note that
<command>systemd-stub</command> will set this too, if not set yet, to support systems that directly
boot into a unified kernel image, bypassing any boot loader.)
the current boot (usually an EFI System Partition). Set by the boot loader. (Note that
<citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> will
set this too, if not set yet, to support systems that boot directly into a unified kernel image,
bypassing any boot loader.)
<citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
uses this information to automatically find the disk booted from, in order to discover various other
partitions on the same disk automatically.</para>

2
man/systemd-cryptsetup.xml
View File

@@ -49,7 +49,7 @@
<refsect1>
<title>Description</title>
<para><filename>systemd-cryptsetup</filename> is used to set up (with <command>attach</command>) and tear
<para><command>systemd-cryptsetup</command> is used to set up (with <command>attach</command>) and tear
down (with <command>detach</command>) access to an encrypted block device. It is primarily used via
<filename>systemd-cryptsetup@.service</filename> during early boot, but may also be called manually.
The positional arguments <parameter>VOLUME</parameter>, <parameter>SOURCE-DEVICE</parameter>,

7
man/systemd-fsck@.service.xml
View File

@@ -64,10 +64,11 @@
returns the "Filesystem errors left uncorrected" condition.</para>
<para><filename>systemd-fsck@.service</filename> will fail if
<command>fsck</command> returns with either "System should reboot"
or "Filesystem errors left uncorrected" conditions. For filesystems
<citerefentry project='man-pages'><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry>
returns either the "System should reboot"
or the "Filesystem errors left uncorrected" condition. For filesystems
listed in <filename>/etc/fstab</filename> without <literal>nofail</literal>
or <literal>noauto</literal> options, <literal>local-fs.target</literal>
or <literal>noauto</literal> options, <filename>local-fs.target</filename>
will then activate <filename>emergency.target</filename>.</para>
</refsect1>

7
man/systemd-gpt-auto-generator.xml
View File

@@ -159,12 +159,7 @@
<entry><constant>4d21b016-b534-45c2-a9fb-5c16e091fd2d</constant></entry>
<entry>Variable Data Partition</entry>
<entry><filename>/var/</filename></entry>
<entry>The first partition with this type UUID on the same disk as the root partition is mounted
to <filename>/var/</filename> — 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
<citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
This can be generated using <citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</entry>
<entry>The first partition with this type UUID on the same disk as the root partition is mounted to <filename>/var/</filename> — 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 <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This can be generated using <citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</entry>
</row>
<row>
<entry><constant>SD_GPT_TMP</constant></entry>

10
man/systemd-import-generator.xml
View File

@@ -81,10 +81,11 @@
<term>verify=</term>
<listitem><para>Controls whether to cryptographically validate the download before installing it
in place. Takes one of <literal>no</literal>, <literal>checksum</literal> or
<literal>signature</literal> (the latter being the default if not specified). For details see the
in place. Takes one of <literal>no</literal>, <literal>checksum</literal>, or
<literal>signature</literal> (the default if not specified). For details see the
<option>--verify=</option> of
<citerefentry><refentrytitle>importctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></para>
<citerefentry><refentrytitle>importctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
</varlistentry>
@@ -111,7 +112,8 @@
<term>raw</term>
<listitem><para>Controls the type of resource to download, i.e. a (possibly compressed) tarball
that needs to be unpacked into a file system tree, or (possibly compressed) raw disk image (DDI).</para>
that needs to be unpacked into a file system tree, or (possibly compressed) raw disk image (DDI).
</para>
<para>Specification of exactly one of these options is mandatory.</para>

10
man/systemd-network-generator.service.xml
View File

@@ -143,15 +143,17 @@
<filename>50-foobar.link</filename>.</para>
<para>Note that the resulting files are created world-readable, it is hence recommended to not include
secrets in these credentials, but supply them via separate credentials directly to
<filename>systemd-networkd.service</filename>.</para>
secrets in these credentials, but to supply them via separate credentials directly to
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
</variablelist>
<para>Note that by default the <filename>systemd-network-generator.service</filename> unit file is set up
to inherit the these credentials from the service manager.</para>
<para>Note that by default the
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service is set up to inherit the these credentials from the service manager.</para>
</refsect1>
<refsect1>

7
man/systemd-pcrphase.service.xml
View File

@@ -73,7 +73,8 @@
<listitem><para><literal>leave-initrd</literal> — when the initrd is about to transition into the host
file system. It acts as barrier between initrd code and host OS code. (This extension happens when the
<filename>systemd-pcrphase-initrd.service</filename> service is stopped.)</para></listitem>
<citerefentry><refentrytitle>systemd-pcrphase-sysinit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service is stopped.)</para></listitem>
<listitem><para><literal>sysinit</literal> — when basic system initialization is complete (which
includes local file systems having been mounted), and the system begins starting regular system
@@ -85,7 +86,9 @@
activated (i.e. after <filename>remote-fs.target</filename>), but before users are permitted to log in
(i.e. before <filename>systemd-user-sessions.service</filename>). It acts as barrier between the time
where unprivileged regular users are still prohibited to log in and where they are allowed to log in.
(This extension happens when the <filename>systemd-pcrphase.service</filename> service is started.)
(This extension happens when the
<citerefentry><refentrytitle>systemd-pcrphase-sysinit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service is started.)
</para></listitem>
<listitem><para><literal>shutdown</literal> — when the system shutdown begins. It acts as barrier

6
man/systemd-poweroff.service.xml
View File

@@ -54,9 +54,9 @@
thus keeping the file system busy, which then cannot be re-mounted read-only.</para>
<para>Shortly before executing the actual system power-off/halt/reboot/kexec,
<filename>systemd-shutdown</filename> will run all executables in
<filename>/usr/lib/systemd/system-shutdown/</filename> and pass one arguments to them: either
<literal>poweroff</literal>, <literal>halt</literal>, <literal>reboot</literal>, or
<command>systemd-shutdown</command> will run all executables in
<filename>/usr/lib/systemd/system-shutdown/</filename>. Those executables are called with one argument:
either <literal>poweroff</literal>, <literal>halt</literal>, <literal>reboot</literal>, or
<literal>kexec</literal>, depending on the chosen action. All executables in this directory are executed
in parallel, and execution of the action is not continued before all executables finished. (A safety
timeout of 90s is applied however.) Note that these executables are run <emphasis>after</emphasis> all

2
man/systemd-repart.xml
View File

@@ -19,7 +19,7 @@
<refnamediv>
<refname>systemd-repart</refname>
<refname>systemd-repart.service</refname>
<refpurpose>Automatically grow and add partitions, and generate disk images (DDIs).</refpurpose>
<refpurpose>Automatically grow and add partitions, and generate disk images (DDIs)</refpurpose>
</refnamediv>
<refsynopsisdiv>

8
man/systemd-sbsign.xml
View File

@@ -73,12 +73,12 @@
<term><option>--certificate-source=<replaceable>TYPE</replaceable>[:<replaceable>NAME</replaceable>]</option></term>
<listitem><para>Set the Secure Boot private key and certificate for use with the
<command>sign</command>. The <option>--certificate=</option> option takes a path to a PEM encoded
X.509 certificate or a URI that's passed to the OpenSSL provider configured with
<option>--certificate-source</option>. The <option>--certificate-source</option> takes one of
<command>sign</command> verb. The <option>--certificate=</option> option takes a path to a
PEM-encoded X.509 certificate or a URI that's passed to the OpenSSL provider configured with
<option>--certificate-source</option>. The <option>--certificate-source</option> option takes one of
<literal>file</literal> or <literal>provider</literal>, with the latter being followed by a specific
provider identifier, separated with a colon, e.g. <literal>provider:pkcs11</literal>. The
<option>--private-key=</option> option can take a path or a URI that will be passed to the OpenSSL
<option>--private-key=</option> option takes a path or a URI that will be passed to the OpenSSL
engine or provider, as specified by <option>--private-key-source=</option> as a
<literal>type:name</literal> tuple, such as <literal>engine:pkcs11</literal>. The specified OpenSSL
signing engine or provider will be used to sign the PE binary.</para>

4
man/systemd-soft-reboot.service.xml
View File

@@ -170,8 +170,8 @@ DefaultDependencies=no</programlisting>
either.</para>
<para>Note that <filename>systemd-soft-reboot.service</filename> (and related units) should never be
executed directly. Instead, trigger system shutdown with a command such as <literal>systemctl
soft-reboot</literal>.</para>
executed directly. Instead, trigger system shutdown with a command such as <command>systemctl
soft-reboot</command>.</para>
<para>Note that if a new root file system has been set up on <literal>/run/nextroot/</literal>, a
<command>soft-reboot</command> will be performed when the <command>reboot</command> command is

38
man/systemd-stub.xml
View File

@@ -140,11 +140,12 @@
command line PE section in the kernel image file. If a command line is accepted via EFI invocation
parameters to the EFI binary it is measured into TPM PCR 12 (if a TPM is present).</para> <para>If a
DeviceTree is embedded in the <literal>.dtb</literal> section, it replaces an existing DeviceTree in the
corresponding EFI configuration table. systemd-stub will ask the firmware via the
<literal>EFI_DT_FIXUP_PROTOCOL</literal> for hardware specific fixups to the DeviceTree.</para> <para>The
contents of 11 of these 12 sections are measured into TPM PCR 11. It is otherwise not used and thus the
result can be pre-calculated without too much effort. The <literal>.pcrsig</literal> section is not
included in this PCR measurement, since it is supposed to contain signatures for the output of the
corresponding EFI configuration table. <command>systemd-stub</command> will ask the firmware via the
<literal>EFI_DT_FIXUP_PROTOCOL</literal> for hardware specific fixups to the DeviceTree.</para>
<para>The contents of 11 of these 12 sections are measured into TPM PCR 11. It is otherwise not used and
thus the result can be pre-calculated without too much effort. The <literal>.pcrsig</literal> section is
not included in this PCR measurement, since it is supposed to contain signatures for the output of the
measurement operation, and thus cannot also be input to it. If an UKI contains multiple profiles, only
the PE sections of the selected profile (and those of the base profile, except if overridden) are
measured.</para>
@@ -287,19 +288,20 @@
<literal>rd.systemd.unit=storagetm.target</literal>.</para>
<para>A single UKI may support multiple profiles by means of the special <literal>.profile</literal> PE
section. This section acts as separator between the PE sections of the individual
profiles. <literal>.profile</literal> PE sections hence may appear multiple times in a single UKI, and
the other PE sections listed above may appear multiple times too, if <literal>.profile</literal> are
used, but only once before the first <literal>.profile</literal> section, once between each subsequent
pair, and once after the last appearance of <literal>.profile</literal>. The sections listed before the
first <literal>.profile</literal> are considered the "base" profile of the UKI. Each
<literal>.profile</literal> section then introduces a new profile, which are numbered starting from
zero. The PE sections following each <literal>.profile</literal> are specific to that profile. When
booting into a specific profile the base section's profiles are used in combination with the specific
profile's sections: if the same section is defined in both, the per-profile section overrides the base
profile's version, otherwise the per-profile sections is used together with the base profile
sections.</para> <para>A UKI that contains no <literal>.profile</literal> is consider equivalent to one
that just contains a single <literal>.profile</literal>, as having only a single profile @0.</para>
section. This section acts as separator between the PE sections of the individual profiles.
<literal>.profile</literal> PE sections hence may appear multiple times in a single UKI, and the other PE
sections listed above may appear multiple times too, if <literal>.profile</literal> are used, but only
once before the first <literal>.profile</literal> section, once between each subsequent pair, and once
after the last appearance of <literal>.profile</literal>. The sections listed before the first
<literal>.profile</literal> are considered the "base" profile of the UKI. Each
<literal>.profile</literal> section then introduces a new profile, which are numbered starting from zero.
The PE sections following each <literal>.profile</literal> are specific to that profile. When booting
into a specific profile, the base section's profiles are used in combination with the specific profile's
sections: if the same section is defined in both, the per-profile section overrides the base profile's
version, otherwise the base profile sections are used.</para>
<para>A UKI that contains no <literal>.profile</literal> is consider equivalent to one that just contains
a single <literal>.profile</literal>, as having only a single profile <literal>@0</literal>.</para>
<para>Here's a simple example for a multi-profile UKI's sections, inspired by the setup suggested above:</para>

30
man/systemd-timesyncd.service.xml
View File

@@ -30,16 +30,16 @@
<refsect1>
<title>Description</title>
<para><filename>systemd-timesyncd</filename> is a system service that may be used to synchronize the
local system clock with a remote Network Time Protocol (NTP) server. It also saves the local time to disk
every time the clock has been synchronized and uses this to possibly advance the system realtime clock on
subsequent reboots to ensure it (roughly) monotonically advances even if the system lacks a
<para><filename>systemd-timesyncd.service</filename> is a system service that may be used to synchronize
the local system clock with a remote Network Time Protocol (NTP) server. It also saves the local time to
disk every time the clock has been synchronized and uses this to possibly advance the system realtime
clock on subsequent reboots to ensure it (roughly) monotonically advances even if the system lacks a
battery-buffered RTC chip.</para>
<para>The <filename>systemd-timesyncd</filename> service implements SNTP only. This minimalistic service
will step the system clock for large offsets or slowly adjust it for smaller deltas. Complex use cases
that require full NTP support (and where SNTP is not sufficient) are not covered by
<filename>systemd-timesyncd</filename>.</para>
<para>The <filename>systemd-timesyncd.service</filename> service implements SNTP only. This minimalistic
service will step the system clock for large offsets or slowly adjust it for smaller deltas. Complex use
cases that require full NTP support (and where SNTP is not sufficient) are not covered by
<filename>systemd-timesyncd.service</filename>.</para>
<para>The NTP servers contacted are determined from the global settings in
<citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, the
@@ -56,8 +56,8 @@
<command>timesync-status</command> or <command>show-timesync</command> command can be used to show the
current status of this service.</para>
<para><filename>systemd-timesyncd</filename> initialization delays the start of units that are ordered
after <filename>time-set.target</filename> (see
<para>Initialization of <filename>systemd-timesyncd.service</filename> delays the start of units that are
ordered after <filename>time-set.target</filename> (see
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
details) until the local time has been updated from <filename>/var/lib/systemd/timesync/clock</filename>
(see below) in order to make it roughly monotonic. It does not delay other units until synchronization
@@ -67,13 +67,13 @@
<filename>time-sync.target</filename> until synchronization to an accurate reference clock is
reached.</para>
<para><filename>systemd</filename> and <filename>systemd-timesyncd</filename> advance the system clock to
<para><command>systemd</command> and <command>systemd-timesyncd</command> advance the system clock to
the "epoch" (the lowest date above which the system clock time is assumed to be set correctly). See
"System clock epoch" section in
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details.
<filename>systemd</filename> will set the clock when initializing, but
<command>systemd</command> will set the clock when initializing, but
<filename>/var/lib/systemd/timesync/clock</filename> might not yet be available at that point.
<filename>systemd-timesyncd</filename> will advance the clock when it is started and notices that the
<command>systemd-timesyncd</command> will advance the clock when it is started and notices that the
system clock is before the modification time of <filename>/var/lib/systemd/timesync/clock</filename>.
</para>
</refsect1>
@@ -104,8 +104,8 @@
<listitem>
<para>A file that is touched on each successful synchronization to assist
<filename>systemd-time-wait-sync</filename> and other applications in detecting synchronization to
an accurate reference clock.</para>
<citerefentry><refentrytitle>systemd-time-wait-sync.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service and other applications in detecting synchronization to an accurate reference clock.</para>
<xi:include href="version-info.xml" xpointer="v239"/>
</listitem>

2
man/systemd.exec.xml
View File

@@ -3793,7 +3793,7 @@ StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZX
<literal>my.renamed.xxx</literal> to the service.</para>
<para>If <varname>ImportCredential=</varname> is specified multiple times and multiple credentials
end up with the same name after renaming, the first one is kept and later ones are dropped.</para>.
end up with the same name after renaming, the first one is kept and later ones are dropped.</para>
<para>When multiple credentials of the same name are found, credentials found by
<varname>LoadCredential=</varname> and <varname>LoadCredentialEncrypted=</varname> take priority over

3
man/systemd.link.xml
View File

@@ -396,7 +396,8 @@
<para>This setting is useful to configure the <literal>ID_NET_MANAGED_BY=</literal> property which
declares which network management service shall manage the interface, which is respected by
<command>systemd-networkd</command> and others. Use
<citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
and others. Use
<programlisting>Property=ID_NET_MANAGED_BY=io.systemd.Network</programlisting>
to declare explicitly that <command>systemd-networkd</command> shall manage the interface, or set
the property to something else to declare explicitly it shall not do so. See

12
man/systemd.net-naming-scheme.xml
View File

@@ -94,7 +94,8 @@
</tgroup>
</table>
<para>The udev <command>net_id</command> builtin exports the following udev device properties:</para>
<para>The <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>
<command>net_id</command> builtin exports the following device properties:</para>
<variablelist>
<varlistentry>
@@ -560,10 +561,11 @@
<refsect1>
<title>Limiting the use of specific sysfs attributes</title>
<para>When creating names for network cards, some naming schemes use data from sysfs populated
by the kernel. This means that although a specific naming scheme in udev is picked,
the network card's name can still change when a new kernel version adds a new sysfs attribute.
For example if kernel starts setting the <constant>phys_port_name</constant>, udev will append the
<para>When creating names for network cards, some naming schemes use data from sysfs populated by the
kernel. This means that although a specific naming scheme in
<citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> is picked, the
network card's name can still change when a new kernel version adds a new sysfs attribute. For example,
if kernel starts setting the <constant>phys_port_name</constant>, <command>udev</command> will append the
"<constant>n</constant><replaceable>phys_port_name</replaceable>" suffix to the device name.</para>
<variablelist>

2
man/systemd.netdev.xml
View File

@@ -1112,7 +1112,7 @@ Ports=eth2</programlisting>
<varlistentry>
<term><varname>MinSourcePort=</varname></term>
<listitem>
<para>Specifies the lowest value of the UDP tunnel source UDP port (in range 1…65535).
<para>Specifies the lowest value of the UDP tunnel source port (in range 1…65535).
Defaults to unset.</para>
<xi:include href="version-info.xml" xpointer="v257"/>

15
man/systemd.network.xml
View File

@@ -89,10 +89,11 @@
<para>Note that any network interfaces that have the <varname>ID_NET_MANAGED_BY=</varname> udev property
set will never be matched by any .network files – unless the property's value is the string
<literal>io.systemd.Network</literal> – even if the [Match] section would otherwise match. This may be
used to exclude specific network interfaces from <command>systemd-networkd</command>'s management, while
keeping the [Match] section generic. The <varname>ID_NET_MANAGED_BY=</varname> property thus declares
intended <emphasis>ownership</emphasis> of the device, and permits ensuring that concurrent network
management implementations do not compete for management of specific devices.</para>
used to exclude specific network interfaces from
<citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
management, while keeping the [Match] section generic. The <varname>ID_NET_MANAGED_BY=</varname> property
thus declares intended <emphasis>ownership</emphasis> of the device, and permits ensuring that concurrent
network management implementations do not compete for management of specific devices.</para>
<para>A network file is said to match a network interface if all matches specified by the [Match]
section are satisfied. When a network file does not contain valid settings in [Match] section, then
@@ -1802,8 +1803,8 @@ NFTSet=prefix:netdev:filter:eth_ipv4_prefix</programlisting>
<varlistentry>
<term><varname>GoTo=</varname></term>
<listitem>
<para>Specifies the target priority used by <literal>goto</literal> type of rule. Takes an integer
in the range 1…4294967295. This must be larger than the priority of this rule specified in
<para>Specifies the target priority used by the <literal>goto</literal> type of rule. Takes an
integer in the range 1…4294967295. This must be larger than the priority of the rule specified in
<varname>Priority=</varname>. When specified, <varname>Type=goto</varname> is implied. This is
mandatory when <varname>Type=goto</varname>.</para>
@@ -2973,7 +2974,7 @@ NFTSet=prefix:netdev:filter:eth_ipv4_prefix</programlisting>
prefix length after <literal>/</literal>. DHCP offers from servers in the list are accepted.
</para>
<para>Note that this filters only DHCP offers, so the filtering might not work when
<varname>RapidCommit=</varname> is enabled. See also <varname>RapidCommit=</varname> in the above.
<varname>RapidCommit=</varname> is enabled. See also <varname>RapidCommit=</varname> above.
</para>
<xi:include href="version-info.xml" xpointer="v246"/>

10
man/sysupdate.d.xml
View File

@@ -58,7 +58,8 @@
combined, synchronized operation, so that only a combined update of all three together constitutes a
complete update.
We'll call such a collection of transfers a target.
<command>systemd-sysupdate</command> always operates on a single target.</para>
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
always operates on a single target.</para>
<para>Transfers may be grouped together into sets that can be individually enabled or disabled by the
system administrator, called "Optional Features":
@@ -522,7 +523,9 @@
XML file. This may be used by software centers (such as GNOME Software or KDE Discover) to present
rich metadata about the resources being updated. This includes display names, changelogs, icons,
and more. The specified catalog must include <ulink url="https://systemd.io/APPSTREAM_BUNDLE">special metadata</ulink>
to be correctly associated with <command>systemd-sysupdate</command> by the software centers.</para>
to be correctly associated with
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
by the software centers.</para>
<para>This setting supports specifier expansion. See below for details on supported
specifiers.</para>
@@ -688,7 +691,8 @@
<para>If set to <constant>explicit</constant>, the specified <varname>Path=</varname> will be
resolved relative to the directory specified with <option>--transfer-source=</option> when invoking
<command>systemd-sysupdate</command>.</para>
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
<para>The values <constant>esp</constant>, <constant>xbootldr</constant>, and
<constant>boot</constant> are only supported when <varname>Type=</varname> is set to

8
man/sysupdate.features.xml
View File

@@ -43,7 +43,9 @@
downloading updates, when vacuuming, and in all other situations.
In effect, transfers belonging to a feature will always be updated in lock-step with the rest of their
target.
This is the primary difference an Optional Feature and a <command>systemd-sysupdate</command> component.
This is the primary difference an Optional Feature and a
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
component.
When a feature is disabled, its transfers will not be considered when checking for and downloading updates,
but <command>systemd-sysupdate</command> will still consider them while vacuuming and in other situations
where it needs to determine ownership over previously downloaded system resources.
@@ -54,8 +56,8 @@
defined below.
Transfers can declare that they belong to a feature via the <varname>Features=</varname> setting.
Feature definitions support drop-in files, which are most commonly used to override the
<varname>Enabled=</varname> setting).
They can also be masked out to hide the availability of the feature entirely.</para>
<varname>Enabled=</varname> setting.
They can also be masked to hide the availability of the feature entirely.</para>
<para>Each <filename>*.feature</filename> file contains one section: [Feature].</para>
</refsect1>

12
man/tmpfiles.d.xml
View File

@@ -508,8 +508,9 @@ r! /tmp/.X[0-9]*-lock</programlisting>
<option>--boot</option>.</para>
<para>If the minus sign (<literal>-</literal>) is used, this line failing to run successfully during
create (and only create) will not cause the execution of <command>systemd-tmpfiles</command> to return
an error.</para>
create (and only create) will not cause the execution of
<citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>
to return an error.</para>
<para>For example:
<programlisting># Modify sysfs but do not fail if we are in a container with a read-only /proc
@@ -877,9 +878,10 @@ e! /var/cache/krb5rcache - - - 0
</programlisting>
<para>By passing this line to QEMU, the public key of the current user will be encoded in base64, added
to a tmpfiles.d line that tells <command>systemd-tmpfiles</command> to decode it into
<filename>/root/.ssh/authorized_keys</filename>, encode that line itself in base64 and pass it as a
Credential that will be picked up by systemd from SMBIOS on boot.
to a tmpfiles.d line that tells
<citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry> to
decode it into <filename>/root/.ssh/authorized_keys</filename>, encode that line itself in base64 and
pass it as a Credential that will be picked up by systemd from SMBIOS on boot.
</para>
</example>
</refsect1>