On Tue, 2025-02-25 at 14:23 +0200, Mikko Rapeli wrote:
> Hi,
>
> On Tue, Feb 25, 2025 at 11:21:59AM +0000, Richard Purdie via
> lists.openembedded.org wrote:
> > On Thu, 2025-02-20 at 16:03 +0000, Alex Kiernan via lists.openembedded.org
> > wrote:
> > > On Thu, Feb 20, 2025 at 3:52 PM Vyacheslav Yurkov via
> > > lists.openembedded.org <uvv.mail=gmail....@lists.openembedded.org>
> > > wrote:
> > > >
> > > > From meta/classes-recipe/rootfs-postcommands.bbclass:
> > > >
> > > > # 20:12 < mezcalero> koen: you have three options: a) run
> > > > systemd-machine-id-setup at install time, b) have / read-only and an
> > > > empty file there (for stateless) and c) boot with / writable
> > > > touch ${IMAGE_ROOTFS}${sysconfdir}/machine-id
> > > > fi
> > > >
> > > > We could think of further improvements. One thing that comes to mind is
> > > > changing systemd-systemctl-native to systemd-tools-native and enable the
> > > > build of systemd-machine-id-setup.
> > > >
> > > > Slava
> > > >
> > >
> > > 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!
> >
> > I just wanted to add that we've been seeing an odd failure on meta-arm on
> > the autobuilder:
> >
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/1032
> >
> > and when I did into this, I see this in the logs:
> >
> > [ 3.700441] systemd[1]: Hostname set to <sbsa-ref>.
> > [ 3.704040] systemd[1]: System cannot boot: Missing /etc/machine-id and
> > /etc is mounted read-only.
> > [ 3.704488] systemd[1]: Booting up is supported only when:
> > [ 3.705023] systemd[1]: 1) /etc/machine-id exists and is populated.
> > [ 3.705349] systemd[1]: 2) /etc/machine-id exists and is empty.
> > [ 3.705651] systemd[1]: 3) /etc/machine-id is missing and /etc is
> > writable.
> > [ 10.206513] systemd[1]: Populated /etc with preset unit settings.
> > [ 13.034155] systemd[1]: Queued start job for default target Graphical
> > Interface.
> > [ 13.149568] systemd[1]: Created slice Slice /system/getty.
> >
> > We therefore need to fix the issue with machine-id before we can merge
> > this patch. I will drop it from master-next in the meantime due to this
> > issue.
>
> I think option 2) should be simple. IMO this could also be done by
> image/rootfs
> classes or base-files when systemd is the init.
>
> Where is build
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/1032
> adding "read-only-rootfs" to IMAGE_FEATURES?
It isn't a read only image, just that it seems the filesystem is
mounted ro at this point in the boot. Maybe timing related?
> The failures log from step 22, full log in
> https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/1586278/raw_inline
> only shows issues with sshd server, which IMO is not installed to any of the
> built images. The builds are IMO missing IMAGE_FEATURES +=
> "ssh-server-dropbear"
> which in meta-arm kas builds is set with ci/testimage.yml.
Those images do contain an ssh server, it just isn't taking connections
for some reason.
> Even the core-image-minimal tests are passing without any communication with
> target qemu machine:
>
> * ping.PingTest.test_ping with slirp pings localhost, not target machine
> * parselogs.ParseLogsTest.test_get_context doesn't talk with booted qemu
> machine
>
> How to get to the qemu boot log which shows the systemd errors above?
I had to ssh into the autobuilder worker in question to obtain it
unfortunately.
> I don't see the connection between the systemd error and the build above.
> I could propose patches to the issues if I can figure out where :/
Ross was able to reproduce by including the patch in this thread,
building and then running testimage against core-image-sato/core-image-
weston. I'd note those tests are using slirp which may or may not be
related. The issue is therefore reproducible to some degree at least.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211879):
https://lists.openembedded.org/g/openembedded-core/message/211879
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]
-=-=-=-=-=-=-=-=-=-=-=-
