[PATCH 0/3] Filesystem mounting and machine-id fix

[PATCH 0/3] Filesystem mounting and machine-id fix

[claudius.heine.ext]

From: Claudius Heine <ch@denx.de>

Hi,

here is a small patchset that removes the fstab and the machine-id file.

The fstab generation is much to inflexible and in its current form unnecessary.
If it comes back in the future, then we should think about a good user API.

As a result of the removal, I added a few 'rw' kernel arguments to the meta-isar
wks files. I haven't touched the wks files from `scripts` yet, because I don't
really know how/if those scripts are used downstream and would like an input
from the community about this. When I use wic, I tend to write custom wks files.

The machine-id removal is pretty simple and systemd will recreate it on first
boot, but that requires a rw /etc directory. (Some exceptions possible, see
systemd-machine-id-commit.service(8).)

The machine-id patch can be applied without the first two patches.

regards,
Claudius

Claudius Heine (3):
  wks: added 'rw' to kernel arguments
  image.bbclass: remove fstab generation
  image-postproc-extension: add removal of machine-id

 .../scripts/lib/wic/canned-wks/bananapi.wks      |  2 +-
 .../lib/wic/canned-wks/directdisk-isar.wks       |  2 +-
 .../scripts/lib/wic/canned-wks/sdimage-efi.wks   |  2 +-
 meta/classes/image-postproc-extension.bbclass    | 11 +++++++++--
 meta/classes/image.bbclass                       | 16 ----------------
 5 files changed, 12 insertions(+), 21 deletions(-)

-- 
2.20.1

[PATCH 1/3] wks: added 'rw' to kernel arguments

[claudius.heine.ext]

From: Claudius Heine <ch@denx.de>

Signed-off-by: Claudius Heine <ch@denx.de>
---
 meta-isar/scripts/lib/wic/canned-wks/bananapi.wks        | 2 +-
 meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks | 2 +-
 meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks     | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks b/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks
index dbec48e..ad8b46f 100644
--- a/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks
+++ b/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks
@@ -2,4 +2,4 @@ part u-boot --source rawcopy --sourceparams "file=/usr/lib/u-boot/Bananapi/u-boo
 
 part / --source rootfs-u-boot --ondisk mmcblk0 --fstype ext4 --label platform --align 1024
 
-bootloader --append "rootwait"
+bootloader --append "rootwait rw"
diff --git a/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks b/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks
index e78429c..43107b6 100644
--- a/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks
+++ b/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks
@@ -4,4 +4,4 @@
 
 include common-isar.wks.inc
 
-bootloader  --timeout=0  --append "rootwait rootfstype=ext4 video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8"
+bootloader  --timeout=0  --append "rootwait rw rootfstype=ext4 video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8"
diff --git a/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks b/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks
index 2afa016..f9e49ca 100644
--- a/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks
+++ b/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks
@@ -6,4 +6,4 @@ part /boot --source bootimg-efi-isar --sourceparams "loader=grub-efi" --ondisk s
 
 part / --source rootfs --ondisk sda --fstype ext4 --label platform --align 1024 --use-uuid
 
-bootloader --ptable gpt --timeout 3 --append "rootwait console=ttyS0,115200 console=tty0"
+bootloader --ptable gpt --timeout 3 --append "rw rootwait console=ttyS0,115200 console=tty0"
-- 
2.20.1

[PATCH 2/3] image.bbclass: remove fstab generation

[claudius.heine.ext]

From: Claudius Heine <ch@denx.de>

Generating the fstab is not necessary, since the mounts are either
default [1] or can be described via kernel command line or systemd.mount
files. The current fstab generation mechanism is also to inflexible to
allow easy customization from within an image recipe.

[1] https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/

Signed-off-by: Claudius Heine <ch@denx.de>
---
 meta/classes/image.bbclass | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 1950263..5682134 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -105,22 +105,6 @@ python set_image_size () {
     d.setVarFlag('ROOTFS_SIZE', 'export', '1')
 }
 
-ROOTFS_CONFIGURE_COMMAND += "image_configure_fstab"
-image_configure_fstab[weight] = "2"
-image_configure_fstab() {
-    sudo tee '${IMAGE_ROOTFS}/etc/fstab' << EOF
-# Begin /etc/fstab
-/dev/root	/		auto		defaults		0	0
-proc		/proc		proc		nosuid,noexec,nodev	0	0
-sysfs		/sys		sysfs		nosuid,noexec,nodev	0	0
-devpts		/dev/pts	devpts		gid=5,mode=620		0	0
-tmpfs		/run		tmpfs		defaults		0	0
-devtmpfs	/dev		devtmpfs	mode=0755,nosuid	0	0
-
-# End /etc/fstab
-EOF
-}
-
 do_copy_boot_files[dirs] = "${DEPLOY_DIR_IMAGE}"
 do_copy_boot_files() {
     kernel="$(realpath -q '${IMAGE_ROOTFS}/vmlinuz')"
-- 
2.20.1

[PATCH 3/3] image-postproc-extension: add removal of machine-id

[claudius.heine.ext]

From: Claudius Heine <ch@denx.de>

The machine-id(5) should contain a unique id of the machine, but since
this file is created by the systemd postinst script, every machine using
the same image would have the same id.

The file is removed in a postprocessing step and will be regenerated by
systemd on the first boot.

Signed-off-by: Claudius Heine <ch@denx.de>
---
 meta/classes/image-postproc-extension.bbclass | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image-postproc-extension.bbclass b/meta/classes/image-postproc-extension.bbclass
index 625ba7d..495eae6 100644
--- a/meta/classes/image-postproc-extension.bbclass
+++ b/meta/classes/image-postproc-extension.bbclass
@@ -26,8 +26,7 @@ update_etc_os_release() {
     fi
 }
 
-ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure image_postprocess_mark"
-
+ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure"
 image_postprocess_configure() {
     # Configure root filesystem
     if [ -n "${DISTRO_CONFIG_SCRIPT}" ]; then
@@ -39,8 +38,16 @@ image_postprocess_configure() {
    fi
 }
 
+ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark"
+
 image_postprocess_mark() {
     BUILD_ID=$(get_build_id)
     update_etc_os_release \
         --build-id "${BUILD_ID}" --variant "${DESCRIPTION}"
 }
+
+ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
+image_postprocess_machine_id() {
+    # systemd(1) takes care of recreating the machine-id on first boot
+    sudo rm -f '${IMAGE_ROOTFS}/etc/machine-id'
+}
-- 
2.20.1

Re: [PATCH 1/3] wks: added 'rw' to kernel arguments

[Henning Schild]

Just looked at recent upstream wic. They do not have the "rw" and are
probably using their own fstab-stuff.

Can you elaborate why this is required?

Not that a care about the minimal change in the fork, the patch does
not motivate it. And there seems to be a difference which would prevent
us from using random wks files from the internet.

Henning

Am Tue, 28 May 2019 10:58:12 +0200
schrieb "[ext] claudius.heine.ext@siemens.com"
<claudius.heine.ext@siemens.com>:

> From: Claudius Heine <ch@denx.de>
> 
> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>  meta-isar/scripts/lib/wic/canned-wks/bananapi.wks        | 2 +-
>  meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks | 2 +-
>  meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks     | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks
> b/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks index
> dbec48e..ad8b46f 100644 ---
> a/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks +++
> b/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks @@ -2,4 +2,4 @@
> part u-boot --source rawcopy --sourceparams
> "file=/usr/lib/u-boot/Bananapi/u-boo part / --source rootfs-u-boot
> --ondisk mmcblk0 --fstype ext4 --label platform --align 1024 
> -bootloader --append "rootwait"
> +bootloader --append "rootwait rw"
> diff --git a/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks
> b/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks index
> e78429c..43107b6 100644 ---
> a/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks +++
> b/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks @@ -4,4
> +4,4 @@ 
>  include common-isar.wks.inc
>  
> -bootloader  --timeout=0  --append "rootwait rootfstype=ext4
> video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8"
> +bootloader  --timeout=0  --append "rootwait rw rootfstype=ext4
> video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8" diff
> --git a/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks
> b/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks index
> 2afa016..f9e49ca 100644 ---
> a/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks +++
> b/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks @@ -6,4 +6,4
> @@ part /boot --source bootimg-efi-isar --sourceparams
> "loader=grub-efi" --ondisk s part / --source rootfs --ondisk sda
> --fstype ext4 --label platform --align 1024 --use-uuid -bootloader
> --ptable gpt --timeout 3 --append "rootwait console=ttyS0,115200
> console=tty0" +bootloader --ptable gpt --timeout 3 --append "rw
> rootwait console=ttyS0,115200 console=tty0"

Re: [PATCH 2/3] image.bbclass: remove fstab generation

[Henning Schild]

Systemd might be default, but is not guaranteed to be installed on a
working and officially supported debian.

Yes we do kind of need it at the moment (for very few features where
other inits can be enabled as needed). But we would at least see a
conflict. I.e ssh-key-regen is pulling systemd while someone else is
pulling sysvinit.

With this patch we might create non-bootable images, which is not OK.

Henning

Am Tue, 28 May 2019 10:58:13 +0200
schrieb "[ext] claudius.heine.ext@siemens.com"
<claudius.heine.ext@siemens.com>:

> From: Claudius Heine <ch@denx.de>
> 
> Generating the fstab is not necessary, since the mounts are either
> default [1] or can be described via kernel command line or
> systemd.mount files. The current fstab generation mechanism is also
> to inflexible to allow easy customization from within an image recipe.
> 
> [1] https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
> 
> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>  meta/classes/image.bbclass | 16 ----------------
>  1 file changed, 16 deletions(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 1950263..5682134 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -105,22 +105,6 @@ python set_image_size () {
>      d.setVarFlag('ROOTFS_SIZE', 'export', '1')
>  }
>  
> -ROOTFS_CONFIGURE_COMMAND += "image_configure_fstab"
> -image_configure_fstab[weight] = "2"
> -image_configure_fstab() {
> -    sudo tee '${IMAGE_ROOTFS}/etc/fstab' << EOF
> -# Begin /etc/fstab
> -/dev/root	/		auto
> defaults		0	0
> -proc		/proc		proc
> nosuid,noexec,nodev	0	0
> -sysfs		/sys		sysfs
> nosuid,noexec,nodev	0	0
> -devpts		/dev/pts	devpts
> gid=5,mode=620		0	0
> -tmpfs		/run		tmpfs
> defaults		0	0
> -devtmpfs	/dev		devtmpfs
> mode=0755,nosuid	0	0 - -# End /etc/fstab -EOF -} -
> do_copy_boot_files[dirs] = "${DEPLOY_DIR_IMAGE}" do_copy_boot_files()
> { kernel="$(realpath -q '${IMAGE_ROOTFS}/vmlinuz')"

Re: [PATCH 3/3] image-postproc-extension: add removal of machine-id

[Henning Schild]

Am Tue, 28 May 2019 10:58:14 +0200
schrieb "[ext] claudius.heine.ext@siemens.com"
<claudius.heine.ext@siemens.com>:

> From: Claudius Heine <ch@denx.de>
> 
> The machine-id(5) should contain a unique id of the machine, but since
> this file is created by the systemd postinst script, every machine
> using the same image would have the same id.
> 
> The file is removed in a postprocessing step and will be regenerated
> by systemd on the first boot.

Systemd is not the only officially supported init system on Debian. And
i disagree with anyone claiming that it is OK to assume that in Isar ;).

I just did a little test and the outcome means we need more research.

In stretch with sysvinit-core in IMAGE_PREINSTALL there will be no
machine-id. So it is OK to rm -f, where the f is important.

In buster there is one, no clue where it comes from ... But that is
not magically recreated at first boot. Meaning we might have deleted an
important file without a plan to bring it back.

Question is, is it important at all for !systemd. If not at all, who
created and and why? Btw ... my gentoo laptop also has one, and i would
never install systemd. Maybe udev ...

Henning

> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>  meta/classes/image-postproc-extension.bbclass | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/image-postproc-extension.bbclass
> b/meta/classes/image-postproc-extension.bbclass index
> 625ba7d..495eae6 100644 ---
> a/meta/classes/image-postproc-extension.bbclass +++
> b/meta/classes/image-postproc-extension.bbclass @@ -26,8 +26,7 @@
> update_etc_os_release() { fi
>  }
>  
> -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure
> image_postprocess_mark" -
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure"
>  image_postprocess_configure() {
>      # Configure root filesystem
>      if [ -n "${DISTRO_CONFIG_SCRIPT}" ]; then
> @@ -39,8 +38,16 @@ image_postprocess_configure() {
>     fi
>  }
>  
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark"
> +
>  image_postprocess_mark() {
>      BUILD_ID=$(get_build_id)
>      update_etc_os_release \
>          --build-id "${BUILD_ID}" --variant "${DESCRIPTION}"
>  }
> +
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
> +image_postprocess_machine_id() {
> +    # systemd(1) takes care of recreating the machine-id on first
> boot
> +    sudo rm -f '${IMAGE_ROOTFS}/etc/machine-id'
> +}

Re: [PATCH 3/3] image-postproc-extension: add removal of machine-id

[Henning Schild]

Am Tue, 28 May 2019 10:58:14 +0200
schrieb "[ext] claudius.heine.ext@siemens.com"
<claudius.heine.ext@siemens.com>:

> From: Claudius Heine <ch@denx.de>
> 
> The machine-id(5) should contain a unique id of the machine, but since
> this file is created by the systemd postinst script, every machine
> using the same image would have the same id.
> 
> The file is removed in a postprocessing step and will be regenerated
> by systemd on the first boot.

Maybe you can add a

Reported-by: Matthias Lüscher <m.luescher@datacomm.ch>

He is the maintainer of https://www.get-edi.io/ and mentioned that in a
talk i attended before i brought that up for Isar.

Matthias let us know if you care.

Henning

> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>  meta/classes/image-postproc-extension.bbclass | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/image-postproc-extension.bbclass
> b/meta/classes/image-postproc-extension.bbclass index
> 625ba7d..495eae6 100644 ---
> a/meta/classes/image-postproc-extension.bbclass +++
> b/meta/classes/image-postproc-extension.bbclass @@ -26,8 +26,7 @@
> update_etc_os_release() { fi
>  }
>  
> -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure
> image_postprocess_mark" -
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure"
>  image_postprocess_configure() {
>      # Configure root filesystem
>      if [ -n "${DISTRO_CONFIG_SCRIPT}" ]; then
> @@ -39,8 +38,16 @@ image_postprocess_configure() {
>     fi
>  }
>  
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark"
> +
>  image_postprocess_mark() {
>      BUILD_ID=$(get_build_id)
>      update_etc_os_release \
>          --build-id "${BUILD_ID}" --variant "${DESCRIPTION}"
>  }
> +
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
> +image_postprocess_machine_id() {
> +    # systemd(1) takes care of recreating the machine-id on first
> boot
> +    sudo rm -f '${IMAGE_ROOTFS}/etc/machine-id'
> +}

Re: [PATCH 1/3] wks: added 'rw' to kernel arguments

[Claudius Heine]

Hi Henning,

On 28/05/2019 19.29, Henning Schild wrote:
> Just looked at recent upstream wic. They do not have the "rw" and are
> probably using their own fstab-stuff.
> 
> Can you elaborate why this is required?

After I removed the fstab in the second patch, the root file system was 
mounted ro in qemu and the /etc/machine-id could not be recreated. The 
easiest solution is to add 'rw' to the kernel cmdline. Since my debian 
host has 'ro' in its cmdline, I think those kind of settings are ok 
there in debian.

> 
> Not that a care about the minimal change in the fork, the patch does
> not motivate it. And there seems to be a difference which would prevent
> us from using random wks files from the internet.

Maybe it would make sense to merge this patch with the next one, since 
this fixes a issue that only happens after fstab is removed.

Claudius

> 
> Henning
> 
> Am Tue, 28 May 2019 10:58:12 +0200
> schrieb "[ext] claudius.heine.ext@siemens.com"
> <claudius.heine.ext@siemens.com>:
> 
>> From: Claudius Heine <ch@denx.de>
>>
>> Signed-off-by: Claudius Heine <ch@denx.de>
>> ---
>>   meta-isar/scripts/lib/wic/canned-wks/bananapi.wks        | 2 +-
>>   meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks | 2 +-
>>   meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks     | 2 +-
>>   3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks
>> b/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks index
>> dbec48e..ad8b46f 100644 ---
>> a/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks +++
>> b/meta-isar/scripts/lib/wic/canned-wks/bananapi.wks @@ -2,4 +2,4 @@
>> part u-boot --source rawcopy --sourceparams
>> "file=/usr/lib/u-boot/Bananapi/u-boo part / --source rootfs-u-boot
>> --ondisk mmcblk0 --fstype ext4 --label platform --align 1024
>> -bootloader --append "rootwait"
>> +bootloader --append "rootwait rw"
>> diff --git a/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks
>> b/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks index
>> e78429c..43107b6 100644 ---
>> a/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks +++
>> b/meta-isar/scripts/lib/wic/canned-wks/directdisk-isar.wks @@ -4,4
>> +4,4 @@
>>   include common-isar.wks.inc
>>   
>> -bootloader  --timeout=0  --append "rootwait rootfstype=ext4
>> video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8"
>> +bootloader  --timeout=0  --append "rootwait rw rootfstype=ext4
>> video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8" diff
>> --git a/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks
>> b/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks index
>> 2afa016..f9e49ca 100644 ---
>> a/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks +++
>> b/meta-isar/scripts/lib/wic/canned-wks/sdimage-efi.wks @@ -6,4 +6,4
>> @@ part /boot --source bootimg-efi-isar --sourceparams
>> "loader=grub-efi" --ondisk s part / --source rootfs --ondisk sda
>> --fstype ext4 --label platform --align 1024 --use-uuid -bootloader
>> --ptable gpt --timeout 3 --append "rootwait console=ttyS0,115200
>> console=tty0" +bootloader --ptable gpt --timeout 3 --append "rw
>> rootwait console=ttyS0,115200 console=tty0"
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: [PATCH 2/3] image.bbclass: remove fstab generation

[Claudius Heine]

On 28/05/2019 19.34, Henning Schild wrote:
> Systemd might be default, but is not guaranteed to be installed on a
> working and officially supported debian.
> 
> Yes we do kind of need it at the moment (for very few features where
> other inits can be enabled as needed). But we would at least see a
> conflict. I.e ssh-key-regen is pulling systemd while someone else is
> pulling sysvinit.
> 
> With this patch we might create non-bootable images, which is not OK.

I would like to support any init system that debian supports as well, 
but I currently don't have any project that does not use systemd with 
isar, so for me there is currently no use case.

But if you would implement a test case for SysV in meta-isar, then I 
could try to find a solution that works with SysV as well as systemd or 
any other init system we have a test case for (if the workload is at a 
manageable level). As is currently stands though we only test systemd 
and therefor officially only support that in isar.

Claudius

> 
> Henning
> 
> Am Tue, 28 May 2019 10:58:13 +0200
> schrieb "[ext] claudius.heine.ext@siemens.com"
> <claudius.heine.ext@siemens.com>:
> 
>> From: Claudius Heine <ch@denx.de>
>>
>> Generating the fstab is not necessary, since the mounts are either
>> default [1] or can be described via kernel command line or
>> systemd.mount files. The current fstab generation mechanism is also
>> to inflexible to allow easy customization from within an image recipe.
>>
>> [1] https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
>>
>> Signed-off-by: Claudius Heine <ch@denx.de>
>> ---
>>   meta/classes/image.bbclass | 16 ----------------
>>   1 file changed, 16 deletions(-)
>>
>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>> index 1950263..5682134 100644
>> --- a/meta/classes/image.bbclass
>> +++ b/meta/classes/image.bbclass
>> @@ -105,22 +105,6 @@ python set_image_size () {
>>       d.setVarFlag('ROOTFS_SIZE', 'export', '1')
>>   }
>>   
>> -ROOTFS_CONFIGURE_COMMAND += "image_configure_fstab"
>> -image_configure_fstab[weight] = "2"
>> -image_configure_fstab() {
>> -    sudo tee '${IMAGE_ROOTFS}/etc/fstab' << EOF
>> -# Begin /etc/fstab
>> -/dev/root	/		auto
>> defaults		0	0
>> -proc		/proc		proc
>> nosuid,noexec,nodev	0	0
>> -sysfs		/sys		sysfs
>> nosuid,noexec,nodev	0	0
>> -devpts		/dev/pts	devpts
>> gid=5,mode=620		0	0
>> -tmpfs		/run		tmpfs
>> defaults		0	0
>> -devtmpfs	/dev		devtmpfs
>> mode=0755,nosuid	0	0 - -# End /etc/fstab -EOF -} -
>> do_copy_boot_files[dirs] = "${DEPLOY_DIR_IMAGE}" do_copy_boot_files()
>> { kernel="$(realpath -q '${IMAGE_ROOTFS}/vmlinuz')"
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: [PATCH 3/3] image-postproc-extension: add removal of machine-id

[Matthias Luescher]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

Hi Henning

Maybe you can add a
>
> Reported-by: Matthias Lüscher <m.luescher@datacomm.ch>
>
> He is the maintainer of https://www.get-edi.io/ and mentioned that in a
> talk i attended before i brought that up for Isar.
>
> Matthias let us know if you care.
>

I am fine if you would like to add me as a reporter.
However, what is probably more important is that the ISAR users are aware
of the systemd preset behavior that gets triggered by the removal of
/etc/machine-id:
https://www.get-edi.io/11-Traps-to-Avoid-When-Building-Debian-Images/  (9.
systemd Preset Behavior).

I am looking forward to learn more about ISAR during the upcoming OSADL
networking day!

Best regards
Matthias

[-- Attachment #2: Type: text/html, Size: 1255 bytes --]

Re: [PATCH 3/3] image-postproc-extension: add removal of machine-id

[Claudius Heine]

Hi Henning,

On 28/05/2019 19.44, Henning Schild wrote:
> Am Tue, 28 May 2019 10:58:14 +0200
> schrieb "[ext] claudius.heine.ext@siemens.com"
> <claudius.heine.ext@siemens.com>:
> 
>> From: Claudius Heine <ch@denx.de>
>>
>> The machine-id(5) should contain a unique id of the machine, but since
>> this file is created by the systemd postinst script, every machine
>> using the same image would have the same id.
>>
>> The file is removed in a postprocessing step and will be regenerated
>> by systemd on the first boot.
> 
> Systemd is not the only officially supported init system on Debian. And
> i disagree with anyone claiming that it is OK to assume that in Isar ;).
> 
> I just did a little test and the outcome means we need more research.
> 
> In stretch with sysvinit-core in IMAGE_PREINSTALL there will be no
> machine-id. So it is OK to rm -f, where the f is important.
> 
> In buster there is one, no clue where it comes from ... But that is
> not magically recreated at first boot. Meaning we might have deleted an
> important file without a plan to bring it back.
> 
> Question is, is it important at all for !systemd. If not at all, who
> created and and why? Btw ... my gentoo laptop also has one, and i would
> never install systemd. Maybe udev ...

 From machine-id(5):
        The machine ID is usually generated from a random source during 
system
        installation or first boot and stays constant for all subsequent 
boots.
        Optionally, for stateless systems, it is generated during 
runtime during early
        boot if necessary.

As I understand it, it is ok to remove that file if the system has 
technically not booted yet. Systemd also couples its 'first boot 
detection' on the existence of the `/etc/machine-id` file:

 From systemd.unit(5):
            ConditionFirstBoot= takes a boolean argument. This condition 
may be used to
            conditionalize units on whether the system is booting up 
with an unpopulated
            /etc directory (specifically: an /etc with no 
/etc/machine-id). This may be
            used to populate /etc on the first boot after factory reset, 
or when a new
            system instance boots up for the first time.

So any system that depends on the existence of a machine-id should also 
depend on systemd (or something else) recreating that on the first boot 
if it does not exist.

Claudius

> 
> Henning
> 
>> Signed-off-by: Claudius Heine <ch@denx.de>
>> ---
>>   meta/classes/image-postproc-extension.bbclass | 11 +++++++++--
>>   1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/image-postproc-extension.bbclass
>> b/meta/classes/image-postproc-extension.bbclass index
>> 625ba7d..495eae6 100644 ---
>> a/meta/classes/image-postproc-extension.bbclass +++
>> b/meta/classes/image-postproc-extension.bbclass @@ -26,8 +26,7 @@
>> update_etc_os_release() { fi
>>   }
>>   
>> -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure
>> image_postprocess_mark" -
>> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure"
>>   image_postprocess_configure() {
>>       # Configure root filesystem
>>       if [ -n "${DISTRO_CONFIG_SCRIPT}" ]; then
>> @@ -39,8 +38,16 @@ image_postprocess_configure() {
>>      fi
>>   }
>>   
>> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark"
>> +
>>   image_postprocess_mark() {
>>       BUILD_ID=$(get_build_id)
>>       update_etc_os_release \
>>           --build-id "${BUILD_ID}" --variant "${DESCRIPTION}"
>>   }
>> +
>> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
>> +image_postprocess_machine_id() {
>> +    # systemd(1) takes care of recreating the machine-id on first
>> boot
>> +    sudo rm -f '${IMAGE_ROOTFS}/etc/machine-id'
>> +}
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: [PATCH 3/3] image-postproc-extension: add removal of machine-id

[Claudius Heine]

Hi Matthias,

On 29/05/2019 09.00, Matthias Luescher wrote:
> Hi Henning
> 
> Maybe you can add a
>>
>> Reported-by: Matthias Lüscher <m.luescher@datacomm.ch>
>>
>> He is the maintainer of https://www.get-edi.io/ and mentioned that in a
>> talk i attended before i brought that up for Isar.
>>
>> Matthias let us know if you care.
>>
> 
> I am fine if you would like to add me as a reporter.

Ok, I will add you.

> However, what is probably more important is that the ISAR users are aware
> of the systemd preset behavior that gets triggered by the removal of
> /etc/machine-id:
> https://www.get-edi.io/11-Traps-to-Avoid-When-Building-Debian-Images/  (9.
> systemd Preset Behavior).

I currently think Isar would not be affected by this, because developer 
images and release images are different root file systems here, so the 
release image would not contain those backdoor services.

But thanks for pointing that out! I did not know that.

kind regards,
Claudius

> 
> I am looking forward to learn more about ISAR during the upcoming OSADL
> networking day!
> 
> Best regards
> Matthias
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

Re: [PATCH 3/3] image-postproc-extension: add removal of machine-id

[Henning Schild]

Am Wed, 29 May 2019 09:00:52 +0200
schrieb Claudius Heine <claudius.heine.ext@siemens.com>:

> Hi Henning,
> 
> On 28/05/2019 19.44, Henning Schild wrote:
> > Am Tue, 28 May 2019 10:58:14 +0200
> > schrieb "[ext] claudius.heine.ext@siemens.com"
> > <claudius.heine.ext@siemens.com>:
> >   
> >> From: Claudius Heine <ch@denx.de>
> >>
> >> The machine-id(5) should contain a unique id of the machine, but
> >> since this file is created by the systemd postinst script, every
> >> machine using the same image would have the same id.
> >>
> >> The file is removed in a postprocessing step and will be
> >> regenerated by systemd on the first boot.  
> > 
> > Systemd is not the only officially supported init system on Debian.
> > And i disagree with anyone claiming that it is OK to assume that in
> > Isar ;).
> > 
> > I just did a little test and the outcome means we need more
> > research.
> > 
> > In stretch with sysvinit-core in IMAGE_PREINSTALL there will be no
> > machine-id. So it is OK to rm -f, where the f is important.
> > 
> > In buster there is one, no clue where it comes from ... But that is
> > not magically recreated at first boot. Meaning we might have
> > deleted an important file without a plan to bring it back.
> > 
> > Question is, is it important at all for !systemd. If not at all, who
> > created and and why? Btw ... my gentoo laptop also has one, and i
> > would never install systemd. Maybe udev ...  
> 
>  From machine-id(5):
>         The machine ID is usually generated from a random source
> during system
>         installation or first boot and stays constant for all
> subsequent boots.
>         Optionally, for stateless systems, it is generated during 
> runtime during early
>         boot if necessary.
> 
> As I understand it, it is ok to remove that file if the system has 
> technically not booted yet. Systemd also couples its 'first boot 
> detection' on the existence of the `/etc/machine-id` file:
> 
>  From systemd.unit(5):
>             ConditionFirstBoot= takes a boolean argument. This
> condition may be used to
>             conditionalize units on whether the system is booting up 
> with an unpopulated
>             /etc directory (specifically: an /etc with no 
> /etc/machine-id). This may be
>             used to populate /etc on the first boot after factory
> reset, or when a new
>             system instance boots up for the first time.
> 
> So any system that depends on the existence of a machine-id should
> also depend on systemd (or something else) recreating that on the
> first boot if it does not exist.

Agreed. Sounds like it is safe to remove it in any case!

Henning

> Claudius
> 
> > 
> > Henning
> >   
> >> Signed-off-by: Claudius Heine <ch@denx.de>
> >> ---
> >>   meta/classes/image-postproc-extension.bbclass | 11 +++++++++--
> >>   1 file changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/meta/classes/image-postproc-extension.bbclass
> >> b/meta/classes/image-postproc-extension.bbclass index
> >> 625ba7d..495eae6 100644 ---
> >> a/meta/classes/image-postproc-extension.bbclass +++
> >> b/meta/classes/image-postproc-extension.bbclass @@ -26,8 +26,7 @@
> >> update_etc_os_release() { fi
> >>   }
> >>   
> >> -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure
> >> image_postprocess_mark" -
> >> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure"
> >>   image_postprocess_configure() {
> >>       # Configure root filesystem
> >>       if [ -n "${DISTRO_CONFIG_SCRIPT}" ]; then
> >> @@ -39,8 +38,16 @@ image_postprocess_configure() {
> >>      fi
> >>   }
> >>   
> >> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark"
> >> +
> >>   image_postprocess_mark() {
> >>       BUILD_ID=$(get_build_id)
> >>       update_etc_os_release \
> >>           --build-id "${BUILD_ID}" --variant "${DESCRIPTION}"
> >>   }
> >> +
> >> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
> >> +image_postprocess_machine_id() {
> >> +    # systemd(1) takes care of recreating the machine-id on first
> >> boot
> >> +    sudo rm -f '${IMAGE_ROOTFS}/etc/machine-id'
> >> +}  
> >   
> 

Re: [PATCH 2/3] image.bbclass: remove fstab generation

[Henning Schild]

Am Wed, 29 May 2019 08:47:39 +0200
schrieb Claudius Heine <claudius.heine.ext@siemens.com>:

> On 28/05/2019 19.34, Henning Schild wrote:
> > Systemd might be default, but is not guaranteed to be installed on a
> > working and officially supported debian.
> > 
> > Yes we do kind of need it at the moment (for very few features where
> > other inits can be enabled as needed). But we would at least see a
> > conflict. I.e ssh-key-regen is pulling systemd while someone else is
> > pulling sysvinit.
> > 
> > With this patch we might create non-bootable images, which is not
> > OK.  
> 
> I would like to support any init system that debian supports as well, 
> but I currently don't have any project that does not use systemd with 
> isar, so for me there is currently no use case.
> 
> But if you would implement a test case for SysV in meta-isar, then I 
> could try to find a solution that works with SysV as well as systemd
> or any other init system we have a test case for (if the workload is
> at a manageable level). As is currently stands though we only test
> systemd and therefor officially only support that in isar.

You are saying it is ok to break a feature because we currently have
no testcase that would detect the problem?

The testcase is really simple, but including it into Isar will grow or
CI even further. For a corner-case. So i would not add a test-case to
keep CI clean of such a corner-case.

The compromise is to manually test the corner-case when introducing
patches that potentially break it. And the test is pretty easy

IMAGE_PREINSTALL += "sysvinit-core"

and make sure nothing pulls in systemd to replace that guy again.

Henning

> Claudius
> 
> > 
> > Henning
> > 
> > Am Tue, 28 May 2019 10:58:13 +0200
> > schrieb "[ext] claudius.heine.ext@siemens.com"
> > <claudius.heine.ext@siemens.com>:
> >   
> >> From: Claudius Heine <ch@denx.de>
> >>
> >> Generating the fstab is not necessary, since the mounts are either
> >> default [1] or can be described via kernel command line or
> >> systemd.mount files. The current fstab generation mechanism is also
> >> to inflexible to allow easy customization from within an image
> >> recipe.
> >>
> >> [1]
> >> https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
> >>
> >> Signed-off-by: Claudius Heine <ch@denx.de>
> >> ---
> >>   meta/classes/image.bbclass | 16 ----------------
> >>   1 file changed, 16 deletions(-)
> >>
> >> diff --git a/meta/classes/image.bbclass
> >> b/meta/classes/image.bbclass index 1950263..5682134 100644
> >> --- a/meta/classes/image.bbclass
> >> +++ b/meta/classes/image.bbclass
> >> @@ -105,22 +105,6 @@ python set_image_size () {
> >>       d.setVarFlag('ROOTFS_SIZE', 'export', '1')
> >>   }
> >>   
> >> -ROOTFS_CONFIGURE_COMMAND += "image_configure_fstab"
> >> -image_configure_fstab[weight] = "2"
> >> -image_configure_fstab() {
> >> -    sudo tee '${IMAGE_ROOTFS}/etc/fstab' << EOF
> >> -# Begin /etc/fstab
> >> -/dev/root	/		auto
> >> defaults		0	0
> >> -proc		/proc		proc
> >> nosuid,noexec,nodev	0	0
> >> -sysfs		/sys		sysfs
> >> nosuid,noexec,nodev	0	0
> >> -devpts		/dev/pts	devpts
> >> gid=5,mode=620		0	0
> >> -tmpfs		/run		tmpfs
> >> defaults		0	0
> >> -devtmpfs	/dev		devtmpfs
> >> mode=0755,nosuid	0	0 - -# End /etc/fstab -EOF -} -
> >> do_copy_boot_files[dirs] = "${DEPLOY_DIR_IMAGE}"
> >> do_copy_boot_files() { kernel="$(realpath -q
> >> '${IMAGE_ROOTFS}/vmlinuz')"  
> >   
> 

Re: [PATCH 0/3] Filesystem mounting and machine-id fix

[Maxim Yu. Osipov]

Hi Claudius,

Regarding machine-id patch -
I may apply it (with adding Reported-by: Matthias Lüscher 
<m.luescher@datacomm.ch>).

As for the two first ones - could you please provide a feedback on the 
last email from Henning in this thread (see below):

Regards,
Maxim.

-------- Forwarded Message --------
Subject: Re: [PATCH 2/3] image.bbclass: remove fstab generation
Date: Wed, 29 May 2019 13:11:59 +0200
From: Henning Schild <henning.schild@siemens.com>
To: Claudius Heine <claudius.heine.ext@siemens.com>
CC: isar-users@googlegroups.com, Claudius Heine <ch@denx.de>

Am Wed, 29 May 2019 08:47:39 +0200
schrieb Claudius Heine <claudius.heine.ext@siemens.com>:

 > On 28/05/2019 19.34, Henning Schild wrote:
 > > Systemd might be default, but is not guaranteed to be installed on a
 > > working and officially supported debian.
 > >
 > > Yes we do kind of need it at the moment (for very few features where
 > > other inits can be enabled as needed). But we would at least see a
 > > conflict. I.e ssh-key-regen is pulling systemd while someone else is
 > > pulling sysvinit.
 > >
 > > With this patch we might create non-bootable images, which is not
 > > OK.
 >
 > I would like to support any init system that debian supports as well,
 > but I currently don't have any project that does not use systemd with
 > isar, so for me there is currently no use case.
 >
 > But if you would implement a test case for SysV in meta-isar, then I
 > could try to find a solution that works with SysV as well as systemd
 > or any other init system we have a test case for (if the workload is
 > at a manageable level). As is currently stands though we only test
 > systemd and therefor officially only support that in isar.

You are saying it is ok to break a feature because we currently have
no testcase that would detect the problem?

The testcase is really simple, but including it into Isar will grow or
CI even further. For a corner-case. So i would not add a test-case to
keep CI clean of such a corner-case.

The compromise is to manually test the corner-case when introducing
patches that potentially break it. And the test is pretty easy

IMAGE_PREINSTALL += "sysvinit-core"

and make sure nothing pulls in systemd to replace that guy again.

Henning

On 5/28/19 10:58 AM, claudius.heine.ext@siemens.com wrote:
> From: Claudius Heine <ch@denx.de>
> 
> Hi,
> 
> here is a small patchset that removes the fstab and the machine-id file.
> 
> The fstab generation is much to inflexible and in its current form unnecessary.
> If it comes back in the future, then we should think about a good user API.
> 
> As a result of the removal, I added a few 'rw' kernel arguments to the meta-isar
> wks files. I haven't touched the wks files from `scripts` yet, because I don't
> really know how/if those scripts are used downstream and would like an input
> from the community about this. When I use wic, I tend to write custom wks files.
> 
> The machine-id removal is pretty simple and systemd will recreate it on first
> boot, but that requires a rw /etc directory. (Some exceptions possible, see
> systemd-machine-id-commit.service(8).)
> 
> The machine-id patch can be applied without the first two patches.
> 
> regards,
> Claudius
> 
> Claudius Heine (3):
>    wks: added 'rw' to kernel arguments
>    image.bbclass: remove fstab generation
>    image-postproc-extension: add removal of machine-id
> 
>   .../scripts/lib/wic/canned-wks/bananapi.wks      |  2 +-
>   .../lib/wic/canned-wks/directdisk-isar.wks       |  2 +-
>   .../scripts/lib/wic/canned-wks/sdimage-efi.wks   |  2 +-
>   meta/classes/image-postproc-extension.bbclass    | 11 +++++++++--
>   meta/classes/image.bbclass                       | 16 ----------------
>   5 files changed, 12 insertions(+), 21 deletions(-)
> 

Re: [PATCH 0/3] Filesystem mounting and machine-id fix

[Claudius Heine]

[-- Attachment #1.1: Type: text/plain, Size: 4705 bytes --]

Hi Maxim,

On 04/06/2019 22.09, Maxim Yu. Osipov wrote:
> Hi Claudius,
> 
> Regarding machine-id patch -
> I may apply it (with adding Reported-by: Matthias Lüscher
> <m.luescher@datacomm.ch>).
> 
> As for the two first ones - could you please provide a feedback on the
> last email from Henning in this thread (see below):

I just didn't have time to test and investigate that yet.

My work schedule changed a bit starting this month, and as a result I
will probably have less time for Isar upstream.

regards,
Claudius

> 
> Regards,
> Maxim.
> 
> -------- Forwarded Message --------
> Subject: Re: [PATCH 2/3] image.bbclass: remove fstab generation
> Date: Wed, 29 May 2019 13:11:59 +0200
> From: Henning Schild <henning.schild@siemens.com>
> To: Claudius Heine <claudius.heine.ext@siemens.com>
> CC: isar-users@googlegroups.com, Claudius Heine <ch@denx.de>
> 
> Am Wed, 29 May 2019 08:47:39 +0200
> schrieb Claudius Heine <claudius.heine.ext@siemens.com>:
> 
>> On 28/05/2019 19.34, Henning Schild wrote:
>> > Systemd might be default, but is not guaranteed to be installed on a
>> > working and officially supported debian.
>> >
>> > Yes we do kind of need it at the moment (for very few features where
>> > other inits can be enabled as needed). But we would at least see a
>> > conflict. I.e ssh-key-regen is pulling systemd while someone else is
>> > pulling sysvinit.
>> >
>> > With this patch we might create non-bootable images, which is not
>> > OK.
>>
>> I would like to support any init system that debian supports as well,
>> but I currently don't have any project that does not use systemd with
>> isar, so for me there is currently no use case.
>>
>> But if you would implement a test case for SysV in meta-isar, then I
>> could try to find a solution that works with SysV as well as systemd
>> or any other init system we have a test case for (if the workload is
>> at a manageable level). As is currently stands though we only test
>> systemd and therefor officially only support that in isar.
> 
> You are saying it is ok to break a feature because we currently have
> no testcase that would detect the problem?
> 
> The testcase is really simple, but including it into Isar will grow or
> CI even further. For a corner-case. So i would not add a test-case to
> keep CI clean of such a corner-case.
> 
> The compromise is to manually test the corner-case when introducing
> patches that potentially break it. And the test is pretty easy
> 
> IMAGE_PREINSTALL += "sysvinit-core"
> 
> and make sure nothing pulls in systemd to replace that guy again.
> 
> Henning
> 
> On 5/28/19 10:58 AM, claudius.heine.ext@siemens.com wrote:
>> From: Claudius Heine <ch@denx.de>
>>
>> Hi,
>>
>> here is a small patchset that removes the fstab and the machine-id file.
>>
>> The fstab generation is much to inflexible and in its current form
>> unnecessary.
>> If it comes back in the future, then we should think about a good user
>> API.
>>
>> As a result of the removal, I added a few 'rw' kernel arguments to the
>> meta-isar
>> wks files. I haven't touched the wks files from `scripts` yet, because
>> I don't
>> really know how/if those scripts are used downstream and would like an
>> input
>> from the community about this. When I use wic, I tend to write custom
>> wks files.
>>
>> The machine-id removal is pretty simple and systemd will recreate it
>> on first
>> boot, but that requires a rw /etc directory. (Some exceptions
>> possible, see
>> systemd-machine-id-commit.service(8).)
>>
>> The machine-id patch can be applied without the first two patches.
>>
>> regards,
>> Claudius
>>
>> Claudius Heine (3):
>>    wks: added 'rw' to kernel arguments
>>    image.bbclass: remove fstab generation
>>    image-postproc-extension: add removal of machine-id
>>
>>   .../scripts/lib/wic/canned-wks/bananapi.wks      |  2 +-
>>   .../lib/wic/canned-wks/directdisk-isar.wks       |  2 +-
>>   .../scripts/lib/wic/canned-wks/sdimage-efi.wks   |  2 +-
>>   meta/classes/image-postproc-extension.bbclass    | 11 +++++++++--
>>   meta/classes/image.bbclass                       | 16 ----------------
>>   5 files changed, 12 insertions(+), 21 deletions(-)
>>
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

           PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                             Keyserver: hkp://pool.sks-keyservers.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 3/3] image-postproc-extension: add removal of machine-id

[Maxim Yu. Osipov]

On 5/28/19 10:58 AM, claudius.heine.ext@siemens.com wrote:
> From: Claudius Heine <ch@denx.de>
> 
> The machine-id(5) should contain a unique id of the machine, but since
> this file is created by the systemd postinst script, every machine using
> the same image would have the same id.
> 
> The file is removed in a postprocessing step and will be regenerated by
> systemd on the first boot.

Applied to the 'next'.

Regards,
Maxim.

> Signed-off-by: Claudius Heine <ch@denx.de>
> ---
>   meta/classes/image-postproc-extension.bbclass | 11 +++++++++--
>   1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/image-postproc-extension.bbclass b/meta/classes/image-postproc-extension.bbclass
> index 625ba7d..495eae6 100644
> --- a/meta/classes/image-postproc-extension.bbclass
> +++ b/meta/classes/image-postproc-extension.bbclass
> @@ -26,8 +26,7 @@ update_etc_os_release() {
>       fi
>   }
>   
> -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure image_postprocess_mark"
> -
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure"
>   image_postprocess_configure() {
>       # Configure root filesystem
>       if [ -n "${DISTRO_CONFIG_SCRIPT}" ]; then
> @@ -39,8 +38,16 @@ image_postprocess_configure() {
>      fi
>   }
>   
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark"
> +
>   image_postprocess_mark() {
>       BUILD_ID=$(get_build_id)
>       update_etc_os_release \
>           --build-id "${BUILD_ID}" --variant "${DESCRIPTION}"
>   }
> +
> +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
> +image_postprocess_machine_id() {
> +    # systemd(1) takes care of recreating the machine-id on first boot
> +    sudo rm -f '${IMAGE_ROOTFS}/etc/machine-id'
> +}
>