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

[Mikko Rapeli <mikko.rapeli@linaro.org>]

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?

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.
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 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 :/

Cheers,

-Mikko