Re: [OE-core] [PATCH v6] systemd: Build the systemctl executable

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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.com@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