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'
> >> +}
> >
>
next prev parent 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