Merge pull request #20530 from keszybz/typos-and-meson

Typos and meson

4 files changed, 28 insertions, 22 deletions

diff --git a/docs/DISCOVERABLE_PARTITIONS.md b/docs/DISCOVERABLE_PARTITIONS.md
index 4caa086dc5..bd4cb24602 100644
--- a/docs/DISCOVERABLE_PARTITIONS.md
+++ b/docs/DISCOVERABLE_PARTITIONS.md
@@ -49,7 +49,7 @@ Interface](https://systemd.io/BOOT_LOADER_INTERFACE).
 | `77055800-792c-4f94-b39a-98c91b762bb6` | _Root Partition (LoongArch 64-bit)_ | ditto | ditto |
 | `60d5a7fe-8e7d-435c-b714-3dd8162144e1` | _Root Partition (RISC-V 32-bit)_ | ditto | ditto |
 | `72ec70a6-cf74-40e6-bd49-4bda08e8f224` | _Root Partition (RISC-V 64-bit)_ | ditto | ditto |
-| `d13c5d3b-b5d1-422a-b29f-9454fdc89d76` | _Root Verity Partition (x86)_ | A dm-verity superblock followed by hash data | On systems with matching architecture, contains dm-verity integrity hash data for the matching root partition. If this feature is used the partition UUID of the root partition should be the first 128bit of the root hash of the dm-verity hash data, and the partition UUID of this dm-verity partition should be the final 128bit of it, so that the root partition and its verity partition can be discovered easily, simply by specifying the root hash. |
+| `d13c5d3b-b5d1-422a-b29f-9454fdc89d76` | _Root Verity Partition (x86)_ | A dm-verity superblock followed by hash data | Contains dm-verity integrity hash data for the matching root partition. If this feature is used the partition UUID of the root partition should be the first 128 bits of the root hash of the dm-verity hash data, and the partition UUID of this dm-verity partition should be the final 128 bits of it, so that the root partition and its verity partition can be discovered easily, simply by specifying the root hash. |
 | `2c7357ed-ebd2-46d9-aec1-23d437ec2bf5` | _Root Verity Partition (x86-64)_ | ditto | ditto |
 | `7386cdf2-203c-47a9-a498-f2ecce45a2d6` | _Root Verity Partition (32-bit ARM)_ | ditto | ditto |
 | `df3300ce-d69f-4c92-978c-9bfb0f38d820` | _Root Verity Partition (64-bit ARM/AArch64)_ | ditto | ditto |
@@ -75,7 +75,7 @@ Interface](https://systemd.io/BOOT_LOADER_INTERFACE).
 | `8f1056be-9b05-47c4-81d6-be53128e5b54` | _`/usr/` Verity Partition (RISC-V 64-bit)_ | ditto | ditto |
 | `933ac7e1-2eb4-4f13-b844-0e14e2aef915` | _Home Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/home/`.  If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/home`. |
 | `3b8f8425-20e0-4f3b-907f-1a25a76f98e8` | _Server Data Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/srv/`.  If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/srv`. |
-| `4d21b016-b534-45c2-a9fb-5c16e091fd2d` | _Variable Data Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/var/` — under the condition that its partition UUID matches the first 128 bit of `HMAC-SHA256(machine-id, 0x4d21b016b53445c2a9fb5c16e091fd2d)` (i.e. the SHA256 HMAC hash of the binary type UUID keyed by the machine ID as read from [`/etc/machine-id`](https://www.freedesktop.org/software/systemd/man/machine-id.html). This special requirement is made because `/var/` (unlike the other partition types listed here) is inherently private to a specific installation and cannot possibly be shared between multiple OS installations on the same disk, and thus should be bound to a specific instance of the OS, identified by its machine ID. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/var`. |
+| `4d21b016-b534-45c2-a9fb-5c16e091fd2d` | _Variable Data Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/var/` — under the condition that its partition UUID matches the first 128 bits of `HMAC-SHA256(machine-id, 0x4d21b016b53445c2a9fb5c16e091fd2d)` (i.e. the SHA256 HMAC hash of the binary type UUID keyed by the machine ID as read from [`/etc/machine-id`](https://www.freedesktop.org/software/systemd/man/machine-id.html). This special requirement is made because `/var/` (unlike the other partition types listed here) is inherently private to a specific installation and cannot possibly be shared between multiple OS installations on the same disk, and thus should be bound to a specific instance of the OS, identified by its machine ID. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/var`. |
 | `7ec6f557-3bc5-4aca-b293-16ef5df639d1` | _Temporary Data Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/var/tmp/`.  If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/tmp`. Note that the intended mount point is indeed `/var/tmp/`, not `/tmp/`. The latter is typically maintained in memory via <tt>tmpfs</tt> and does not require a partition on disk. In some cases it might be desirable to make `/tmp/` persistent too, in which case it is recommended to make it a symlink or bind mount to `/var/tmp/`, thus not requiring its own partition type UUID. |
 | `0657fd6d-a4ab-43c4-84e5-0933c84b4f4f` | _Swap_ | Swap, optionally in LUKS | All swap partitions on the disk containing the root partition are automatically enabled. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/swap`. This partition type predates the Discoverable Partitions Specification. |
 | `0fc63daf-8483-4772-8e79-3d69d8477de4` | _Generic Linux Data Partitions_ | Any native, optionally in LUKS | No automatic mounting takes place for other Linux data partitions. This partition type should be used for all partitions that carry Linux file systems. The installer needs to mount them explicitly via entries in <tt>/etc/fstab</tt>. Optionally, these partitions may be encrypted with LUKS. This partition type predates the Discoverable Partitions Specification. |
diff --git a/man/os-release.xml b/man/os-release.xml
index 6be96cf8bc..15608c437a 100644
--- a/man/os-release.xml
+++ b/man/os-release.xml
@@ -93,30 +93,36 @@
       main system. Additionally, the presence of that file means that the system is in the initrd phase.
       <filename>/etc/os-release</filename> should be symlinked to <filename>/etc/initrd-release</filename>
       (or vice versa), so programs that only look for <filename>/etc/os-release</filename> (as described
-      above) work correctly. The rest of this document that talks about <filename>os-release</filename>
-      should be understood to apply to <filename>initrd-release</filename> too.</para>
+      above) work correctly.</para>
+
+      <para>The rest of this document that talks about <filename>os-release</filename> should be understood
+      to apply to <filename>initrd-release</filename> too.</para>
     </refsect2>
 
     <refsect2>
       <title><filename>/usr/lib/extension-release.d/extension-release.<replaceable>IMAGE</replaceable></filename></title>
 
       <para><filename>/usr/lib/extension-release.d/extension-release.<replaceable>IMAGE</replaceable></filename>
-      for extension images plays the same role as <filename>os-release</filename> in the main system, and follows the
-      same syntax and rules as described in the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>.
-      The purpose of this file is to allow the operating system to correctly match an extension image
-      to a base OS image, This is typically implemented by first checking that the <varname>ID=</varname>
-      options match, and if they do either <varname>SYSEXT_LEVEL=</varname> has to match too (preferred), or
-      as a fallback if that is not present <varname>VERSION_ID=</varname> is checked. This ensures that ABI/API
-      between the layers matches and no incompatible images are merged in an overlay.
-      It is preferred that the <filename>extension-release.<replaceable>IMAGE</replaceable></filename> filename is suffixed
-      with the exact file name of the image that contains it, so that all such files in every layer of an overlay are visible.
-      But for the purpose of parsing metadata, in case it is not possible to guarantee that an image file name is stable
-      and doesn't change between the build and the deployment phases, the first and only file which name starts with
-      <filename>extension-release.</filename>, is located in the same directory and is tagged with a
-      <varname>user.extension-release.strict</varname> <citerefentry><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>
-      set to the string <literal>0</literal>, will be parsed instead, if the one with the expected name cannot be found.
-      The rest of this document that talks about <filename>os-release</filename> should be understood to apply to
-      <filename>extension-release</filename> too.</para>
+      plays the same role for extension images as <filename>os-release</filename> for the main system, and
+      follows the syntax and rules as described in the <ulink
+      url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>. The purpose of this
+      file is to identify the extension and to allow the operating system to verify that the extension image
+      matches the base OS. This is typically implemented by checking that the <varname>ID=</varname> options
+      match, and either <varname>SYSEXT_LEVEL=</varname> exists and matches too, or if it is not present,
+      <varname>VERSION_ID=</varname> exists and matches. This ensures ABI/API compatibility between the
+      layers and prevents merging of an incompatible image in an overlay.</para>
+
+      <para>In the <filename>extension-release.<replaceable>IMAGE</replaceable></filename> filename, the
+      <replaceable>IMAGE</replaceable> part must exactly match the file name of the containing image with the
+      suffix removed. In case it is not possible to guarantee that an image file name is stable and doesn't
+      change between the build and the deployment phases, it is possible to relax this check: if exactly one
+      file whose name matches <literal><filename>extension-release.*</filename></literal> is present in this
+      directory, and the file is tagged with a <varname>user.extension-release.strict</varname>
+      <citerefentry><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry> set to the
+      string <literal>0</literal>, it will be used instead.</para>
+
+      <para>The rest of this document that talks about <filename>os-release</filename> should be understood
+      to apply to <filename>extension-release</filename> too.</para>
     </refsect2>
   </refsect1>
 
diff --git a/man/systemd-sysext.xml b/man/systemd-sysext.xml
index f8a9f47539..3ceb9fe7de 100644
--- a/man/systemd-sysext.xml
+++ b/man/systemd-sysext.xml
@@ -92,7 +92,7 @@
 
     <para>During boot OS extension images are activated automatically, if the
     <filename>systemd-sysext.service</filename> is enabled. Note that this service runs only after the
-    underlying file systems where system extensions are searched are mounted. This means they are not
+    underlying file systems where system extensions may be located have been mounted. This means they are not
     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>
diff --git a/meson.build b/meson.build
index f7b18c6b98..6e1a8b1e50 100644
--- a/meson.build
+++ b/meson.build
@@ -3830,7 +3830,7 @@ summary({
 # LDFLAGS:  ${OUR_LDFLAGS} ${LDFLAGS}
 
 if conf.get('ENABLE_EFI') == 1
-        summary({'efi arch' : efi_arch},
+        summary({'EFI arch' : efi_arch},
                 section : 'Extensible Firmware Interface')
 
         if have_gnu_efi