Clarify the actual reason machine-id can't be truncated earlier

Even after fixing https://github.com/systemd/systemd/issues/11925

 we
would still have issues by truncating the /etc/machine-id earlies, as
the actual problem is that the systemd-boot tools rely on it being set
for dual-boot scenarios:
* to avoid conflicts when creating entries, see the `90-loaderentry` kernel
  install trigger
* to set the entries for the currently booted installation as default in
  the loader.conf generated by `bootctl install`

In our image this is not useful, as the actual machine-id is supposed to be
uniquely generated on the first boot. However the impact is negligible, as
things still work albeit the code used to potentially disambiguate entries
doesn't match a real machine-id.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

apertis-image-sdk.yaml

@@ -124,7 +124,18 @@ actions:
     description: "Drop resolv.conf so the appropriate one gets created at runtime"
     command: rm "${ROOTDIR}/etc/resolv.conf"
 
-  # can't be done before due to https://github.com/systemd/systemd/issues/11925
+  # the clearing of machine-id can't be done before this point since
+  # systemd-boot requires the machine-id to be set for reasons related to
+  # dual-boot scenarios:
+  # * to avoid conflicts when creating entries, see the `90-loaderentry` kernel
+  #   install trigger
+  # * to set the entries for the currently booted installation as default in
+  #   the loader.conf generated by `bootctl install`
+  #
+  # in our image this is not useful, as the actual machine-id is supposed to be
+  # uniquely generated on the first boot. however the impact is negligible, as
+  # things still work albeit the code used to potentially disambiguate entries
+  # doesn't match a real machine-id
   - action: run
     chroot: false
     description: "Empty /etc/machine-id so it's regenerated on first boot with an unique value"

apertis-image-uboot.yaml

@@ -111,7 +111,18 @@ actions:
     description: "Drop resolv.conf so the appropriate one gets created at runtime"
     command: rm "${ROOTDIR}/etc/resolv.conf"
 
-  # can't be done before due to https://github.com/systemd/systemd/issues/11925
+  # the clearing of machine-id can't be done before this point since
+  # systemd-boot requires the machine-id to be set for reasons related to
+  # dual-boot scenarios:
+  # * to avoid conflicts when creating entries, see the `90-loaderentry` kernel
+  #   install trigger
+  # * to set the entries for the currently booted installation as default in
+  #   the loader.conf generated by `bootctl install`
+  #
+  # in our image this is not useful, as the actual machine-id is supposed to be
+  # uniquely generated on the first boot. however the impact is negligible, as
+  # things still work albeit the code used to potentially disambiguate entries
+  # doesn't match a real machine-id
   - action: run
     chroot: false
     description: "Empty /etc/machine-id so it's regenerated on first boot with an unique value"

apertis-image-uefi.yaml

@@ -141,7 +141,18 @@ actions:
     description: "Drop resolv.conf so the appropriate one gets created at runtime"
     command: rm "${ROOTDIR}/etc/resolv.conf"
 
-  # can't be done before due to https://github.com/systemd/systemd/issues/11925
+  # the clearing of machine-id can't be done before this point since
+  # systemd-boot requires the machine-id to be set for reasons related to
+  # dual-boot scenarios:
+  # * to avoid conflicts when creating entries, see the `90-loaderentry` kernel
+  #   install trigger
+  # * to set the entries for the currently booted installation as default in
+  #   the loader.conf generated by `bootctl install`
+  #
+  # in our image this is not useful, as the actual machine-id is supposed to be
+  # uniquely generated on the first boot. however the impact is negligible, as
+  # things still work albeit the code used to potentially disambiguate entries
+  # doesn't match a real machine-id
   - action: run
     chroot: false
     description: "Empty /etc/machine-id so it's regenerated on first boot with an unique value"

apertis-ostree-commit.yaml

@@ -80,7 +80,18 @@ actions:
     chroot: true
     command: rm -f /usr/lib/tmpfiles.d/dbus.conf
 
-  # can't be done before due to https://github.com/systemd/systemd/issues/11925
+  # the clearing of machine-id can't be done before this point since
+  # systemd-boot requires the machine-id to be set for reasons related to
+  # dual-boot scenarios:
+  # * to avoid conflicts when creating entries, see the `90-loaderentry` kernel
+  #   install trigger
+  # * to set the entries for the currently booted installation as default in
+  #   the loader.conf generated by `bootctl install`
+  #
+  # in our image this is not useful, as the actual machine-id is supposed to be
+  # uniquely generated on the first boot. however the impact is negligible, as
+  # things still work albeit the code used to potentially disambiguate entries
+  # doesn't match a real machine-id
   - action: run
     chroot: false
     description: "Empty /etc/machine-id so it's regenerated on first boot with an unique value"