[RFC] image-postproc-extension: Configurable systemd first boot

Message ID 20221129104654.217984-1-Quirin.Gylstorff@siemens.com
State RFC
Headers show
Series [RFC] image-postproc-extension: Configurable systemd first boot | expand

Commit Message

Quirin Gylstorff Nov. 29, 2022, 10:46 a.m. UTC
From: Quirin Gylstorff <quirin.gylstorff@siemens.com>

The Default implementation will not trigger the first boot condition.

In case of a writable root file system systemd will enable all
units in /usr/lib/systemd/system with the vendor preset enable.
This will also enable units in /usr/lib/systemd/system which are
disable during the installation like ssh.socket.

This will not happen in a Debian installation as first boot is
the installation boot as defined by:
"For normal operating system installations, where a custom image
is created for a specific machine, /etc/machine-id should be
populated during installation."

Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
---
 meta/classes/image-postproc-extension.bbclass | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

Comments

Quirin Gylstorff Aug. 4, 2023, 11:07 a.m. UTC | #1
On 11/29/22 11:46, Quirin Gylstorff wrote:
> From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
> 
> The Default implementation will not trigger the first boot condition.
> 
> In case of a writable root file system systemd will enable all
> units in /usr/lib/systemd/system with the vendor preset enable.
> This will also enable units in /usr/lib/systemd/system which are
> disable during the installation like ssh.socket.
> 
> This will not happen in a Debian installation as first boot is
> the installation boot as defined by:
> "For normal operating system installations, where a custom image
> is created for a specific machine, /etc/machine-id should be
> populated during installation."
> 
> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
> ---
>   meta/classes/image-postproc-extension.bbclass | 11 +++++------
>   1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/classes/image-postproc-extension.bbclass b/meta/classes/image-postproc-extension.bbclass
> index 4a901cb..7e3b8e0 100644
> --- a/meta/classes/image-postproc-extension.bbclass
> +++ b/meta/classes/image-postproc-extension.bbclass
> @@ -53,15 +53,14 @@ image_postprocess_mark() {
>           --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" --version "${PV}"
>   }
>   
> +ENABLE_SYSTEMD_FIRST_BOOT ??= "0"
>   ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
>   image_postprocess_machine_id() {
> -    # systemd(1) takes care of recreating the machine-id on first boot
> -    # for systemd < v247, set to empty string, else set to uninitialized
> -    # (required if initramfs with ro root is used)
>       SYSTEMD_VERSION=$( sudo chroot ${IMAGE_ROOTFS} dpkg-query --showformat='${source:Upstream-Version}' --show systemd || echo "0" )
> -    MACHINE_ID="uninitialized"
> -    if dpkg --compare-versions "$SYSTEMD_VERSION" "lt" "247"; then
> -        MACHINE_ID=""
> +    MACHINE_ID=""
> +    if [ "${ENABLE_SYSTEMD_FIRST_BOOT}" = "1" ] && \
> +        dpkg --compare-versions "$SYSTEMD_VERSION" "gt" "247"; then
> +        MACHINE_ID="uninitialized"
>       fi
>       echo "$MACHINE_ID" | sudo tee '${IMAGE_ROOTFS}/etc/machine-id'
>       sudo rm -f '${IMAGE_ROOTFS}/var/lib/dbus/machine-id'

Ping
Quirin
Michael Adler Aug. 4, 2023, 11:33 a.m. UTC | #2
Hi Quirin,

> In case of a writable root file system systemd will enable all
> units in /usr/lib/systemd/system with the vendor preset enable.
> This will also enable units in /usr/lib/systemd/system which are
> disable during the installation like ssh.socket.

I've stumbled upon the same problem. It took me quite a while to figure out
why systemd services which where explicitly *not* enabled at build time where
somehow still enabled and started on system boot. I did not suspect systemd to
be the culprit! This behavior is unexpected and irritating to say the least.

> The Default implementation will not trigger the first boot condition.

That makes sense. After all, we are fully in control of the root filesystem at
build time. I don't want to deal with surprises at boot time.

Kind Regards,
  Michael

Patch

diff --git a/meta/classes/image-postproc-extension.bbclass b/meta/classes/image-postproc-extension.bbclass
index 4a901cb..7e3b8e0 100644
--- a/meta/classes/image-postproc-extension.bbclass
+++ b/meta/classes/image-postproc-extension.bbclass
@@ -53,15 +53,14 @@  image_postprocess_mark() {
         --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" --version "${PV}"
 }
 
+ENABLE_SYSTEMD_FIRST_BOOT ??= "0"
 ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
 image_postprocess_machine_id() {
-    # systemd(1) takes care of recreating the machine-id on first boot
-    # for systemd < v247, set to empty string, else set to uninitialized
-    # (required if initramfs with ro root is used)
     SYSTEMD_VERSION=$( sudo chroot ${IMAGE_ROOTFS} dpkg-query --showformat='${source:Upstream-Version}' --show systemd || echo "0" )
-    MACHINE_ID="uninitialized"
-    if dpkg --compare-versions "$SYSTEMD_VERSION" "lt" "247"; then
-        MACHINE_ID=""
+    MACHINE_ID=""
+    if [ "${ENABLE_SYSTEMD_FIRST_BOOT}" = "1" ] && \
+        dpkg --compare-versions "$SYSTEMD_VERSION" "gt" "247"; then
+        MACHINE_ID="uninitialized"
     fi
     echo "$MACHINE_ID" | sudo tee '${IMAGE_ROOTFS}/etc/machine-id'
     sudo rm -f '${IMAGE_ROOTFS}/var/lib/dbus/machine-id'