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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200601): https://lists.openembedded.org/g/openembedded-core/message/200601 Mute This Topic: https://lists.openembedded.org/mt/106478182/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
