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?
When released, will it also support updating the system by downloading a new layer (for efficiency)?
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?
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?
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?
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.
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?
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.
From what I know so far, this is unlikely and, by the way, we still donât have a name for the initiative itself.
I personally donât fully understand this question. Perhaps more explanation would be helpful.
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.
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?
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?
Letâs hope some of the developers can clarify how layers are added/processed with the base image!
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.
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!
So, hopefully a beta release during version 44 and a stable release 45. As a early adaptor I could try the beta release and see if itâs stable enough.
I voted for the name Fedora Atomic!
The fact that it can be combined with either composefs (Fedora) and systemd-sysupdate (GNOME OS) means it is independent of those two projects.
Iâm not sure if youâre aware, but in case youâre notâAtomic Desktops bootable container images have been around for quite some time, but are considered unofficial simply because theyâre not built on Fedoraâs infrastructure. Although technically unofficial, they are the de facto reference until we can build the images using Konflux, which is one of the key goals of the Atomic Initiative. These images are maintained by the Fedora Atomic Desktops SIG and are used and tested extensively, for example by the Universal Blue project.
I have personally used them for quite some time and can try to assist you in case you decide to try them. Here are the brief instructions on how to do it:
Would anyone be willing to share their bootc containerfile as an example? I want to start playing with it in a VM and eventually switch over from rpm-ostree on my hardware, but am just unsure of what all to put in there.
Custom OS builds are appropriate If youâre making non trivial changes to the base OS, otherwise layering using rpm-ostree is fine, even if you rebase to a bootable container image.
Do I get it right and these are still based on rpm-ostree? Or do they you use composefs under the hood (like Fedora 43 Silverblue)?
I think I wait until there is an official beta version of Fedora with bootc and composefs. That will also be an opportunity to clean up my files and do a complete reinstall of the system.
As already mentioned, currently, the entire technology is based on OSTree. One major difference is that with bootable containers you can build the system using Containefile/Dockerfile and Podman. Another is that they use standard OCI/Docker containers as a transport and delivery format for base operating system updates.
Not for Fedora 44 but this is the plan eventually.
Yes, because Fedora Atomic Desktops is for the group (all Fedora Atomic variants using various desktops) and then Fedora Silverblue is specifically for the one with the GNOME desktop. In another thread, there is a discussion on-going to start using âFedora Atomicâ again to name the group of all bootc/rpm-ostree based deliverables in Fedora.
There isnât a specific protocol as itâs a common behavior with container tools to only pull the layers that are not already on the disk. Under the hood this is implemented using the skopeo tool.
dm-verity does not operate at the file level but at the block level because it works with disk image which are block devices. It does not know when a specific file changed. This is the core difference with composefs.
The bootc version of GNOME OS is based on the content of GNOME OS but does not use systemd-sysupdate as it uses bootc. The principle behind Bootable Containers is flexible enough that you can pull OS content from any distribution and make a Bootable Container for it. Here the folks took the content in GNOME OS and made a Bootable Container image out of it.
Sorry, I meant a beta version of it. I think we can expect that? When there is a beta version I want to try it out! I do have a few rpm packages that I need to layer, so that should be possible.
I do like the name Fedora Atomic. Have been think if you could use the name of atomic particles as the names of the individual distributions (Silverblue, Kinoite, etc), but the names of the particles arenât very suitable.
Ah, thanks good to know! So during the first time of the installation, you install the base image and after that only the layers? Will the Anaconda installer use an OCI image for this? Or is this planned later?
Ah okay, but we could agree that an image is a collection of files cryptographically hashed together (using a merkle/hash tree)? It is the hashing that links the files together?
Oh, really, so itâs the content of GNOME OS without systemd-sysupdate! But I think it can be combined with systemd-sysupdate? Is this possible? Just trying to understand the boundaries of the different applications.
I saw there is already a mobile version of Fedora with bootc; Pocketblue. Very interesting! One day I hope the have a version of Fedora Mobile with bootc, composefs and a responsive version of the GNOME desktop on my Fairphone 4 .
Thanks for all your hard work on bootc and composefs!
Bootable container base images are already split into layers so when bootc updates the system it only has to download the layered that changed.
Initially the installation ISO will be generated from a bootable container image but wonât be a bootable container system itself. In the end, we should have everything be a bootable container system.
Not really. Disk images do not necessarily come with integrity metadata and thatâs not what makes then disk images. Disk images are block devices and are usually a filesystem image (squashfs, erofs, ext4, etc.). Then dm-verity metadata is added to them to add integrity. Dm-verity has no knowledge about the files in the image.
Not really. The way systemd-sysupdate and bootc do updates is fundamentally different.
Yes, I was aware of this. Right now I donât have the time, but when you need a user to test a possible new implementation (systemd-sysext?); let me know! As I understand, systemd-sysext layers a package on top the current filesystem?
Oh really, I didnât know this (that the image all ready consists of multiple layers).
I was not talking about disk images, I meant systems like rpm-ostree and composefs. They do work on the file level, not?
.
