public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
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>
Subject: Re: [PATCH 3/3] image-postproc-extension: add removal of machine-id
Date: Wed, 29 May 2019 13:06:44 +0200	[thread overview]
Message-ID: <20190529130644.3fa8be7c@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <10cc6729-ddae-141d-abaa-43081707fd84@siemens.com>

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'
> >> +}  
> >   
> 


  reply	other threads:[~2019-05-29 11:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28  8:58 [PATCH 0/3] Filesystem mounting and machine-id fix claudius.heine.ext
2019-05-28  8:58 ` [PATCH 1/3] wks: added 'rw' to kernel arguments claudius.heine.ext
2019-05-28 17:29   ` Henning Schild
2019-05-29  6:38     ` Claudius Heine
2019-05-28  8:58 ` [PATCH 2/3] image.bbclass: remove fstab generation claudius.heine.ext
2019-05-28 17:34   ` Henning Schild
2019-05-29  6:47     ` Claudius Heine
2019-05-29 11:11       ` Henning Schild
2019-05-28  8:58 ` [PATCH 3/3] image-postproc-extension: add removal of machine-id claudius.heine.ext
2019-05-28 17:44   ` Henning Schild
2019-05-29  7:00     ` Claudius Heine
2019-05-29 11:06       ` Henning Schild [this message]
2019-05-28 19:51   ` Henning Schild
2019-05-29  7:00     ` Matthias Luescher
2019-05-29  7:06       ` Claudius Heine
2019-06-06 17:18   ` Maxim Yu. Osipov
2019-06-04 20:09 ` [PATCH 0/3] Filesystem mounting and machine-id fix Maxim Yu. Osipov
2019-06-05  6:45   ` Claudius Heine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190529130644.3fa8be7c@md1za8fc.ad001.siemens.net \
    --to=henning.schild@siemens.com \
    --cc=ch@denx.de \
    --cc=claudius.heine.ext@siemens.com \
    --cc=isar-users@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox