I’ve been using Kinoite for quite a while now and I love the concept! From time to time, I encounter problems with updated software I use inside distrobox containers, so I thought about building my own base image that would include all the stuff that really isn’t supposed to break because I need it on a daily basis (like some basic development tooling or TeXLive, but also rather uncommon stuff from copr or self-built packages). Because this software spans a few (not always super-stable) repositories, and can get larger than the whole base image, a custom image seemed like a good fit in contrast to layering.
I evaluated whether I should use rpm-ostree or go “full-bootc” and figured out that composing these images via rpm-ostree may work better for my needs, due to more advanced chunking-features (I don’t want to download a full TexLive build with every update after all!).
So I went ahead, checked out workstation-ostree-config and created a treefile based on kinoite.yaml. I built it like this, similar to the command mentioned in the docs:
I could take the resulting image, push it to my registry and rebase my kinoite system onto it. Great!
However, I’m a bit lost on how to generate updated container images. If I understand the documentation correctly, the above command should also work for updating the generated image, such that unchanged layers stay unchanged. However, when running it for a second time, I always end up getting a Subprocess failed: ExitStatus(unix_wait_status(134)) error referencing chunking.rs from os-tree-ext (this line; left: 1615, right: 0). Unfortunately, the backtrace is meaningless due to missing debug symbols.
So - am I using it wrong? Is it supposed to work like this? If yes, I would probably to proceed to build rpm-ostree+bootc/ostree-ext from git and report the bug upstream if it persists. If not, I would welcome any advice on how I could structure my workflow in order to be able to generate as-small-as-possible update packages on a regular basis.
I would suggest you re-evaluate whether to use rpm-ostree or create either a base bootc image “from scratch”, or a derived bootable container image, as already recommended.
I’ve been using distrobox containers for this for quite a while now, but unfortunately sometimes something breaks after updating. I guess that could be solved by using dedicated and tagged podman containers for everything, but especially if this is related to GUI software like VSCode oder TeXStudio I’m afraid this would get complicated wrt. desktop integrations. Also I find that I end up duplicating a lot of stuff like git, basic gui libraries, breeze icons, et cetera. So the idea was to just have everything bundled into a custom base image that is versioned and can be rolled back by booting a previous version (so I’d also get rid of the duplicates). Now that I think of it, this could also be solved by some kind of “mega-container”
Then again, my CI/Container server is a bit light on available space and bandwidth so I’d also need to think about chunking. In my experience, there are some significant difficulties to manage and reuse layers using Containerfiles because there’s often something that’s a tiny bit different (e.g. the rpm db, which I still need for subsequent RUNs). I also had my problems with rechunk in the past, maybe it’s time to try that again.
Unfortunately, this is reproducible and happens on every build. I think I found the mistake, however: I was under the impression that the path to the tar file needed to point to an existing tar file on subsequent runs, so that rpm-ostree could figure out the previous chunking configuration. This doesn’t seem to be the case however. The chunks seem to be identical even without reusing an existing cache or layer-repo. I think I’ll need to have a closer look on how all of this works in detail.
Thanks! This is really similar to what I’m trying to achieve
Moreover, I learned about rpm-ostree experimental compose build-chunked-oci which seems to do pretty much what I want. In general, I would love to use Containerfiles over Treefiles.
I’ve been using a similar bootable container image (based on the Silverblue version) inspired by this project as my daily driver for quite some time now. Again, I highly recommend it.
That said, while building multiple images independently from each other (when rpm-ostree is invoked with -i every time) mostly works, even for chunking, I still think the command from my first post should work but doesn’t. When I do not specify -i and give it a path to a not-yet-existing target, I get the following error, which of course makes sense:
error: failed to invoke method OpenImage: failed to invoke method OpenImage: creating temp directory: archive file not found: "/build/archive2.tar"
When giving it the path to the previous ociarchive I (reproducibly) get the error from my first post about a failed assertion in chunking.rs (I have verified that the referenced line is still the same compared to main):
Generating container image
error: Subprocess failed: ExitStatus(unix_wait_status(134))
thread 'tokio-runtime-worker' panicked at /builddir/build/BUILD/rpm-ostree-2025.8-build/rpm-ostree-2025.8/vendor/ostree-ext/src/chunking.rs:368:9:
assertion `left == right` failed
left: 1615
right: 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Regardless of the how the image is built (I see that there may be better ways - like the one mentioned above - by now), could someone with a little bit of knowledge about rpm-ostree internals maybe have a guess at whether I’m just doing it wrong™ or if this is actually a bug?
