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 :( Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200592): https://lists.openembedded.org/g/openembedded-core/message/200592 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] -=-=-=-=-=-=-=-=-=-=-=-
