Re: [OE-core] [PATCH v11 0/3] pkg-database and systemd-sysext image

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

Hello,

On 13/06/2024 07:44:59+0100, Richard Purdie wrote:
> On Tue, 2024-06-04 at 08:50 +0200, Johannes Schneider wrote:
> > systemd-sysext allows to overlay another image (or multiple) ontop of
> > a "base-image" = the current rootfs, via the use of overlayfs; to add
> > tools and features meant for development purposes.
> > 
> > To quote the documentation on systemd-sysext:
> > " ...addition in order to make debugging/development easier). System
> > extension images should not be misunderstood as a generic software
> > packaging framework, ..."
> > 
> > To build a lean image, that only holds packages that are not already
> > part of the base-image, a snapshot of the package-database is taken
> > after the installation of the base-rootfs is done, and picked up
> > again
> > when collecting the rootfs of such a extension image.
> > 
> > with all this in place an example usage could look like this:
> > some-core-image.bb
> > � inherit core-image
> > � IMAGE_GEN_PKGDBFS = "1"
> > 
> > extending-image.bb
> > � inherit image-sysext
> > � IMAGE_FSTYPES = "squashfs"
> > � IMAGE_BASE_PKGDB = "some-core-image"
> > � # the above pointing at a package-db similar to:
> > � # build/deploy/images/$MACHINE/some-core-image-$MACHINE-
> > 20240210172305-pkgdb.rootfs.tar.gz
> > 
> > then on the device, running some-core-image, with the extension image
> > placed at FN:
> > $> ln -s "$FN" /run/extensions/$(basename $FN).raw
> > $> systemd-sysext list
> > $> SYSTEMD_LOG_LEVEL=debug systemd-sysext merge
> > 
> > As long as the VERSION_ID of the extension image matches the os-
> > release
> > in the base image, the above commands return sucessfully;
> > for details on the compativility check see the docs for systemd-
> > sysext.
> 
> I'm unsure what to so with this series/change.�I'm a bit worried that
> it is copy and pasting the debugfs image code to another form and once
> we have this form, I suspect others will then also want things to be
> added for other image update use cases or similar. That code is already
> hard to read and this is not going to improve that. I can understand
> the use case for the code though and I can certainly see why you'd want
> this code upstream as it would be hard to maintain standalone. Having
> the tests do help but the also illustrate this all feels a bit fragile.
> 
> I've just seen further failures in testing:
> 
> https://valkyrie.yoctoproject.org/#/builders/76/builds/55/steps/14/logs/stdio
> https://valkyrie.yoctoproject.org/#/builders/35/builds/47
> https://valkyrie.yoctoproject.org/#/builders/48/builds/16
> https://valkyrie.yoctoproject.org/#/builders/54/builds/57
> 
> and https://valkyrie.yoctoproject.org/#/builders/23/builds/58 will
> probably fail too but is currently still building.
> 
> What really worries me about these failures is that there isn't a good
> error message, so if this happens some time in the future we're going
> to be scratching our heads wondering what is wrong. I'm worrying this
> is going to be particularly hard to maintain and keep working in the
> future.
> 
> In many ways I'm wishing there was an API you could hook into so that
> the core project didn't need to take on the responsibility for this
> complexity.
> 
> Regardless, unfortunately we're still not to the bottom of the failures
> as evidenced above :(

I'm actually surprised it failed for you as v11 was successful on the AB
for me. Anyway, In the meantime, I dropped the series.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com