man: fix sysupdate typos

A couple of TEST-69 tweaks

NEWS

@@ -12493,7 +12493,7 @@ CHANGES WITH 197:
           based on a calendar time specification such as "Thu,Fri
           2013-*-1,5 11:12:13" which refers to 11:12:13 of the first
           or fifth day of any month of the year 2013, given that it is
-          a thursday or friday. This brings timer event support
+          a Thursday or a Friday. This brings timer event support
           considerably closer to cron's capabilities. For details on
           the supported calendar time specification language see
           systemd.time(7).

TODO

@@ -78,6 +78,17 @@ Janitorial Clean-ups:
 
 Features:
 
+* per-service sandboxing option: ProtectIds=. If used, will overmount
+  /etc/machine-id and /proc/sys/kernel/random/boot_id with synthetic files, to
+  make it harder for the service to identify the host. Depending on the user
+  setting it should be fully randomized at invocation time, or a hash of the
+  real thing, keyed by the unit name or so. Of course, there are other ways to
+  get these IDs (e.g. journal) or similar ids (e.g. MAC addresses, DMI ids, CPU
+  ids), so this knob would only be useful in combination with other lockdown
+  options. Particularly useful for portable services, and anything else that
+  uses RootDirectory= or RootImage=. (Might also over-mount
+  /sys/class/dmi/id/*{uuid,serial} with /dev/null).
+
 * journalctl/timesyncd: whenever timesyncd acquires a synchronization from NTP,
   create a structured log entry that contains boot ID, monotonic clock and
   realtime clock (I mean, this requires no special work, as these three fields

man/loader.conf.xml

@@ -30,10 +30,11 @@
     <title>Description</title>
 
     <para>
-    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> will
-    will read <filename><replaceable>ESP</replaceable>/loader/loader.conf</filename> and any files with the
+    read <filename><replaceable>ESP</replaceable>/loader/loader.conf</filename>, and any files with the
     <literal>.conf</literal> extension under
-    <filename><replaceable>ESP</replaceable>/loader/entries/</filename> on the EFI system partition (ESP).
+    <filename><replaceable>ESP</replaceable>/loader/entries/</filename> on the EFI system partition (ESP) as
+    defined by <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>.
     </para>
 
     <para>Each configuration file must consist of an option name, followed by

man/systemd-boot.xml

@@ -39,23 +39,22 @@
 
     <itemizedlist>
       <listitem><para>Boot entries defined with <ulink
-      url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> description files
+      url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> Type #1
-      located in <filename>/loader/entries/</filename> on the ESP and the Extended Boot Loader
+      description files located in <filename>/loader/entries/</filename> on the ESP and the Extended Boot
-      Partition. These usually describe Linux kernel images with associated initrd images, but alternatively
+      Loader Partition. These usually describe Linux kernel images with associated initrd images, but
-      may also describe arbitrary other EFI executables.</para></listitem>
+      alternatively may also describe other arbitrary EFI executables.</para></listitem>
 
-      <listitem><para>Unified kernel images following the <ulink
+      <listitem><para>Unified kernel images, <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot
-      url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>, as executable EFI
+      Loader Specification</ulink> Type #2, which are executable EFI binaries in
-      binaries in <filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader Partition.
+      <filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader Partition.</para></listitem>
-      </para></listitem>
 
-      <listitem><para>The Microsoft Windows EFI boot manager, if installed</para></listitem>
+      <listitem><para>The Microsoft Windows EFI boot manager, if installed.</para></listitem>
 
-      <listitem><para>The Apple macOS boot manager, if installed</para></listitem>
+      <listitem><para>The Apple macOS boot manager, if installed.</para></listitem>
 
-      <listitem><para>The EFI Shell binary, if installed</para></listitem>
+      <listitem><para>The EFI Shell binary, if installed.</para></listitem>
 
-      <listitem><para>A reboot into the UEFI firmware setup option, if supported by the firmware</para></listitem>
+      <listitem><para>A reboot into the UEFI firmware setup option, if supported by the firmware.</para></listitem>
     </itemizedlist>
 
     <para><command>systemd-boot</command> supports the following features:</para>

man/systemd-sysupdate.xml

@@ -44,9 +44,9 @@
     <para>This tool implements file, directory, or partition based update schemes, supporting multiple
     parallel installed versions of specific resources in an A/B (or even: A/B/C, A/B/C/D/, …) style. A/B
     updating means that when one version of a resource is currently being used, the next version can be
-    downloaded, unpacked, and prepared in an entirely separate location, indepdently of the first, and — once
+    downloaded, unpacked, and prepared in an entirely separate location, independently of the first, and — once
     complete — be activated, swapping the roles so that it becomes the used one and the previously used one
-    becomes the the one that is replaced by the next update, and so on. The resources to update are defined
+    becomes the one that is replaced by the next update, and so on. The resources to update are defined
     in transfer files, one for each resource to be updated. For example, resources that may be updated with
     this tool could be: a root file system partition, a matching Verity partition plus one kernel image. The
     combination of the three would be considered a complete OS update.</para>

src/libsystemd-network/meson.build

@@ -119,7 +119,7 @@ fuzzers += [
          [libsystemd_network,
           libshared]],
 
-        [files('fuzz-dhcp-server-relay-message.c'),
+        [files('fuzz-dhcp-server-relay.c'),
          [libsystemd_network,
           libshared]],
 

src/test/meson.build

@@ -613,7 +613,7 @@ tests += [
                'nss-test-util.h'),
          [],
          [libdl],
-         [], 'ENABLE_NSS'],
+         [], 'ENABLE_NSS', 'timeout=120'],
 
         [files('test-nss-users.c',
                'nss-test-util.c',

test/TEST-69-SHUTDOWN/test.sh

@@ -13,9 +13,9 @@ _ORIG_NSPAWN="${SYSTEMD_NSPAWN:?}"
 SYSTEMD_NSPAWN="${STATEDIR:?}/run-nspawn"
 
 setup_nspawn_root_hook() {
-    cat > "${STATEDIR:?}"/run-nspawn <<-EOF
+    cat >"${STATEDIR:?}/run-nspawn" <<EOF
 #!/bin/bash
-	exec "${TEST_BASE_DIR:?}"/test-shutdown.py -- "$_ORIG_NSPAWN" "\$@"
+exec "${TEST_BASE_DIR:?}/test-shutdown.py" -v -- "$_ORIG_NSPAWN" "\$@"
 exit 1
 EOF
     chmod 755 "${STATEDIR:?}"/run-nspawn
@@ -24,7 +24,12 @@ setup_nspawn_root_hook() {
 test_append_files() {
     local workspace="${1:?}"
     # prevent shutdown in test suite, the expect script does that manually.
-    rm "${workspace:?}/usr/lib/systemd/tests/testdata/units/end.service"
+    mkdir -p "${workspace:?}/etc/systemd/system/end.service.d"
+    cat >"$workspace/etc/systemd/system/end.service.d/99-override.conf" <<EOF
+[Service]
+ExecStart=
+ExecStart=/bin/true
+EOF
     inst /usr/bin/screen
     echo "PS1='screen\$WINDOW # '" >>"$workspace/root/.bashrc"
     echo 'startup_message off' >"$workspace/etc/screenrc"

test/units/testsuite-69.service

@@ -4,4 +4,4 @@ Description=TEST-69-SHUTDOWN
 
 [Service]
 Type=oneshot
-ExecStart=/usr/lib/systemd/tests/testdata/units/%N.sh
+ExecStart=/bin/true

units/systemd-sysupdate.timer

@@ -18,7 +18,7 @@ ConditionVirtualization=!container
 [Timer]
 # Trigger the update 15min after boot, and then – on average – every 6h, but
 # randomly distributed in a 2h…6h interval. In addition trigger things
-# persistently once on each saturday, to ensure that even on systems that are
+# persistently once on each Saturday, to ensure that even on systems that are
 # never booted up for long we have a chance to to do the update.
 OnBootSec=15min
 OnUnitActiveSec=2h