| Message ID | 20250531110022.3843938-1-johannes.schneider@leica-geosystems.com |
|---|---|
| Headers | show |
| Series | add support for building "system extension images" | expand |
Hi Johannes, thank you for sharing you approach! I few quick notes that came to my mind when scrolling through the patches/cover letter. Am Samstag, dem 31.05.2025 um 13:00 +0200 schrieb Johannes Schneider via lists.openembedded.org: > This patch-stack adds support for building "system extension images" to meta-oe - to quote the > man-page [1]: > "The primary use case for system images are immutable environments where debugging and development > tools shall optionally be made available, but not included in the immutable base OS image itself > (e.g. strace(1) and gdb(1) shall be an optionally installable addition in order to make > debugging/development easier). System extension images should not be misunderstood as a generic > software packaging framework, as no dependency scheme is available: system extensions should carry > all files they need themselves, except for those already shipped in the underlying host system > image. Typically, system extension images are built at the same time as the base OS image — within > the same build system." > > Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html The interesting part system extensions should carry all files they need themselves, except for those already shipped in the underlying host system image. is not really addressed yet by the class, since it takes a conventional rootfs image recipe, adds a version file and ensures that the removal of 'os-release' works around the sanity check. To better solve this, I guess we would need a way to either split the sysext content from the rootfs before generating both, or, a proper way to create a 'non-rootfs', i.e. a file system that does not contain the default rootfs files, etc. I'd assume these base questions are relevant for a number of similar problems, too. Like for creating layered containers. For now, to not give the impression of being a generic solution for creating systext's, maybe one should rename the class to reflect its for a rootfs or covers only the version file generation so far? E.g.: systemd-sysext-rootfs.bbclass. > These patches are added to meta-oe - instead of oe-core - because systemd-repart-native requires > 'cryptsetup' to build discoverable-disk-images with verity and optional signature partitions - and > cryptsetup is currently only/still in meta-oe. This could also be a point where one might consider moving it to oe-core, since it provides 'core' functionality for creating encrypted system setups, which becomes more and more relevant, e.g. for properly protecting sensitive personal data. > Note that erofs-utils and systemd-repart-native have to be of a recent version, to support > features like compression and signing through PKCS#11 (e.g. as provided by the > classes/signing.bbclass) > > As an example consider this simple image recipe: > SUMMARY = "An example image to showcase a system extension image." > LICENSE = "MIT" > inherit discoverable-disk-image sysext-image > IMAGE_FEATURES = "" > IMAGE_LINGUAS = "" > IMAGE_INSTALL = "gdb" This example might be quite helpful to see how the class intents to be used. As it will get lost when patches are merged, maybe move it to the class inline documentation or at least into the corresponding commit message? Regards, Enrico > After building, the resulting 'extension-image-example-*sysext.rootfs.ddi' can be deployed to an > embedded system (running from a RO rootfs) and 'merged' into the OS by following steps: > place a symlink into the systemd-sysext image search path: > $> mkdir /run/extensions > $> ln -s /tmp/extension-example.sysext.ddi /run/extensions/example.raw > list all available extensions: > $> systemd-sysext list > and enable the found extensions: > $> SYSTEMD_LOG_LEVEL=debug systemd-sysext merge > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#117678): https://lists.openembedded.org/g/openembedded-devel/message/117678 > Mute This Topic: https://lists.openembedded.org/mt/113393897/3616721 > Group Owner: openembedded-devel+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [ejo@pengutronix.de] > -=-=-=-=-=-=-=-=-=-=-=- >
Hoi > > thank you for sharing you approach! > :-D > > I few quick notes that came to my mind when scrolling through the patches/cover letter. > > Am Samstag, dem 31.05.2025 um 13:00 +0200 schrieb Johannes Schneider via lists.openembedded.org: > > This patch-stack adds support for building "system extension images" to meta-oe - to quote the > > man-page [1]: > > "The primary use case for system images are immutable environments where debugging and development > > tools shall optionally be made available, but not included in the immutable base OS image itself > > (e.g. strace(1) and gdb(1) shall be an optionally installable addition in order to make > > debugging/development easier). System extension images should not be misunderstood as a generic > > software packaging framework, as no dependency scheme is available: system extensions should carry > > all files they need themselves, except for those already shipped in the underlying host system > > image. Typically, system extension images are built at the same time as the base OS image — within > > the same build system." > > > > Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html > > The interesting part > > system extensions should carry all files they need themselves, except for those > already shipped in the underlying host system image. > > is not really addressed yet by the class, since it takes a conventional rootfs image recipe, adds a > version file and ensures that the removal of 'os-release' works around the sanity check. > very good observation - yes, the extension/overlay would bring along all files that the additional packages (recursivly) rdepend upon - regardless of whether they are already in the rootfs or not - so ATM the overlay is not a true delta to "some underlying rootfs", but more a self-contained/-complete rootfs (which a "systemd portable service" would require... but different topic ;-) the blessing/curse is that the extension image is larger then it would need to be, but also brings along exactly the library version $some_tool depends upon roughly a year ago i tried to upstream an approach to construct such delta images: https://lore.kernel.org/openembedded-core/4a6b60ec8200956e25e031cd28bf1023cf02df3f.camel@linuxfoundation.org/t/#u but it ended up bouncing off of the testing infrastructure (which isn't easily accessible or spun up locally) ... that's why it ended up at v11, which finally passed the CI but then got dropped alltogether :'-( > > To better solve this, I guess we would need a way to either split the sysext content from the rootfs > before generating both, or, a proper way to create a 'non-rootfs', i.e. a file system that does not > contain the default rootfs files, etc. > > I'd assume these base questions are relevant for a number of similar problems, too. Like for > creating layered containers. > ATM i'm not aware of anyone/thing doing sth like layering images (for containers or rootfs) that actually build only delta-images and then stack them back together - or did i just miss sth like this? > > For now, to not give the impression of being a generic solution for creating systext's, maybe one > should rename the class to reflect its for a rootfs or covers only the version file generation so > far? E.g.: systemd-sysext-rootfs.bbclass. > > > These patches are added to meta-oe - instead of oe-core - because systemd-repart-native requires > > 'cryptsetup' to build discoverable-disk-images with verity and optional signature partitions - and > > cryptsetup is currently only/still in meta-oe. > > This could also be a point where one might consider moving it to oe-core, since it provides 'core' > functionality for creating encrypted system setups, which becomes more and more relevant, e.g. for > properly protecting sensitive personal data. > and systemd uses (lib)cryptsetup in many places... should i move the whole patchstack over there? opinions of the layer maintainer(s)? (-: > > > Note that erofs-utils and systemd-repart-native have to be of a recent version, to support > > features like compression and signing through PKCS#11 (e.g. as provided by the > > classes/signing.bbclass) > > > > As an example consider this simple image recipe: > > SUMMARY = "An example image to showcase a system extension image." > > LICENSE = "MIT" > > inherit discoverable-disk-image sysext-image > > IMAGE_FEATURES = "" > > IMAGE_LINGUAS = "" > > IMAGE_INSTALL = "gdb" > > This example might be quite helpful to see how the class intents to be used. > As it will get lost when patches are merged, maybe move it to the class inline documentation or at > least into the corresponding commit message? > good idea will do (with the next version) > > > Regards, Enrico > > > After building, the resulting 'extension-image-example-*sysext.rootfs.ddi' can be deployed to an > > embedded system (running from a RO rootfs) and 'merged' into the OS by following steps: > > place a symlink into the systemd-sysext image search path: > > $> mkdir /run/extensions > > $> ln -s /tmp/extension-example.sysext.ddi /run/extensions/example.raw > > list all available extensions: > > $> systemd-sysext list > > and enable the found extensions: > > $> SYSTEMD_LOG_LEVEL=debug systemd-sysext merge > >