Hoi,
and thanks for taking the time to look into this patch-set! > > 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. > > IIRC you mentioned in a past mail that you're not "too fond" of the debug-fs or it's (current] implementation - is it an inherited/legacy functionality thtat's hard to move elsewhere or what is the background/history there? Granted, the code looks similar because it hooks in at the same point in the image generation, also operates on the package(s) level, and was in part based on how the debug data is handled. The "feels a bit fragile" is most likely because i have/had to iterate a lot over these patches because i've got not a full/good grasph of the complex test&build infrastructure (and can't easily replicate/reproduce it locally :-S) At the last iteration almost all build variants where 'Ok', with one exception around an "already present" ipkg in the build environment image. > > > > I've just seen further failures in testing: <snip>mangled links</snip> > > 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. > > Im very open for suggestions on how to increase the verbosity = pointers/hints are appreciated :-) I've tried to be verbose/to the point with error messages in the actual code; or are you looking for more verbosity or different messages in the tests (what and how? - since i'm unsure what would be helpful in the build/test infrastructure; it seems to me that not all messages make it through to the logs visible in the web-ui). > > > > 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. > > Like "image generation step hooks"? im not sure that all necessary information can easily be exposed, passed along, or tested! - that code could end up being more complicated than the current form that does it "just in place directly". If there where an API, where would the code then live - if not in the core? (and who would test it how?) > > 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. Aww, we were getting close; so the last iteration fixed the one remaining/troubling exception with the arm64+ipk? :-) gruß Johannes
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200654): https://lists.openembedded.org/g/openembedded-core/message/200654 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] -=-=-=-=-=-=-=-=-=-=-=-
