Flock 2026 Whats new in Fedora CoreOS in 2026?

All right, let's get started. Hi everyone. Um, Jean-Baptiste, I work in the CoreOS team at Red Hat and I contribute to Fedora CoreOS most of my time. >> Hello. I'm Joel Capitao. I'm software engineer working at Red Hat as well. Um, mainly on Fedora CoreOS and Fedora boot C as well. Um, I release a strong focus on the pipeline conflicts and so on. >> All right, so we're doing the usual yearly what's happening CoreOS this year. Uh, those have been done by Dusty Mabe uh, through the previous years. I'm trying to to fill that shoes. Uh, quick refresher on what's Fedora CoreOS. Uh, it's a container focused minimal OS. Uh, they the goal is treat your treat your machine as a container. So, you would like to re-spin a new VM whenever you need to make change and then think about it as a like immutable entity. It's an image-based system. And uh, yeah. Ship with Docker and Podman so you can choose whatever and run run your containers. So, new thing this year is not too much. Uh, we now we now support Proxmox as a main platform. And then uh, switch all of the running systems to pull their updates from Quay as OCI images. And a bit before Flock last year we moved new install to install from Quay and now we have all the now it's pulling from Quay. So, those are the the two main user-facing change that that we had this year. And uh, before I go on into like what change in the back end, I'll just uh, show a few metrics. Um, because yeah, not so much change which means F course is becoming kind of mature and stable and then users seems to like that. Uh, it's now the most popular uh, server edition of Fedora, I think, given [snorts] the stats. So, those are machines that are more than one one week old. Um, most of them are now Arch 64, uh, which is a huge bump from last year. Last year was almost like 50/50. Most of these, we think, because we can't really know, is Podman machine that ships with Podman Desktop on Macs. So, last week, actually, I filed a ticket with the Podman machine team, so they changed the OS release string, so maybe next year we'll see a different and then we'll be able to count those. Another interesting trend that we see is people tend to use their FCOS for longer. Uh, those are in red, the one week node, and in blue, more than one week node. And we see more and more people sticking with the with the FCOS install. And then, a last one is machine that get up for more than six months. So, that's erased that huge Fedora server, uh, yeah, Fedora Cloud blip that we saw in the previous one. And, uh, yeah, uh, 2/3 of the FCOS machine are there for more than six months, so people tend to stick around with CoreOS. So, what changed this year, but on the build side of CoreOS? That was most of the work of the year. We've have been doing a lot of BootC work. Um, we changed the build system to be container-native, so building Fedora CoreOS is now happening in a container build. And we also been working on using BootC install to file system to build the disk images, and this is now shipping in the Rawhide stream of, uh, of CoreOS. Um, yeah, so most of the work have been removed be removing the opinionated bits and building script that we have and then upstreaming those in BootC in image builder as much as possible to to reduce the specific CoreOS bits that we have. Another last change that shipped like a maybe a month ago or so is the OS build root that we use is now BootC images instead of CoreOS. So what that means is that for the Rawhide image of FCOS, we used the Rawhide, I don't know, mkfs binary instead of having like one fixed set of utilities that we'd use for all the variants. So like now each image is built with the matching stream. And what are we working on? And that's the part for Joel. >> Yeah, so what are we working on right now? So the the next plan. So more BootC, surprisingly. So you may ask yourself if we are still using doing CoreOS or if we are BootC now. But yeah, we are still CoreOS, but we try to be more BootC derivative. So yeah, the first bullet point is about generating the disk images. So right now we are using the OS build compile manifest, which is working really fine, to be honest. We are generating like more than 20 disk images in like 10 minutes, which is pretty fast. But we are not using the BootC tooling and we want to to move towards more the BootC tooling. So we have to to do some stuff about the um the in the image builder and boot C. Uh so we have to add some knobs to to customize the image builder pipelines for for the core OS. So we are working on that right now. The second point it's about the um decoupling the ignition part um from core OS. So there is actually a package, I mean the ignition package in Fedora, so you can install, but you won't have the integration files like the drag card configs files, the system D units and presets. Um so it's living right now in the Fedora core OS config main repo, and we want to move out from that repo and to ship all of these files within a a subpackage within the uh the main ignition package. So that way Fedora boot C will be able to to use ignition as a first boot installer, as well as all of the uh other derivatives like the atomic desktops. And the third point it's the testing suit. Um so right now we are yeah, in the testing suit in core OS, there is lot of test uh which are basically basic generic test that are not core core OS specifics at all. So there is no point to to run them in Fedora core OS, so we want to to upstream these test in the in the Fedora boot C as well. And the cool part of all of these things is that we will be able to to move to Conflux more easily. Uh so yeah, few words about Conflux. So it's um a CI/CD build system uh that tries to meet the SLSA level three requirements. So SLSA for those who don't know, it's um OpenSSF framework which um which tries to secure the supply chains as much as possible. And in this diagram, it's from the salsa.dev um website, you can see the supply chain threats. So, from the source at the left of the diagram to the end user. So, there is a lot of letters, A A to I, and this is all of these uh let's say the vector attacks that can can uh can appear in the supply chain. And salsa tries to address all of these uh vectors attack. Not not all of them, but most of them. And conflux it's uh opinionated implementations of um of this uh of this framework. And um so, yeah, we are working on that currently. Um So, the cool part with Fedora CoreOS is that we are container native, like conflux. Uh so, it makes a lot of sense for us to to use conflux um to modernize our supply chain, to be more secure. Um so, right now, we are just There is some missing spot, which is the disk images. So, we have We are building the raw image stream, um the container image with conflux. And then, we are still testing and releasing with the Jenkins pipeline. But uh very soon, we will be able to to do all of this within conflux. And the end goal of all of this is to be able to cosine verify the uh the coreos image uh and the end user will be able to verify the SBOM and also the provenance attestation. And uh And yeah, that's it. That's basically it Uh, for the for the conflicts. >> Done. >> Don't go and try that command. That doesn't work yet. We need to work with Jeremy to get that working. All right. Some uh, a few other things that we have in your in our radar uh, we want to move to split the container image that we produce using chunker. That would give us an increase increase layer count so we can have smaller updates. Uh, because so moving to CI is is need for the distribution side of thing. But one thing that we had before with the OS 3 repo was if your update doesn't happen much often but let's say your update is only one file change, you would only download one file. And then now with OCI, you would only download that layer that contain that file. And then using more layer allow us to decrease the network use for the for the updates. Another thing that would be nice is to have the ability for ignition to consume butane directly so that would avoid transpiling uh, butane to ignition before booting the VM. Um, because YAML is nicer to write than JSON. Uh, that's an opinion. Um, and then longer time IDs, those are like not I don't know if that happen but that's kind of a wish list. Uh, maybe maybe have some C6 factory in Fedora so we can distribute extension for FCOS that are supported and built from Fedora content. And um, and also working on supporting people that want to derive FCOS the boot C way. Uh, Gus talked about that yesterday. And one thing that you you can do today, but then you lose updates and you don't get support and then it would be nice to find a way to keep providing the update guidance that the FCOS team builds to derive the images. Maybe later, I don't know. Um Yeah, that's the last slide. Any suggestion ideas for FCOS questions? >> [applause] [applause] >> Uh I'm a happy Fedora CoreOS user. We run it for testing farm, so thank you. I'm just wondering like when we have image mode like will those two projects like somehow converge together because I'm always having this stupid question like if we have image mode, right? Uh like they're very much getting closer with the boot C support. So the only thing is the initialization maybe with butane and ignition or is there anything else why people would choose CoreOS and it seems like they're diverging together, right? So or converging together, sorry. So can you maybe explain that? >> So in a sense FCOS is a boot C distribution with opinions. Um and also we do a lot of testing and we provide automatic updates with uh guidance. We have this update graph where we are able to inject uh releases that the nodes have to go through. Let's say you have some boot loader migrating to code or something. Uh that's the main benefit of FCOS like you have a set of updates that you may skip and then some that you may not skip and so on. But in essence um FCOS is kind of just boot C with opinions. And also ready to consume. You can go and grab a QEMU image and boot it without having to build anything. Does that answer the question? >> So, I noticed there there was a strong association with the cloud native in the Conflux slide in the like for for where that's going. How does that relate back to common criteria? >> Common criteria, you mean? >> Yeah, the foundation requirements for for building in isolation. >> You mean hermetic builds? >> Not just the hermetic build, but like but but that is a key factor in in common criteria, yes. Most of the RPMs are built that way, so it's not it's not like it's a scary thing, but I but I just wondered if that if that was a a consideration in terms of how the how those builds were created. >> I think that's a question for you. >> Uh to be To be honest, I don't have the the answer to that. Um we are using the Conflux the base Tekton tasks, which is shipped within the pipeline. Um I haven't taken a look really deeply into that security part, but uh >> I I would suggest a conversation with Amy Ralph. >> Okay. >> So, how long do you think you'll be a core or you'll be boot a boot C uh um uh version with opinions? Or do you think there'll be a lot more convergence there? >> That's a tough one to answer. Uh depending on the progress and uh the community appetite for this and I don't know. Uh we plan to remain FCOS for a while, I guess. But uh one of the main blocker thing is So All right. So, when you get when you get your boot yeah, your FCOS image uh you can extend it by overlaying some packages, uh which is something that RPM-OSTree do and BootC doesn't. And then so, that's the main thing right now that keeps us all right going for BootC. Um and also like as long as we as long as we want to provide disk images and so uh BootC only do containers right now. Fedora BootC, I mean. Yeah. And Yeah, also that means they have to do it. And then right now FCOS does it for does that for you. >> Okay. I think we Thank you. >> [applause]