From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Date: Wed, 11 Jan 2023 15:45:59 +0000 (+0100)
Subject: man: fix issues reported by the manpage-l10n project
X-Git-Tag: v253-rc1~125^2~1
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8b9f092112ce097dd5c72a58a092c4176458889c;p=thirdparty%2Fsystemd.git

man: fix issues reported by the manpage-l10n project

Fixes #25780.

> Man page: crypttab.5
> Issue 1:  Missing fullstop
> Issue 2:  I<cipher=>, I<hash=>, I<size=> → B<cipher=>, B<hash=>, B<size=>
>
> "Force LUKS mode\\&. When this mode is used, the following options are "
> "ignored since they are provided by the LUKS header on the device: "
> "I<cipher=>, I<hash=>, I<size=>"

Seems OK to me. The full stop is there and has been for at least a few years. And we use <option> for the markup, which is appropriate here.

> Man page: crypttab.5
> Issue 1:  Missing fullstop
> Issue 2:  I<cipher=>, I<hash=>, I<keyfile-offset=>, I<keyfile-size=>, I<size=> → B<cipher=>, B<hash=>, B<keyfile-offset=>, B<keyfile-size=>, B<size=>
>
> "Use TrueCrypt encryption mode\\&. When this mode is used, the following "
> "options are ignored since they are provided by the TrueCrypt header on the "
> "device or do not apply: I<cipher=>, I<hash=>, I<keyfile-offset=>, I<keyfile-"
> "size=>, I<size=>"

Same.

> Man page: journalctl.1
> Issue 1:  make be → may be

Fixed.

> Issue 2:  below\\&. → below:

Fixed.

> Man page: journalctl.1
> Issue:    Colon at the end?
>
> "The following commands are understood\\&. If none is specified the default "
> "is to display journal records\\&."
> msgstr ""
> "Die folgenden Befehle werden verstanden\\&. Falls keiner festgelegt ist, ist "
> "die Anzeige von Journal-Datensätzen die Vorgabe\\&."

This is a bit awkward, but I'm not sure how to fix it.

> Man page: kernel-install.8
> Issue:    methods a fallback → methods fallback

It was correct, but I added a comma to make the sense clearer.

> Man page: loader.conf.5
> Issue 1:  secure boot variables → Secure Boot variables
> Issue 2:  one → one for (multiple times)
>
> "Supported secure boot variables are one database for authorized images, one "
> "key exchange key (KEK) and one platform key (PK)\\&. For more information, "
> "refer to the \\m[blue]B<UEFI specification>\\m[]\\&\\s-2\\u[2]\\d\\s+2, "
> "under Secure Boot and Driver Signing\\&. Another resource that describe the "
> "interplay of the different variables is the \\m[blue]B<EDK2 "
> "documentation>\\m[]\\&\\s-2\\u[3]\\d\\s+2\\&."

"one of" would sound strange. "One this and one that" is OK.

> Man page: loader.conf.5
> Issue:    systemd-boot → B<systemd-boot>(7)

Fixed.

> Man page: logind.conf.5
> Issue:    systemd-logind → B<systemd-logind>(8)

We use <filename>systemd-logind</> on subsequent references… I think that's good enough.

> Man page: nss-myhostname.8
> Issue:    B<getent> → B<getent>(1)

Fixed.

> Man page: nss-resolve.8
> Issue:    B<systemd-resolved> → B<systemd-resolved>(8)

The first reference does this, subsequent are shorter.

> Man page: os-release.5
> Issue:    Portable Services → Portable Services Documentation?

Updated.

> Man page: pam_systemd_home.8
> Issue:    auth and account use "reason", while session and password do not?

Reworded.

> Man page: portablectl.1
> Issue:    In systemd-portabled.service(8): Portable Services Documentation

Updated.

> Man page: repart.d.5
> Issue:    The partition → the partition

Fixed.

> Man page: repart.d.5
> Issue:    B<systemd-repart> → B<systemd-repart>(8)

The first reference does this. I also change this one, because it's pretty far down in the text.

> Man page: systemd.1
> Issue:    kernel command line twice?
>
> "Takes a boolean argument\\&. If false disables importing credentials from "
> "the kernel command line, qemu_fw_cfg subsystem or the kernel command line\\&."

Apparently this was fixed already.

> Man page: systemd-boot.7
> Issue:    enrollement → enrollment

Fixed.

> Man page: systemd-cryptenroll.1
> Issue:    multiple cases: any specified → the specified

Reworded.

> Man page: systemd-cryptenroll.1
> Issue:    If this this → If this

Fixed tree-wide.

> Man page: systemd-cryptsetup-generator.8
> Issue:    and the initrd → and in the initrd

"Is honoured by the initrd" is OK, because we often speak about the initrd as a single unit. But in the same paragraph we also used "in the initrd", which makes the other use look sloppy. I changed it to "in the initrd" everywhere in that file.

> Man page: systemd.directives.7
> Issue:    Why are these two quoted (but not others)?
>
> "B<\\*(Aqh\\*(Aq>"
>
> B<\\*(Aqs\\*(Aq>"
>
> "B<\\*(Aqy\\*(Aq>"

This is autogenerated from files… We use slightly different markup in different files, and it's just too hard to make it consistent. We gave up on this.

> Man page: systemd.exec.5
> Issue 1:  B<at>(1p) → B<at>(1)
> Issue 2:  B<crontab>(1p) → B<crontab>(1)

Fixed.

> Man page: systemd.exec.5
> Issue:    B<select()> → B<select>(2)

Fixed.

> Man page: systemd.exec.5
> Issue:   qemu → B<qemu>(1)

The man page doesn't seem to be in any of the canonical places on the web.
I added a link to online docs.

> Man page: systemd.exec.5
> Issue:    variable → variables

Seems to be fixed already.

> Man page: systemd-integritysetup-generator.8
> Issue:    systemd-integritysetup-generator → B<systemd-integritysetup-generator>

I changed <filename> to <command>.

> Man page: systemd-integritysetup-generator.8
> Issue:    superfluous comma at the end

Already fixed.

> Man page: systemd-measure.1
> Issue:    (see B<--pcr-bank=>) below → (see B<--pcr-bank=> below)

Reworded.

> Man page: systemd-measure.1
> Issue:    =PATH> → =>I<PATH>

Fixed.

> Man page: systemd-measure.1.po
> Issue:    B<--bank=DIGEST> → B<--bank=>I<DIGEST>

Fixed.

> Man page: systemd.netdev.5
> Issue:    os the → on the

Appears to have been fixed already.

> Man page: systemd.netdev.5
> Issue:    Onboard → On-board (as in previous string)

Updated.

> Man page: systemd.network.5
> Issue:    B<systemd-networkd> -> B<systemd-networkd>(8)

First reference does this, subsequent do not.

> Man page: systemd.network.5
> Issue:    B<netlabelctl> → B<netlabelctl>(8)

First reference does this, subsequent do not.

> Man page: systemd.network.5
> Issue:    Missing verb (aquired? configured?) in the half sentence starting with "or by a "

I dropped the comma.

> Man page: systemd-nspawn.1
> Issue:    All host users outside of that range → All other host users

Reworded.

> # FIXME no effect → no effect\\&.
> #. type: Plain text
> #: archlinux debian-unstable fedora-rawhide mageia-cauldron opensuse-tumbleweed
> msgid ""
> "Whichever ID mapping option is used, the same mapping will be used for users "
> "and groups IDs\\&. If B<rootidmap> is used, the group owning the bind "
> "mounted directory will have no effect"

A period is added. Not sure if there's some other issue.

> Man page: systemd-oomd.service.8
> Issue:    B<systemd> → B<systemd>(1)

Done.

> Man page: systemd.path.5
> Issue 1:  B<systemd.exec>(1) → B<systemd.exec>(5)
> Issue 2:  This section does not (yet?) exist

Fixed.

> Man page: systemd-pcrphase.service.8
> Issue 1:  indicate phases into TPM2 PCR 11 ??
> Issue 2: Colon at the end of the paragraph?

Fixed.

> Man page: systemd-pcrphase.service.8
> Issue:    final boot phase → final shutdown phase?

Updated.

> Man page: systemd-pcrphase.service.8
> Issue:    for the the → for the

Fixed tree-wide.

> Man page: systemd-portabled.service.8
> Issue:    In systemd-portabled.service(8): Portable Services Documentation

Updated.

> Man page: systemd-pstore.service.8
> Issue:    Here and the following paragraphs: . → \\&. // Upstream: What does this comment mean? // You normally write \\&. for a full dot (full stop etc.); here you write only "." (i.e. a plain dot).
>
> "and we look up \"localhost\", nss-dns will send the following queries to "
> "systemd-resolved listening on 127.0.0.53:53: first \"localhost.foobar.com\", "
> "then \"localhost.barbar.com\", and finally \"localhost\". If (hopefully) the "
> "first two queries fail, systemd-resolved will synthesize an answer for the "
> "third query."

Looks all OK to me.

> Man page: systemd.resource-control.5
> Issue:    Missing closing bracket after link to Control Groups version 1

Fixed.

> Man page: systemd-sysext.8
> Issue:    In systemd-portabled.service(8): Portable Services Documentation

Updated.

> Man page: systemd.timer.5
> Issue 1:  B<systemd.exec>(1) → B<systemd.exec>(5)
> Issue 2:  This section does not (yet?) exist

Fixed.

> Man page: systemd.unit.5
> Issue:    that is → that are

Fixed.

> Man page: systemd-veritysetup-generator.8
> Issue:    systemd-veritysetup-generator → B<systemd-veritysetup-generator>
>
 > "systemd-veritysetup-generator implements B<systemd.generator>(7)\\&."
>
> "systemd-veritysetup-generator understands the following kernel command line "
> "parameters:"

Updated.

> Man page: systemd-volatile-root.service.8
> Issue:    initrdyes → Initrd

Fixed.

> Man page: sysupdate.d.5
> Issue:    : → \\&. (As above in TRANSFER)

Updated.

> Man page: sysupdate.d.5
> Issue:    some → certain

Updated.

> Man page: sysupdate.d.5
> Issue 1:  i\\&.e\\& → I\\&.e\\&

Fixed.

> Issue 2:  the image → the system

"image" seems correct.

> Man page: tmpfiles.d.5
> Issue:    systemd-tmpfiles → B<systemd-tmpfiles>(8)

Updated.
---

diff --git a/man/bootctl.xml b/man/bootctl.xml
index f03f836746f..c9edf77b373 100644
--- a/man/bootctl.xml
+++ b/man/bootctl.xml
@@ -429,7 +429,7 @@
       <programlisting>$ <command>bootctl status</command>
 System:
      Firmware: UEFI 2.40 (<replaceable>firmware-version</replaceable>)  ← firmware vendor and version
-  Secure Boot: disabled (setup)              ← secure boot status
+  Secure Boot: disabled (setup)              ← Secure Boot status
  TPM2 Support: yes
  Boot into FW: supported                     ← does the firmware support booting into itself
 
diff --git a/man/journalctl.xml b/man/journalctl.xml
index d9ee51b302a..109797776e6 100644
--- a/man/journalctl.xml
+++ b/man/journalctl.xml
@@ -18,7 +18,7 @@
 
   <refnamediv>
     <refname>journalctl</refname>
-    <refpurpose>Print log entries from the the systemd journal</refpurpose>
+    <refpurpose>Print log entries from the systemd journal</refpurpose>
   </refnamediv>
 
   <refsynopsisdiv>
@@ -664,7 +664,8 @@
   <refsect1>
     <title>Forward Secure Sealing (FSS) Options</title>
 
-    <para>The following options make be used together with the <option>--setup-keys</option> command, see below.</para>
+    <para>The following options may be used together with the <option>--setup-keys</option> command described
+    below:</para>
 
     <variablelist>
       <varlistentry>
diff --git a/man/kernel-install.xml b/man/kernel-install.xml
index f3fdc961f4d..e50aeee9499 100644
--- a/man/kernel-install.xml
+++ b/man/kernel-install.xml
@@ -198,8 +198,8 @@
 
       <para><varname>$KERNEL_INSTALL_MACHINE_ID</varname> is set for the plugins to the desired machine-id to
       use. It's always a 128-bit ID. Normally it's read from <filename>/etc/machine-id</filename>, but it can
-      also be overridden via <varname>$MACHINE_ID</varname> (see below).  If not specified via these methods a
-      fallback value will generated by <command>kernel-install</command>, and used only for a single
+      also be overridden via <varname>$MACHINE_ID</varname> (see below). If not specified via these methods,
+      a fallback value will generated by <command>kernel-install</command> and used only for a single
       invocation.</para>
 
       <para><varname>$KERNEL_INSTALL_ENTRY_TOKEN</varname> is set for the plugins to the desired entry
diff --git a/man/loader.conf.xml b/man/loader.conf.xml
index 245f4c45366..80122177e50 100644
--- a/man/loader.conf.xml
+++ b/man/loader.conf.xml
@@ -228,19 +228,22 @@
         <listitem><para>Danger: this feature might soft-brick your device if used improperly.</para>
 
         <para>Takes one of <literal>off</literal>, <literal>manual</literal> or <literal>force</literal>.
-        Controls the enrollment of secure boot keys. If set to <literal>off</literal>, no action whatsoever
+        Controls the enrollment of Secure Boot keys. If set to <literal>off</literal>, no action whatsoever
         is taken. If set to <literal>manual</literal> (the default) and the UEFI firmware is in setup-mode
         then entries to manually enroll Secure Boot variables are created in the boot menu. If set to
         <literal>force</literal>, in addition, if a directory named <filename>/loader/keys/auto/</filename>
         exists on the ESP then the keys in that directory are enrolled automatically.</para>
 
-        <para>The different sets of variables can be set up under <filename>/loader/keys/<replaceable>NAME</replaceable></filename>
-        where <replaceable>NAME</replaceable> is the name that is going to be used as the name of the entry.
-        This allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime.</para>
+        <para>The different sets of variables can be set up under
+        <filename>/loader/keys/<replaceable>NAME</replaceable></filename> where
+        <replaceable>NAME</replaceable> is the name that is going to be used as the name of the entry. This
+        allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime.
+        </para>
 
-        <para>Supported secure boot variables are one database for authorized images, one key exchange key (KEK)
-        and one platform key (PK). For more information, refer to the <ulink url="https://uefi.org/specifications">UEFI specification</ulink>,
-        under Secure Boot and Driver Signing. Another resource that describe the interplay of the different variables is the
+        <para>Supported Secure Boot variables are one database for authorized images, one key exchange key
+        (KEK) and one platform key (PK). For more information, refer to the <ulink
+        url="https://uefi.org/specifications">UEFI specification</ulink>, under Secure Boot and Driver
+        Signing. Another resource that describe the interplay of the different variables is the
         <ulink url="https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/uefi_secure_boot">
         EDK2 documentation</ulink>.</para>
 
@@ -294,17 +297,17 @@ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
         <para>Work around BitLocker requiring a recovery key when the boot loader was
         updated (disabled by default).</para>
 
-        <para>Try to detect BitLocker encrypted drives along with an active TPM. If both are found
-        and Windows Boot Manager is selected in the boot menu, set the <literal>BootNext</literal>
-        EFI variable and restart the system. The firmware will then start Windows Boot Manager
-        directly, leaving the TPM PCRs in expected states so that Windows can unseal the encryption
-        key. This allows systemd-boot to be updated without having to provide the recovery key for
-        BitLocker drive unlocking.</para>
+        <para>Try to detect BitLocker encrypted drives along with an active TPM. If both are found and
+        Windows Boot Manager is selected in the boot menu, set the <literal>BootNext</literal> EFI variable
+        and restart the system. The firmware will then start Windows Boot Manager directly, leaving the TPM
+        PCRs in expected states so that Windows can unseal the encryption key. This allows
+        <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> to
+        be updated without having to provide the recovery key for BitLocker drive unlocking.</para>
 
         <para>Note that the PCRs that Windows uses can be configured with the
         <literal>Configure TPM platform validation profile for native UEFI firmware configurations</literal>
         group policy under <literal>Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption</literal>.
-        When secure boot is enabled, changing this to PCRs <literal>0,2,7,11</literal> should be safe.
+        When Secure Boot is enabled, changing this to PCRs <literal>0,2,7,11</literal> should be safe.
         The TPM key protector needs to be removed and then added back for the PCRs on an already
         encrypted drive to change. If PCR 4 is not measured, this setting can be disabled to speed
         up booting into Windows.</para></listitem>
diff --git a/man/nss-myhostname.xml b/man/nss-myhostname.xml
index b6544cf65d5..19e7aa237ac 100644
--- a/man/nss-myhostname.xml
+++ b/man/nss-myhostname.xml
@@ -109,7 +109,9 @@ rpc:            db files
 
 netgroup:       nis</programlisting>
 
-    <para>To test, use <command>glibc</command>'s <command>getent</command> tool:</para>
+    <para>To test, use <command>glibc</command>'s
+    <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool:</para>
 
     <programlisting>$ getent ahosts `hostname`
 ::1       STREAM omega
diff --git a/man/os-release.xml b/man/os-release.xml
index 7325f840b9c..113ef9fc18a 100644
--- a/man/os-release.xml
+++ b/man/os-release.xml
@@ -451,12 +451,12 @@
         <varlistentry>
           <term><varname>PORTABLE_PREFIXES=</varname></term>
           <listitem><para>Takes a space-separated list of one or more valid prefix match strings for the
-          <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> logic. This field
-          serves two purposes: it is informational, identifying portable service images as such (and thus
-          allowing them to be distinguished from other OS images, such as bootable system images). It is also
-          used when a portable service image is attached: the specified or implied portable service prefix is
-          checked against the list specified here, to enforce restrictions how images may be attached to a
-          system.</para></listitem>
+          <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink> logic.
+          This field serves two purposes: it is informational, identifying portable service images as such
+          (and thus allowing them to be distinguished from other OS images, such as bootable system images).
+          It is also used when a portable service image is attached: the specified or implied portable
+          service prefix is checked against the list specified here, to enforce restrictions how images may
+          be attached to a system.</para></listitem>
         </varlistentry>
       </variablelist>
     </refsect2>
diff --git a/man/pam_systemd_home.xml b/man/pam_systemd_home.xml
index 9fa0e0a7e7c..9d07aa96c76 100644
--- a/man/pam_systemd_home.xml
+++ b/man/pam_systemd_home.xml
@@ -97,13 +97,14 @@
   <refsect1>
     <title>Module Types Provided</title>
 
-    <para>The module implements all four PAM operations: <option>auth</option> (reason: to allow
-    authentication using the encrypted data), <option>account</option> (reason: users with
+    <para>The module implements all four PAM operations: <option>auth</option> (to allow authentication using
+    the encrypted data), <option>account</option> (because users with
     <filename>systemd-homed.service</filename> user accounts are described in a <ulink
     url="https://systemd.io/USER_RECORD/">JSON user record</ulink> and may be configured in more detail than
-    in the traditional Linux user database), <option>session</option> (user sessions must be tracked in order
-    to implement automatic release when the last session of the user is gone), <option>password</option> (to
-    change the encryption password — also used for user authentication — through PAM).</para>
+    in the traditional Linux user database), <option>session</option> (because user sessions must be tracked
+    in order to implement automatic release when the last session of the user is gone),
+    <option>password</option> (to change the encryption password — also used for user authentication —
+    through PAM).</para>
   </refsect1>
 
   <refsect1>
diff --git a/man/portablectl.xml b/man/portablectl.xml
index 963361e28cb..162db7658a6 100644
--- a/man/portablectl.xml
+++ b/man/portablectl.xml
@@ -48,7 +48,7 @@
     and transfer them as a whole between systems. When these images are attached the local system the contained units
     may run in most ways like regular system-provided units, either with full privileges or inside strict sandboxing,
     depending on the selected configuration. For more details, see
-    <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>.</para>
+    <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>.</para>
 
     <para>Specifically portable service images may be of the following kind:</para>
 
@@ -367,7 +367,7 @@
         <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
         Images can be block images, btrfs subvolumes or directories. For more information on portable
         services with extensions, see the <literal>Extension Images</literal> paragraph on
-        <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>.
+        <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>.
         </para>
 
         <para>Note that the same extensions have to be specified, in the same order, when attaching
diff --git a/man/repart.d.xml b/man/repart.d.xml
index 1da38a4e91b..846e1984e59 100644
--- a/man/repart.d.xml
+++ b/man/repart.d.xml
@@ -427,9 +427,11 @@
 
         <para>This option cannot be combined with <varname>CopyBlocks=</varname>.</para>
 
-        <para>When <command>systemd-repart</command> is invoked with the <option>--image=</option> or
-        <option>--root=</option> command line switches the source paths specified are taken relative to the
-        specified root directory or disk image root.</para></listitem>
+        <para>When
+        <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        is invoked with the <option>--image=</option> or <option>--root=</option> command line switches the
+        source paths specified are taken relative to the specified root directory or disk image root.
+        </para></listitem>
       </varlistentry>
 
       <varlistentry>
@@ -492,7 +494,7 @@
         to <literal>off</literal> or <literal>data</literal>, the partition is populated with content as
         specified by <varname>CopyBlocks=</varname> or <varname>CopyFiles=</varname>. If set to
         <literal>hash</literal>, the partition will be populated with verity hashes from the matching verity
-        data partition. If set to <literal>signature</literal>, The partition will be populated with a JSON
+        data partition. If set to <literal>signature</literal>, the partition will be populated with a JSON
         object containing a signature of the verity root hash of the matching verity hash partition.</para>
 
         <para>A matching verity partition is a partition with the same verity match key (as configured with
diff --git a/man/systemd-boot.xml b/man/systemd-boot.xml
index bfc93b3eeb8..64ded052e16 100644
--- a/man/systemd-boot.xml
+++ b/man/systemd-boot.xml
@@ -56,7 +56,7 @@
 
       <listitem><para>A reboot into the UEFI firmware setup option, if supported by the firmware.</para></listitem>
 
-      <listitem><para>Secure boot variables enrollement if the UEFI firmware is in setup-mode and files are provided
+      <listitem><para>Secure Boot variables enrollment if the UEFI firmware is in setup-mode and files are provided
       on the ESP.</para></listitem>
     </itemizedlist>
 
@@ -95,7 +95,7 @@
       with a 'system token' stored in a persistent EFI variable and derives a random seed to use by the OS as
       entropy pool initialization, providing a full entropy pool during early boot.</para></listitem>
 
-      <listitem><para>The boot manager allows for secure boot variables to be enrolled if the UEFI firmware is
+      <listitem><para>The boot manager allows for Secure Boot variables to be enrolled if the UEFI firmware is
       in setup-mode. Additionally, variables can be automatically enrolled if configured.</para></listitem>
     </itemizedlist>
 
diff --git a/man/systemd-creds.xml b/man/systemd-creds.xml
index 003fbcd4635..49d78ee7fcc 100644
--- a/man/systemd-creds.xml
+++ b/man/systemd-creds.xml
@@ -359,7 +359,7 @@
         <listitem><para>Takes a path to a TPM2 PCR signature file as generated by the
         <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
         tool and that may be used to allow the <command>decrypt</command> command to decrypt credentials that
-        are bound to specific signed PCR values. If this this is not specified explicitly, and a credential
+        are bound to specific signed PCR values. If this is not specified explicitly, and a credential
         with a signed PCR policy is attempted to be decrypted, a suitable signature file
         <filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>,
         <filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this order) and
diff --git a/man/systemd-cryptenroll.xml b/man/systemd-cryptenroll.xml
index ad338cdcc5e..e4b03936a60 100644
--- a/man/systemd-cryptenroll.xml
+++ b/man/systemd-cryptenroll.xml
@@ -288,7 +288,7 @@
 
               <row>
                 <entry>7</entry>
-                <entry>Secure boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR.</entry>
+                <entry>Secure Boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR.</entry>
               </row>
 
               <!-- Grub measures all its commands and the kernel command line into PCR 8… -->
@@ -312,7 +312,7 @@
 
               <row>
                 <entry>12</entry>
-                <entry><citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any specified kernel command line into this PCR. <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any manually specified kernel command line (i.e. a kernel command line that overrides the one embedded in the unified PE image) and loaded credentials into this PCR. (Note that if <command>systemd-boot</command> and <command>systemd-stub</command> are used in combination the command line might be measured twice!)</entry>
+                <entry><citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the kernel command line into this PCR. <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any manually specified kernel command line (i.e. a kernel command line that overrides the one embedded in the unified PE image) and loaded credentials into this PCR. (Note that if <command>systemd-boot</command> and <command>systemd-stub</command> are used in combination the command line might be measured twice!)</entry>
               </row>
 
               <row>
@@ -382,7 +382,7 @@
         <para>The <option>--tpm2-signature=</option> option takes a path to a TPM2 PCR signature file
         as generated by the
         <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
-        tool. If this this is not specified explicitly a suitable signature file
+        tool. If this is not specified explicitly a suitable signature file
         <filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>,
         <filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this order) and
         used. If a signature file is specified or found it is used to verify if the volume can be unlocked
diff --git a/man/systemd-cryptsetup-generator.xml b/man/systemd-cryptsetup-generator.xml
index 5ba024a866b..feaf64bf752 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -63,7 +63,7 @@
         <literal>no</literal>, causes the generator to ignore any devices configured in
         <filename>/etc/crypttab</filename> (<varname>luks.uuid=</varname> will still work however).
         <varname>rd.luks.crypttab=</varname> is honored only in initrd while
-        <varname>luks.crypttab=</varname> is honored by both the main system and the initrd.
+        <varname>luks.crypttab=</varname> is honored by both the main system and in the initrd.
         </para></listitem>
       </varlistentry>
 
@@ -75,7 +75,7 @@
         part of the boot process as if it was listed in <filename>/etc/crypttab</filename>. This option may
         be specified more than once in order to set up multiple devices. <varname>rd.luks.uuid=</varname> is
         honored only in the initrd, while <varname>luks.uuid=</varname> is honored by both the main system
-        and the initrd.</para>
+        and in the initrd.</para>
 
         <para>If <filename>/etc/crypttab</filename> contains entries with the same UUID, then the name,
         keyfile and options specified there will be used. Otherwise, the device will have the name
@@ -101,7 +101,7 @@
         <manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para>
 
         <para><varname>rd.luks.name=</varname> is honored only in the initrd, while
-        <varname>luks.name=</varname> is honored by both the main system and the initrd.</para>
+        <varname>luks.name=</varname> is honored by both the main system and in the initrd.</para>
         </listitem>
       </varlistentry>
 
@@ -203,7 +203,7 @@
 
         <para><varname>rd.luks.options=</varname> is honored only by initial
         RAM disk (initrd) while <varname>luks.options=</varname> is
-        honored by both the main system and the initrd.</para>
+        honored by both the main system and in the initrd.</para>
         </listitem>
       </varlistentry>
     </variablelist>
diff --git a/man/systemd-integritysetup-generator.xml b/man/systemd-integritysetup-generator.xml
index 44248b2e801..3e788f1c986 100644
--- a/man/systemd-integritysetup-generator.xml
+++ b/man/systemd-integritysetup-generator.xml
@@ -27,8 +27,8 @@
   <refsect1>
     <title>Description</title>
 
-    <para><filename>systemd-integritysetup-generator</filename> is a generator that translates <filename>/etc/integritytab</filename> entries into
-    native systemd units early at boot. This will create
+    <para><command>systemd-integritysetup-generator</command> is a generator that translates
+    <filename>/etc/integritytab</filename> entries into native systemd units early at boot. This will create
     <citerefentry><refentrytitle>systemd-integritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
     units as necessary.</para>
 
diff --git a/man/systemd-measure.xml b/man/systemd-measure.xml
index 42871b0c771..4e010846e1d 100644
--- a/man/systemd-measure.xml
+++ b/man/systemd-measure.xml
@@ -78,12 +78,13 @@
         seen in TPM2 PCR register 11 after boot-up of a unified kernel image. Then, cryptographically sign
         the resulting values with the private/public key pair (RSA) configured via
         <option>--private-key=</option> and <option>--public-key=</option>. This will write a JSON object to
-        standard output that contains signatures for all specified PCR banks (see
-        <option>--pcr-bank=</option>) below, which may be used to unlock encrypted credentials (see
+        standard output that contains signatures for all specified PCR banks (see the
+        <option>--pcr-bank=</option> option below), which may be used to unlock encrypted credentials (see
         <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>) or
         LUKS volumes (see
-        <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>). This
-        allows binding secrets to a set of kernels for which such PCR 11 signatures can be provided.</para>
+        <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>).
+        This allows binding secrets to a set of kernels for which such PCR 11 signatures can be
+        provided.</para>
 
         <para>Note that a TPM2 device must be available for this signing to take place, even though the
         result is not tied to any TPM2 device or its state.</para></listitem>
@@ -98,13 +99,13 @@
 
     <variablelist>
       <varlistentry>
-        <term><option>--linux=PATH</option></term>
-        <term><option>--osrel=PATH</option></term>
-        <term><option>--cmdline=PATH</option></term>
-        <term><option>--initrd=PATH</option></term>
-        <term><option>--splash=PATH</option></term>
-        <term><option>--dtb=PATH</option></term>
-        <term><option>--pcrpkey=PATH</option></term>
+        <term><option>--linux=<replaceable>PATH</replaceable></option></term>
+        <term><option>--osrel=<replaceable>PATH</replaceable></option></term>
+        <term><option>--cmdline=<replaceable>PATH</replaceable></option></term>
+        <term><option>--initrd=<replaceable>PATH</replaceable></option></term>
+        <term><option>--splash=<replaceable>PATH</replaceable></option></term>
+        <term><option>--dtb=<replaceable>PATH</replaceable></option></term>
+        <term><option>--pcrpkey=<replaceable>PATH</replaceable></option></term>
 
         <listitem><para>When used with the <command>calculate</command> or <command>sign</command> verb,
         configures the files to read the unified kernel image components from. Each option corresponds with
@@ -122,7 +123,7 @@
       </varlistentry>
 
       <varlistentry>
-        <term><option>--bank=DIGEST</option></term>
+        <term><option>--bank=<replaceable>DIGEST</replaceable></option></term>
 
         <listitem><para>Controls the PCR banks to pre-calculate the PCR values for – in case
         <command>calculate</command> or <command>sign</command> is invoked –, or the banks to show in the
@@ -132,8 +133,8 @@
       </varlistentry>
 
       <varlistentry>
-        <term><option>--private-key=PATH</option></term>
-        <term><option>--public-key=PATH</option></term>
+        <term><option>--private-key=<replaceable>PATH</replaceable></option></term>
+        <term><option>--public-key=<replaceable>PATH</replaceable></option></term>
 
         <listitem><para>These switches take paths to a pair of PEM encoded RSA key files, for use with
         the <command>sign</command> command.</para>
diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index ec308927df6..be2c3882d71 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -1374,7 +1374,7 @@ After=sys-subsystem-net-devices-ens1.device</programlisting>
         <itemizedlist>
           <listitem><para>If <option>noidmap</option> is used, any user <option>z</option> in the range
           <option>0 … y</option> seen from inside of the container is mapped to <option>x + z</option> in the
-          <option>x … x + y</option> range on the host. All host users outside of that range are mapped to
+          <option>x … x + y</option> range on the host. Other host users are mapped to
           <option>nobody</option> inside the container.</para></listitem>
           <listitem><para>If <option>idmap</option> is used, any user <option>z</option> in the UID range
           <option>0 … y</option> as seen from inside the container is mapped to the same <option>z</option>
diff --git a/man/systemd-oomd.service.xml b/man/systemd-oomd.service.xml
index dc02abd307e..45c791b8311 100644
--- a/man/systemd-oomd.service.xml
+++ b/man/systemd-oomd.service.xml
@@ -36,7 +36,8 @@
     <para>You can enable monitoring and actions on units by setting <varname>ManagedOOMSwap=</varname> and
     <varname>ManagedOOMMemoryPressure=</varname> in the unit configuration, see
     <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
-    <command>systemd-oomd</command> retrieves information about such units from <command>systemd</command>
+    <command>systemd-oomd</command> retrieves information about such units from
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
     when it starts and watches for subsequent changes.</para>
 
     <para>Cgroups of units with <varname>ManagedOOMSwap=</varname> or
diff --git a/man/systemd-pcrphase.service.xml b/man/systemd-pcrphase.service.xml
index 9b7cc80b3a7..ea1e541fb76 100644
--- a/man/systemd-pcrphase.service.xml
+++ b/man/systemd-pcrphase.service.xml
@@ -41,11 +41,11 @@
 
     <para>These services require
     <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> to be
-    used in a unified kernel image (UKI) setup. They execute no operation when invoked when the stub has not
-    been used to invoke the kernel. The stub will measure the invoked kernel and associated vendor resources
-    into PCR 11 before handing control to it; once userspace is invoked these services then will extend
-    certain literal strings indicating various phases of the boot process into TPM2 PCR 11. During a regular
-    boot process the following strings are extended into PCR 11.</para>
+    used in a unified kernel image (UKI). They execute no operation when the stub has not been used to invoke
+    the kernel. The stub will measure the invoked kernel and associated vendor resources into PCR 11 before
+    handing control to it; once userspace is invoked these services then will extend certain literal strings
+    indicating various phases of the boot process into TPM2 PCR 11. During a regular boot process the
+    following strings are extended into PCR 11:</para>
 
     <orderedlist>
       <listitem><para><literal>enter-initrd</literal> is extended into PCR 11 early when the initrd
@@ -78,9 +78,8 @@
 
       <listitem><para><literal>final</literal> is extended into PCR 11 at the end of system shutdown. It is
       supposed to act as barrier between the time the service manager still runs and when it transitions into
-      the final boot phase where service management is not available anymore. (This string is extended at
+      the final shutdown phase where service management is not available anymore. (This string is extended at
       stop of <filename>systemd-pcrphase-sysinit.service</filename>.)</para></listitem>
-
     </orderedlist>
 
     <para>During a regular system lifecycle, the strings <literal>enter-initrd</literal> →
@@ -91,7 +90,7 @@
     <para>Specific phases of the boot process may be referenced via the series of strings measured, separated
     by colons (the "boot path"). For example, the boot path for the regular system runtime is
     <literal>enter-initrd:leave-initrd:sysinit:ready</literal>, while the one for the initrd is just
-    <literal>enter-initrd</literal>. The boot path for the the boot phase before the initrd, is an empty
+    <literal>enter-initrd</literal>. The boot path for the boot phase before the initrd, is an empty
     string; because that's hard to pass around a single colon (<literal>:</literal>) may be used
     instead. Note that the aforementioned six strings are just the default strings and individual systems
     might measure other strings at other times, and thus implement different and more fine-grained boot
diff --git a/man/systemd-portabled.service.xml b/man/systemd-portabled.service.xml
index 61f2c5ca9e5..6dacea5e9b7 100644
--- a/man/systemd-portabled.service.xml
+++ b/man/systemd-portabled.service.xml
@@ -35,8 +35,8 @@
     <para>Most of <command>systemd-portabled</command>'s functionality is accessible through the
     <citerefentry><refentrytitle>portablectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> command.</para>
 
-    <para>See <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> for details about
-    the concepts this service implements.</para>
+    <para>See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>
+    for details about the concepts this service implements.</para>
   </refsect1>
 
   <refsect1>
diff --git a/man/systemd-sysext.xml b/man/systemd-sysext.xml
index 99436ced59d..39a16d8e8fb 100644
--- a/man/systemd-sysext.xml
+++ b/man/systemd-sysext.xml
@@ -98,16 +98,16 @@
     suitable for shipping resources that are processed by subsystems running in earliest boot. Specifically,
     OS extension images are not suitable for shipping system services or
     <citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>8</manvolnum></citerefentry>
-    definitions. See <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> for a simple
-    mechanism for shipping system services in disk images, in a similar fashion to OS extensions. Note the
-    different isolation on these two mechanisms: while system extension directly extend the underlying OS
-    image with additional files that appear in a way very similar to as if they were shipped in the OS image
-    itself and thus imply no security isolation, portable services imply service level sandboxing in one way
-    or another. The <filename>systemd-sysext.service</filename> service is guaranteed to finish start-up
-    before <filename>basic.target</filename> is reached; i.e. at the time regular services initialize (those
-    which do not use <varname>DefaultDependencies=no</varname>), the files and directories system extensions
-    provide are available in <filename>/usr/</filename> and <filename>/opt/</filename> and may be
-    accessed.</para>
+    definitions. See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>
+    for a simple mechanism for shipping system services in disk images, in a similar fashion to OS
+    extensions. Note the different isolation on these two mechanisms: while system extension directly extend
+    the underlying OS image with additional files that appear in a way very similar to as if they were
+    shipped in the OS image itself and thus imply no security isolation, portable services imply service
+    level sandboxing in one way or another. The <filename>systemd-sysext.service</filename> service is
+    guaranteed to finish start-up before <filename>basic.target</filename> is reached; i.e. at the time
+    regular services initialize (those which do not use <varname>DefaultDependencies=no</varname>), the files
+    and directories system extensions provide are available in <filename>/usr/</filename> and
+    <filename>/opt/</filename> and may be accessed.</para>
 
     <para>Note that there is no concept of enabling/disabling installed system extension images: all
     installed extension images are automatically activated at boot. However, you can place an empty directory
diff --git a/man/systemd-veritysetup-generator.xml b/man/systemd-veritysetup-generator.xml
index 331b5c07bc5..37ded91a936 100644
--- a/man/systemd-veritysetup-generator.xml
+++ b/man/systemd-veritysetup-generator.xml
@@ -27,8 +27,8 @@
   <refsect1>
     <title>Description</title>
 
-    <para><filename>systemd-veritysetup-generator</filename> is a generator that translates kernel command line options
-    configuring verity protected block devices into native systemd units early at boot and when
+    <para><command>systemd-veritysetup-generator</command> is a generator that translates kernel command line
+    options configuring verity protected block devices into native systemd units early at boot and when
     configuration of the system manager is reloaded. This will create
     <citerefentry><refentrytitle>systemd-veritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
     units as necessary.</para>
@@ -36,14 +36,14 @@
     <para>Currently, only two verity devices may be set up with this generator, backing the root and <filename>/usr</filename> file systems of the
     OS.</para>
 
-    <para><filename>systemd-veritysetup-generator</filename> implements
+    <para><command>systemd-veritysetup-generator</command> implements
     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
   </refsect1>
 
   <refsect1>
     <title>Kernel Command Line</title>
 
-    <para><filename>systemd-veritysetup-generator</filename>
+    <para><command>systemd-veritysetup-generator</command>
     understands the following kernel command line parameters:</para>
 
     <variablelist class='kernel-commandline-options'>
@@ -98,7 +98,8 @@
         <term><varname>systemd.verity_usr_hash=</varname></term>
         <term><varname>systemd.verity_usr_options=</varname></term>
 
-        <listitem><para>Equivalent to their counterparts for the root file system as described above, but apply to the <filename>/usr/</filename> file system instead.</para></listitem>
+        <listitem><para>Equivalent to their counterparts for the root file system as described above, but
+        apply to the <filename>/usr/</filename> file system instead.</para></listitem>
       </varlistentry>
     </variablelist>
   </refsect1>
diff --git a/man/systemd-volatile-root.service.xml b/man/systemd-volatile-root.service.xml
index e55526070cc..0d3b40211aa 100644
--- a/man/systemd-volatile-root.service.xml
+++ b/man/systemd-volatile-root.service.xml
@@ -37,10 +37,10 @@
     stateless systems.</para>
 
     <para>This service is only enabled if full volatile mode is selected, for example by specifying
-    <literal>systemd.volatile=yes</literal> on the kernel command line. This service runs only in the initrdyes,
+    <literal>systemd.volatile=yes</literal> on the kernel command line. This service runs only in the initrd,
     before the system transitions to the host's root directory. Note that this service is not used if
-    <literal>systemd.volatile=state</literal> is used, as in that mode the root directory is
-    non-volatile.</para>
+    <literal>systemd.volatile=state</literal> is used, as in that mode the root directory is non-volatile.
+    </para>
   </refsect1>
 
   <refsect1>
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index d7480d266cd..3ee0484e946 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -727,9 +727,9 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
         <para>Note that this setting only has an effect on the unit's processes themselves (or any processes
         directly or indirectly forked off them). It has no effect on processes potentially invoked on request
         of them through tools such as <citerefentry
-        project='man-pages'><refentrytitle>at</refentrytitle><manvolnum>1p</manvolnum></citerefentry>,
+        project='man-pages'><refentrytitle>at</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
         <citerefentry
-        project='man-pages'><refentrytitle>crontab</refentrytitle><manvolnum>1p</manvolnum></citerefentry>,
+        project='man-pages'><refentrytitle>crontab</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
         <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>, or
         arbitrary IPC services.</para></listitem>
       </varlistentry>
@@ -934,7 +934,7 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
                 <entry>LimitNOFILE=</entry>
                 <entry>ulimit -n</entry>
                 <entry>Number of File Descriptors</entry>
-                <entry>Don't use. Be careful when raising the soft limit above 1024, since <function>select()</function> cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use <function>select()</function>. Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use <varname>MemoryMax=</varname> to control overall service memory use, including file descriptor memory.</entry>
+                <entry>Don't use. Be careful when raising the soft limit above 1024, since <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry> cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use <varname>MemoryMax=</varname> to control overall service memory use, including file descriptor memory.</entry>
               </row>
               <row>
                 <entry>LimitAS=</entry>
@@ -3173,11 +3173,13 @@ StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZX
         11) with a prefix of <literal>io.systemd.credential:</literal> or
         <literal>io.systemd.credential.binary:</literal>. In both cases a key/value pair separated by
         <literal>=</literal> is expected, in the latter case the right-hand side is Base64 decoded when
-        parsed (thus permitting binary data to be passed in). Example qemu switch: <literal>-smbios
+        parsed (thus permitting binary data to be passed in). Example
+        <ulink url="https://www.qemu.org/docs/master/system/index.html">qemu</ulink>
+        switch: <literal>-smbios
         type=11,value=io.systemd.credential:xx=yy</literal>, or <literal>-smbios
         type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=</literal>. Alternatively,
         use the <command>qemu</command> <literal>fw_cfg</literal> node
-        <literal>opt/io.systemd.credentials/</literal>. Example qemu switch: <literal>-fw_cfg
+        <literal>opt/io.systemd.credentials/</literal>. Example <command>qemu</command> switch: <literal>-fw_cfg
         name=opt/io.systemd.credentials/mycred,string=supersecret</literal>. They may also be specified on
         the kernel command line using the <literal>systemd.set_credential=</literal> switch (see
         <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) and from
diff --git a/man/systemd.link.xml b/man/systemd.link.xml
index cc55b02b182..c0167b1c86a 100644
--- a/man/systemd.link.xml
+++ b/man/systemd.link.xml
@@ -1116,7 +1116,7 @@
       links.</para>
 
       <programlisting>[Link]
-NamePolicy=kernel database onboard slot path
+NamePolicy=kernel database on-board slot path
 MACAddressPolicy=persistent</programlisting>
     </example>
 
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index d83141de110..ccdbc49b1d8 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -2297,7 +2297,7 @@ allow my_server_t localnet_peer_t:peer recv;</programlisting>
   <refsect1>
     <title>[DHCPPrefixDelegation] Section Options</title>
     <para>The [DHCPPrefixDelegation] section configures subnet prefixes of the delegated prefixes
-    acquired by a DHCPv6 client, or by a DHCPv4 client through the 6RD option on another interface.
+    acquired by a DHCPv6 client or by a DHCPv4 client through the 6RD option on another interface.
     The settings in this section are used only when the <varname>DHCPPrefixDelegation=</varname>
     setting in the [Network] section is enabled.</para>
 
diff --git a/man/systemd.path.xml b/man/systemd.path.xml
index f8748bf700a..834f480b5ce 100644
--- a/man/systemd.path.xml
+++ b/man/systemd.path.xml
@@ -210,7 +210,7 @@
       <title>See Also</title>
       <para>Environment variables with details on the trigger will be set for triggered units. See the
       <literal>Environment Variables Set on Triggered Units</literal> section in
-      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
       for more details.</para>
       <para>
         <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml
index 1142ad7758f..a74a401ef7e 100644
--- a/man/systemd.resource-control.xml
+++ b/man/systemd.resource-control.xml
@@ -1139,8 +1139,9 @@ DeviceAllow=/dev/loop-control
         <varlistentry>
           <term>systemd 252</term>
           <listitem><para> Options for controlling the Legacy Control Group Hierarchy (<ulink
-          url="https://docs.kernel.org/admin-guide/cgroup-v1/index.html">Control Groups version 1</ulink> are
-          now fully deprecated: <varname>CPUShares=<replaceable>weight</replaceable></varname>,
+          url="https://docs.kernel.org/admin-guide/cgroup-v1/index.html">Control Groups version 1</ulink>)
+          are now fully deprecated:
+          <varname>CPUShares=<replaceable>weight</replaceable></varname>,
           <varname>StartupCPUShares=<replaceable>weight</replaceable></varname>,
           <varname>MemoryLimit=<replaceable>bytes</replaceable></varname>,
           <varname>BlockIOAccounting=</varname>,
@@ -1150,8 +1151,7 @@ DeviceAllow=/dev/loop-control
           <replaceable>weight</replaceable></varname>,
           <varname>BlockIOReadBandwidth=<replaceable>device</replaceable>
           <replaceable>bytes</replaceable></varname>,
-          <varname>BlockIOWriteBandwidth=<replaceable>device</replaceable>
-          <replaceable>bytes</replaceable></varname>.
+          <varname>BlockIOWriteBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname>.
           Please switch to the unified cgroup hierarchy.</para></listitem>
         </varlistentry>
       </variablelist>
diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml
index 953faa9b334..a8c8241c94e 100644
--- a/man/systemd.timer.xml
+++ b/man/systemd.timer.xml
@@ -368,7 +368,7 @@
       <title>See Also</title>
       <para>Environment variables with details on the trigger will be set for triggered units. See the
       <literal>Environment Variables Set on Triggered Units</literal> section in
-      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
       for more details.</para>
       <para>
         <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
diff --git a/man/sysupdate.d.xml b/man/sysupdate.d.xml
index 3540b441760..bdf4bcbf7a5 100644
--- a/man/sysupdate.d.xml
+++ b/man/sysupdate.d.xml
@@ -432,7 +432,7 @@
   <refsect1>
     <title>[Transfer] Section Options</title>
 
-    <para>This section defines general properties of this transfer:</para>
+    <para>This section defines general properties of this transfer.</para>
 
     <variablelist>
       <varlistentry>
@@ -485,7 +485,7 @@
   <refsect1>
     <title>[Source] Section Options</title>
 
-    <para>This section defines properties of the transfer source:</para>
+    <para>This section defines properties of the transfer source.</para>
 
     <variablelist>
       <varlistentry>
@@ -535,7 +535,7 @@
   <refsect1>
     <title>[Target] Section Options</title>
 
-    <para>This section defines properties of the transfer target:</para>
+    <para>This section defines properties of the transfer target.</para>
 
     <variablelist>
       <varlistentry>
@@ -546,7 +546,8 @@
         <constant>subvolume</constant>. For details about the resource types, see above. This option is
         mandatory.</para>
 
-        <para>Note that only some combinations of source and target resource types are supported, see above.</para></listitem>
+        <para>Note that only certain combinations of source and target resource types are supported, see
+        above.</para></listitem>
       </varlistentry>
 
       <varlistentry>
@@ -625,7 +626,7 @@
         <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
         Specification</ulink>, similar to the <varname>PartitionNoAuto=</varname> and
         <varname>PartitionGrowFileSystem=</varname> flags described above. If the target type is
-        <constant>regular-file</constant>, the writable bit is removed from the access mode. If the the
+        <constant>regular-file</constant>, the writable bit is removed from the access mode. If the
         target type is <constant>subvolume</constant>, the subvolume will be marked read-only as a
         whole. Finally, if the target <varname>Type=</varname> is selected as <constant>directory</constant>,
         the "immutable" file attribute is set, see <citerefentry
@@ -675,7 +676,7 @@
 
         <para>If the target <varname>Type=</varname> is selected as <constant>partition</constant>, the number
         of concurrent versions to keep is additionally restricted by the number of partition slots of the
-        right type in the partition table. i.e. if there are only 2 partition slots for the selected
+        right type in the partition table. I.e. if there are only 2 partition slots for the selected
         partition type, setting this value larger than 2 is without effect, since no more than 2 concurrent
         versions could be stored in the image anyway.</para></listitem>
       </varlistentry>
diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index bd3bc33ab4d..2b4b4f37bcb 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -88,8 +88,9 @@ A+    /path-or-glob/to/append/acls/recursively -    -    -     -           POSIX
     <filename>/sys/</filename> or <filename>/proc/</filename>, as well as some other directories below
     <filename>/var/</filename>).</para>
 
-    <para><command>systemd-tmpfiles</command> uses this configuration to create volatile files and
-    directories during boot and to do periodic cleanup afterwards. See
+    <para><citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    uses this configuration to create volatile files and directories during boot and to do periodic cleanup
+    afterwards. See
     <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
     the description of <filename>systemd-tmpfiles-setup.service</filename>,
     <filename>systemd-tmpfiles-clean.service</filename>, and associated units.</para>
diff --git a/man/udevadm.xml b/man/udevadm.xml
index ee0658dc14c..0298123c65f 100644
--- a/man/udevadm.xml
+++ b/man/udevadm.xml
@@ -866,7 +866,7 @@
           the "whole" block device in case a partition block device is specified. The devices will be sorted
           by their device node major number as primary ordering key and the minor number as secondary
           ordering key (i.e. they are shown in the order they'd be locked). Note that the number of lines
-          printed here can be less than the the number of <option>--device=</option> and
+          printed here can be less than the number of <option>--device=</option> and
           <option>--backing=</option> switches specified in case these resolve to the same "whole"
           devices.</para></listitem>
         </varlistentry>