A few questions about bootc and composefs

Hello Fedora administrators and developers!

I have a few questions about bootc and composefs:

  1. I saw the discussion about Renewing the Fedora bootc initiative. If I understand it right, there will be a beta version of a new version of Fedora Silverblue with bootc and composefs during the release of Fedora 44? Will Fedora Silverblue also get a new name?
  2. When released, will it also support updating the system by downloading a new layer (for efficiency)?
  3. Maybe a stupid question, but a layer is just a file on the hard drive? And this layer is then merged/processed with the base image?
  4. Fedora Silverblue, bootc and composefs are all about images. Which definition of an image do you (developers of bootc/composefs) use? An image is just a bunch of files that are hashed together using a Merkle tree?
  5. Do I understand it right and bootc supports composefs and systemd-sysupdate? So it supports an object store like composefs and it supports an A/B boot system like systemd-sysupdate?
  6. Maybe a detailed question, but what are the steps of converting an OCI image into a composefs image? The main goal is to update the object store? This answer could give some clarity about how it all works together.
  7. What is the location of the composefs object store? Or in another words: where are all the files actually located? And where is all the metadata stored?

Thanks in advance :-)!

Scott Trakker

(Just an enthusiastic Fedora user)

I will try to answer the questions that I think I know the answers to. For the rest, you’ll probably have to wait a few days until Atomic Desktops maintainers return from their holidays leave.

  1. From what I know so far, this is unlikely and, by the way, we still don’t have a name for the initiative itself.

  2. I personally don’t fully understand this question. Perhaps more explanation would be helpful.

  3. It’s not a stupid question, and I personally don’t fully understand it either, but I’ll try to answer it anyway.
    The way I see it, applying an overlay results in a new image that is reproducible each time. The overlay operates by using a clean base image and applying all changes at once, ensuring that the image is always new rather than a build-up of previous edits.
    Utilizing bootc does not exclude the possibility of overlays; among the features currently in development is the integration of DNF and the capability to create overlays on bootc in a similar fashion.

The following link may also be generally informative, in case you are not already aware of it.

@hricky: thanks for thinking along!

  1. According to the Success Criteria they want to have ‘Beta/nightly rolling releases of base images (44)’. My interpretation of this, that there will be a beta version of the Fedora Atomic Desktops with bootc?
  2. For what I read it the past (somewhere on the Fedora wiki) the plan is the update the system by downloading a new layer of the image with all the (package) changes. My question is what the status of this is? Or in another words: how will updating a system with bootc and composefs work?
  3. Let’s hope some of the developers can clarify how layers are added/processed with the base image!

Have a good New Year!

The Fedora Atomic Desktops Bootable Container images have been around for quite some time, and the Universal Blue project uses them as the basis for their customizations. These images are currently built outside of the Fedora infrastructure and are therefore considered unofficial. As I understand it, one of the main goals of the renewed initiative is to help organize an environment that will ensure that these (and other) bootable container images are built inside Fedora.

Currently, both bootable container images and the classic OSTree use composefs. You may swap rpm-ostree upgrade for bootc upgrade, and so on. At this time, they perform the same operations in general. Yet, any modifications to the local state, such as installing or removing packages or using commands like rpm-ostree initramfs --enable, will cause bootc upgrade to fail.

There are various approaches to client-side package functionality at this point, and it’s not fully determined how it will be addressed.

Have a good New Year to you too!

The Fedora Atomic Desktops Bootable Container images have been around for quite some time, and the Universal Blue project uses them as the basis for their customizations. These images are currently built outside of the Fedora infrastructure and are therefore considered unofficial. As I understand it, one of the main goals of the renewed initiative is to help organize an environment that will ensure that these (and other) bootable container images are built inside Fedora.

Ah, if this is the point of the Fedora bootc initiative, then I probably have misunderstood it! I thought/hoped it meant that there would be a new offical version of Fedora with bootc and composefs.

As I mentioned, all Atomic Desktops variants currently use composefs. There are official Fedora Atomic Desktops bootable container images, but I wouldn’t recommend using them, for example because they are not signed.

We are already producing official but not recommended and unofficial but recommended bootable container images for the Atomic Desktops. See the " Compose Methods and Outputs" in https://pagure.io/workstation-ostree-config.

There are no plans to change the name of any Atomic Desktops.

Bootable Container images can (and usually are) split into multiple layers. When a new image is built, the layers that did not change are shared and are thus not re-downloaded on updates.

The layers are container image layers. Each layer is essentially a tarball of files + some JSON metadata. See the OCI image format: The OpenContainers Image Spec. How they are stored on the disk depends on the tool. bootc currently imports those into an ostree repository but soon we will use a native composefs repo instead.

The term “image” is ambiguous. Bootable Container systems use OCI container images, which are files in tarballs plus JSON metadata. If you use dm-verity for example then this is a disk image because it’s an image of a filesystem written to a block device.

Bootc currently uses ostree with composefs and soon pure composefs as backends. systemd-sysupdate is another way to do updates from the systemd projects and is unrelated.

Currently, bootc reads the content of the container images and imports it into the ostree repo. It then generate the composefs image that will be used at boot time for the system. i would recommend watching the following talks for more info:

Currently, everything is still in the ostree repo (/sysroot/ostree). Soon, once we move to the native composefs backend, it will be in (/sysroot/composefs).

And how is this related to the Renewing the Fedora bootc initiative? How would you describe what the goal of this initiative is? The plan is the have an official and recommended version of Fedora Atomic Desktops available with bootc and composefs at the launch of Fedora 44? As far as I know there is no change request for this, but this is the plan?


This can be confusing, because you have now two competing names: Fedora Atomic Desktop(-s) and e.g. Fedora Silverblue. Maybe the name Silverblue can be dropped in the future and you only call it Fedora Atomic Desktop GNOME.


So there is some kind of protocol that compares the local installed image with the new online image and then decides which layers to download?


Clear, thanks!


I read that dm-verity uses a hash tree, so that makes the image an image: a collection of files cryptographically hashed together.


But there is a bootc version of GNOME OS (which uses systemd-sysupdate), so I guess bootc can be combined with either composefs or systemd-sysupdate.


Thanks! I actually watched those two videos at that time!


Clear!

Thanks for answering the questions!

See:

See:

See: