From: Vyacheslav Yurkov <uvv.mail@gmail.com>
To: Ross Burton <Ross.Burton@arm.com>
Cc: "Openembedded-core@lists.openembedded.org"
<Openembedded-core@lists.openembedded.org>,
Alex Kiernan <alex.kiernan@gmail.com>,
Mikko Rapeli <mikko.rapeli@linaro.org>
Subject: Re: [OE-core] [PATCH v6] systemd: Build the systemctl executable
Date: Wed, 26 Feb 2025 11:43:20 +0100 [thread overview]
Message-ID: <2b44ca06-2d0c-4df9-9d3b-76ac5dcf41cc@gmail.com> (raw)
In-Reply-To: <A5978220-EBAF-4C51-8587-76498A346624@arm.com>
On 25.02.2025 15:48, Ross Burton wrote:
> On 20 Feb 2025, at 15:33, Vyacheslav Yurkov <uvv.mail@gmail.com> wrote:
>> Isn't is supposed to be created on first boot?
>
> Yes, ish, but our rootfs is read only at this point:
>
> [ 7.639766] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only.
> [ 7.641135] systemd[1]: Booting up is supported only when:
> [ 7.641844] systemd[1]: 1) /etc/machine-id exists and is populated.
> [ 7.642588] systemd[1]: 2) /etc/machine-id exists and is empty.
> [ 7.643279] systemd[1]: 3) /etc/machine-id is missing and /etc is writable.
>
> On 20 Feb 2025, at 16:03, Alex Kiernan <alex.kiernan@gmail.com> wrote:
>> I do know that it was a horrible thing to get right when I rewrote the
>> shell script in python (which I'm very glad to see the back of):
>>
>> # If we populate the systemd links we also create /etc/machine-id, which
>> # allows systemd to boot with the filesystem read-only before generating
>> # a real value and then committing it back.
>> #
>> # For the stateless configuration, where /etc is generated at runtime
>> # (for example on a tmpfs), this script shouldn't run at all and we
>> # allow systemd to completely populate /etc.
>>
>> It may be that this behaviour was wrong in some cases, but at the same
>> time, I remember spending a lot of time getting this right!
> It certainly looks like it’s “tricky” to get the right semantics here because the range of potential use-cases is too great.
>
> I believe we should be writing /etc/machine-id at rootfs time if systemd is being used. Currently this is done in the systemctl class if it writes links, and then in the rootfs class if the rootfs is read-only.
>
> I think we should consolidate those into the rootfs class, and give the user the choice of whether to treat the image as booted or not by writing either “” or “uninitialized” to the file as per https://www.freedesktop.org/software/systemd/man/latest/machine-id.html#First%20Boot%20Semantics.
>
> tl;dr: if it contains “uninitialized” then this is the first boot, otherwise it’s not. By always touching the file we break the ability for anyone to use systemd-first-boot or ConditionFirstBoot in their own units, which seems wrong.
>
> We’re about a week from feature freeze and getting this merged would be great, do you think you can finish this off Slava?
>
> Thanks,
> Ross
I definitely gonna try. But I might be missing something, because I
thought it sums up as follows:
RO rootfs -> empty machine-id
RW rootfs -> no machine-id
And it does work that way when I rebuild my image with or without RO rootfs.
Richard, could you please point me out which test actually failed? I
looked at the logs, but most of them were "Skipped".
Does the test explicitly remount rootfs as RO perhaps?
The other option to have a real machine ID will probably mean to build
machine id and leave it up to a user to decide whether they want to have
such image. But I don't think it's wise to add this option now so it
ends up in the next release.
Slava
next prev parent reply other threads:[~2025-02-26 10:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 10:39 [PATCH v6] systemd: Build the systemctl executable uvv.mail
2025-02-20 14:07 ` [OE-core] " Ross Burton
2025-02-20 15:33 ` Vyacheslav Yurkov
[not found] ` <1825F47182B39BA0.23135@lists.openembedded.org>
2025-02-20 15:52 ` Vyacheslav Yurkov
2025-02-20 16:03 ` Alex Kiernan
2025-02-25 11:21 ` Richard Purdie
2025-02-25 12:23 ` Mikko Rapeli
2025-02-25 13:50 ` Richard Purdie
2025-02-25 14:48 ` Ross Burton
2025-02-26 10:43 ` Vyacheslav Yurkov [this message]
2025-02-28 15:56 ` Alexis CELLIER
2025-02-28 16:33 ` Alex Kiernan
2025-02-28 17:28 ` Alexis CELLIER
2025-02-28 21:09 ` Alex Kiernan
2025-03-04 9:27 ` Koen Kooi
2025-02-20 17:08 ` Ross Burton
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=2b44ca06-2d0c-4df9-9d3b-76ac5dcf41cc@gmail.com \
--to=uvv.mail@gmail.com \
--cc=Openembedded-core@lists.openembedded.org \
--cc=Ross.Burton@arm.com \
--cc=alex.kiernan@gmail.com \
--cc=mikko.rapeli@linaro.org \
/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