From e8691e702dd34afdadd76887a193e6e74e4c8368 Mon Sep 17 00:00:00 2001
From: Emanuele Aina <emanuele.aina@collabora.com>
Date: Fri, 8 Mar 2019 18:23:47 +0100
Subject: [PATCH] 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 | 13 ++++++++++++-
apertis-image-uboot.yaml | 13 ++++++++++++-
apertis-image-uefi.yaml | 13 ++++++++++++-
apertis-ostree-commit.yaml | 13 ++++++++++++-
4 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/apertis-image-sdk.yaml b/apertis-image-sdk.yaml
index 2728b4e2..41182652 100644
--- a/apertis-image-sdk.yaml
+++ b/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"
diff --git a/apertis-image-uboot.yaml b/apertis-image-uboot.yaml
index 7bc9e0f6..ce00e100 100644
--- a/apertis-image-uboot.yaml
+++ b/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"
diff --git a/apertis-image-uefi.yaml b/apertis-image-uefi.yaml
index 52cea976..1f0c4874 100644
--- a/apertis-image-uefi.yaml
+++ b/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"
diff --git a/apertis-ostree-commit.yaml b/apertis-ostree-commit.yaml
index af58f02d..a79af998 100644
--- a/apertis-ostree-commit.yaml
+++ b/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"
--
GitLab