how do i mage sure the user gets the correct extensions when updating
how do i mage sure the user gets the correct extensions when updating
Nyeah, that's true.
Fi thought that akmods & kernel is tightened since latest tries
Awell wrong kernel got into the image
Fbut yeah, I get some build errors since 2 days ago cuz of akmods
Ajust put it in there dont think about it
Aand start slowly migrating to using the akmod kernel
Bthis is where the right tooling/packaging come in to play. when sysexts are built with the base OS image, it's just a matter of wiring things up.
Band now we're one step closer (tm)
Band then we're done
Aexactly
Abut we're doing oci, sysext is squash
Band that won't stop us from building them 
Awill stop you from hosting them lol
Bit doesn't have to be, your fs can come from anywhere including an OCI image
Eit's pretty straightforward to automatically build a squashfs artifact from an OCI image; or you could host a squashfs file in an OCI image
KYep, we'll just need some kind of distribution and update method. Both for package updates in the extensions, and for OS updates since you have to specify an OS version and ID they're designed for
Athats news to me
Athis is how i'd do it at least
Bman systemd-sysext -- System extensions are searched for in the directories /etc/extensions/, /run/extensions/ and/var/lib/extensions/. The first two listed directories are not suitable for carrying large binary images,
however are still useful for carrying symlinks to them. The primary place for installing system extensions is
/var/lib/extensions/. Any directories found in these search directories are considered directory based
extension images; any files with the .raw suffix are considered disk image based extension images. When
invoked in the initrd, the additional directory /.extra/sysext/ is included in the directories that are
searched for extension images. Note however, that by default a tighter image policy applies to images found
there, though, see below. This directory is populated by systemd-stub(7) with extension images found in the
system's EFI System Partition.
Jwe'd just build them regularly in github afaict? like how flatcar does it?
Byou can just create a dir in /var/lib/extensions (with the right layout and contents) and apply it.
KEnd users need some way to make sure their extensions are up to date
Awheres oci
Byes, but they'll have to be built for the correct base.
Ai cant see it
KIf I'm on Fedora 40 and upgrade to 41, my existing extensions are now invalidated unless they also update
Bthat's the tooling and pipeline we need to build
Jright, we'll need to version for F41, etc.
KWe also don't want to ship extensions that may or may not have security implications without a way to update those extensions
Aid hope for fedora 41
Abut the problem is day to day
Ayou also need to update it
Aas far as i understand it
Aie 240420 image has different extensions than 240424
Athey have to be pinned to the exact image
Jall the docs I've read point to the extension living in /var/lib/extensions
Bthere is a new download service in systemd 256 we can use
NIs there a way to build tooling to utilize other existing tooling? Or is there no way to achieve that? What I hope to see avoided is yet ANOTHER way to package linux packages.
Jand a service just updates a new one in place
Afrom everything i read, sysext is the brother to sysupd and they are designed for each other
Awe're in the bootc camp, theres some conflict with that
Ecould we provide a similar maintenance/usage pattern for updating sysexts as what was described in the video introducing logically bound images to bootc?
Asysupd also uses squashfs images
Jwhy is there conflict?
Aessentially the design of sysext is get your image with sysupd which is squashfs
Athen apply the sysexts which are also squashfs
NAthe systems are designed for each other
Ae.g, you'd host both on an HTTP host
Awhen using with ostree oci you get conflicting delivery methods for the base image and the extensions
