On Fri, Feb 28, 2025 at 5:28 PM Alexis CELLIER <alexis.cell...@smile.fr> wrote:
>
> On Fri, Feb 28, 2025 at 5:33 PM Alex Kiernan <alex.kier...@gmail.com> wrote:
> >
> > On Fri, Feb 28, 2025 at 3:57 PM Alexis CELLIER <alexis.cell...@smile.fr>
> > wrote:
> > >
> > > On Wed, Feb 26, 2025 at 11:43 AM Vyacheslav Yurkov via
> > > lists.openembedded.org <uvv.mail=gmail....@lists.openembedded.org>
> > > wrote:
> > > >
> > > > On 25.02.2025 15:48, Ross Burton wrote:
> > > > > On 20 Feb 2025, at 15:33, Vyacheslav Yurkov <uvv.m...@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.kier...@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.
> > >
> > > At the moment on master, as systemd-systemctl python script touch the
> > > file, we can end up with an empty file independently of the
> > > IMAGE_FEATURE read-only-rootfs. So we do break the ability of
> > > firstboot in any case.
> > > Also, if you boot with your rootfs in ro (KERNEL_ARGS, wic, ...)
> > > without setting read-only-rootfs, with fstab that will remount your
> > > rootfs in rw (so you do not have a read-only rootfs), not having the
> > > /etc/machine-id file will make systemd fail (no not having
> > > /etc/machine-id seems dangerous te me).
> > >
> > > So why not put "uninitialized" in /etc/machine-id all the time
> > > (probably in rootfs post commands, if the file does not exist yet, to
> > > allow user to put a predefine one), it allows firstboot and prevent
> > > the dangerous case of not having the file. The only strange case would
> > > be when you do have a read-only filesystem, as you will always have a
> > > first boot.
> > > But if we do not want that strange behaviour by default, we can empty
> > > /etc/machine-id in case of read-only-rootfs (in rootfs post commands),
> > > or we let the decision to the user by letting him choose using the
> > > systemd PACKAGECONFIG to enable/disable the firstboot support.
> > >
> >
> > firstboot usage, really doesn't feel like a piece of package
> > configuration to me, possibly distro config, but having a
> > (potentially) interactive boot seems like an outlier in the OE world
> > (though I'm not saying it shouldn't be supported).
>
> It is already a PACKAGECONFIG of systemd, not enabled by default (not
> sure it was clear in my previous message).
>
I didn't look... though that's not unreasonable - I was thinking of it
as PACKAGECONFIG controlling whether firstboot happens.
> > Today we call the systemctl script as part of rootfs construction
> > which may touch /etc/machine-id, removing it from there and having it
> > obviously in one place as part of rootfs construction seems like it
> > ought to be an improvement.
>
> I do agree.
>
> I do have a question, it is possible to not end up with the
> /etc/machine-id file, i.e. not having the python script called (on
> master)?
You can - if you add stateless-rootfs to IMAGE_FEATURES then systemctl
isn't called at image construction time, hence this part of the
comment in the script:
# 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.
--
Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#212079):
https://lists.openembedded.org/g/openembedded-core/message/212079
Mute This Topic: https://lists.openembedded.org/mt/111267385/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
