All right, does this work?
I think it does.
OK, amazing.
So I'm on tape.
And I am building images at Red Hat.
And today, I would like to talk about building ISOs.
So these things that in the past,
you downloaded them, you burned them on your CD,
then you plugged them into the CD drive,
and you installed your system.
Nowadays, you usually put them on a USB disk, which creates
a lot of friction, because CDs and USB disks are different,
or you just plug them in a VM.
So this is an ISO.
And this talk is about building them from container images.
It's not only because of my t-shirt.
It's also because a lot of people nowadays think,
and I agree with them, that using container images
as the source of truth for their operating systems
and for their machines is a good idea.
So basically how this works is that, if you are not
aware, I'm sure you are, is that when you install a machine
from such a distribution, you basically get the container,
and then you explore it on a partition drive.
And it just works, right?
You need to do some special bits with putt loader,
but that's it.
And then when you update the system,
you basically put another container,
and you kind of somehow reboot into it.
That's basically the story.
But the container image is really the source of truth.
This will be kind of the multi-autist of this presentation.
And yeah, there are many, many parties
who actually did it.
I think that the most popular one right now
is universal rule, and especially a buzz-eyed,
with the demise of Windows 10, it goes really popular, right?
Everyone wants to game on Linux, amazing world in 2026.
But there is a helium OS, which is kind of like,
I think it's based on CentroStream with KDOG, I don't know.
We at Redhead, we actually have our image mode based on it,
which is basically well-bought in our shipped in containers.
And all of these three projects are using Booty,
which is kind of the backend for it.
It's the software that does the container pooling,
and then exploring and all these things.
But there are also projects that use containers,
but they don't use mootsy-like cars.
I think the next topic is about cars, right?
In this room, or element of my renter.
So apparently, it's so popular that we have even,
like, multiple competing solutions.
So yeah.
But the problem that I saw is that there is no good tooling for ISOs.
There is no good tooling for ISOs.
I mean, in the Booty, we're, oh, we are not in, amazing.
So maybe we've been fixed, we will see.
So like, we have, for example, in the Booty bot,
and I will relate to the Booty bot a lot,
because that's where I live.
We have a good tooling for creating like,
this image is an installing them and whatever,
but for actually creating these ISOs,
it's still kind of sucks to be honest.
So, and you know, ISOs are somewhat different,
like ISOs isn't a disk image,
like there are some specialties that you need to handle.
So, you know, I wanted to mention some existing solutions.
I will start with a one that's not even a solution,
but I just wanted to mention it for the sake of telling this
how story.
So, about two years ago, when Booty became a thing,
we in an image builder, which is the software that I'm working on,
we were tasked with creating the installation experience,
and we came up with this weird ISO that is,
we thought that it would be a great idea that, you know,
people they just want to install the container
on the Booty container or their machine,
so we provided a very guided and open-ended thing,
basically, you just call something like,
image builder build, Booty, image builder build, ISO,
and it would take a container and it would do weird things.
Like, we actually not use the container in the process,
we just picked some parts from it,
and actually created the rotary again from scratch,
and there were no customizations,
and yeah, it was bad, because,
well, I mean, for certain use cases, it's good,
but we kind of failed to implement what people
and expected from this road.
Like, people expect that they can do all sorts of customizations
in their container, like they can, you know,
override whatever they want, you know,
custom, kernel, or custom package, is custom, whatever,
and we provided a thing with almost no customizations,
so yeah, yes, it solves a solution,
but we realize that many people,
they want to customize also, they are so ISO,
and yeah, I kind of, somewhat hated,
but it was my idea to implement it,
so it's fine that I hated it, too.
And the second project that I want to mention here
is this wonderful name,
Titanoboa, I think, it's like ancient snake,
huge dinosaur snake.
This is a project made by the U-blue folks,
and it's like a just file and a GitHub action,
and it's much better, because it actually,
you feed it the container image,
that you should, the one that you want to install,
so for example, Buzzite, and you create the ISO out of it,
so you know, all of the customizations are in.
However, like Titanoboa, it's not there yet, I think,
because it actually modifies the container image
in the process, and it's actually a tie to Fedora,
like there are literally in the source code,
like DNF installed record live, or something like this,
so you know, it's tied to the RPAM ecosystem.
And I simply don't have a way to simply,
like when, before converting the container image to an ISO,
I don't have an easy way to just put them in,
run the container and inspect it,
you know, just play around, see if everything is there,
because like the logic is hidden in the Titanoboa sources,
so the container is still not the source of truth for this.
So yeah, I think that neither of these solutions are there yet,
so now let's step back a bit and think of what we really want,
and let's actually think about the disc images
because I think that these are like solved issue kind of, I think,
and basically the process, it consists of two steps
when we are talking about, you know, shipping operating system
and this container, so firstly, you build the container image,
somehow, doesn't matter how, and it defines all content
in the source of truth for your distribution operating system,
however you want to call it.
And then you convert it to a disc image,
it's always two-step process, right?
So basically that means exploring a table
and the partition disc in the right way.
And this is important because not everything
can be expressed in a table by default, right?
Like not everything that it's installed on your machine
can be like easily expressed as a table
for example partition in, right?
But we actually thought about it at like our tooling image builder,
it has a support for Jason that you include in the container file
and image builder does the read it
and partitions the disc accordingly.
So the container image became the source of truth also
for the partitioning.
And yeah, the bootholder, for example, like bootholder,
I mean, okay, in the world of just Fibooting,
it's like almost everything is in the file system
except that you need to mark the Fib partition in the right way.
But, but, but, but, like our CBooting, right?
Like how do you express, how do you express what?
You know, the Fibooting process in a container file
when you just need to put the right block
at the right place at the disc, like this is how
booting works in the legacy world.
So, but unfortunately in the boot of the,
we just can handle it.
Like it's a standard that, or not a standard,
but it's a tool that like decoratively
describes how to put the, the right bootholder
at the right places.
So now moving to the ISO world,
I think it should be the same thing.
So you should be able to build a container image
and it serves as a source of truth.
And you know, I can, it's a container image.
So I can polymer run it, I can push it in the registry,
I can sign it, you can do all sorts of cool stuff
with a container image, right?
And then you need to polymerize it on ISO
in the right way.
And the right way, in the terms of ISOs, means that,
so the basic thing here is that when the boot,
if boot process finished, the goal
is that your container image, thank you,
that your container image is the root file system,
that is the image.
And usually in the world of ISO,
that means that you put the whole thing in a squash FS
or a cipher or a error FS or whatever you want.
Squash FS is the most common one.
So that's the easy part, but you know,
for ISOs, you actually squash FS is just one part,
but you also need the kernel to be there,
the bootholder, the enitram FS,
and you need to configure the bootholder,
so the ISO label are sort of think.
And basically, I realize that we need a contract
between these two steps, right?
Like, it needs to be defined
where you put all these important bits
that are needed in the ISO,
and they are outside of the main squash FS archive.
And so the converter knows where to find them,
and where to, you know, how to structure the ISO.
So we need the contract.
And this is exactly what we defined.
So I called it a container native ISO contract.
Yeah, it might be a stupid name,
but it's a basic very tiny specification
that allows a container image to be the source of true for,
you know, all these ISO weird quirks.
And the thing that I very natural a date
is that it very much resembles
how bootsy containers work,
so you know, like, I don't know,
I will talk about it later.
And it is opinionated, but for pragmatic reasons
and only when there are pragmatic reasons,
and the big thing is, of course, the bootloader.
I mean, there are many, many bootloaders,
but I know that some of them are really cool, you know,
but some of them work everywhere, and that's crap.
So, sorry, that's just true, I think.
So, currently, the spec just hard cause
that you need to use, you know,
the usual editor hybrid ISO setup,
so it's bootable using, like I say,
and FA, from USB drives and CD ROMs.
And the bootloader, it works.
Yeah.
And so the spec, so it describes where to put the right files
into the image, into the container image,
so the converter that also is a part of this contract,
where it can find it, and the spec also defines
where the converter puts them inside the image
because certain things are a kind, I know,
mangled together.
So, the important bits, you know,
of course, you know, a shame, grab tools,
so the kernel, the bootloader bits, kernel,
and it's arguments, very, very.
The inner RAMFS is in the container image,
and of course, very, and then the ISO,
then a subset of grab tools, settings,
this is something that I would like feedback on,
the ISO label, and then the contract,
you know, so the contract is that,
of course, the squashFS, the whole container image
becomes the squashFS, but the contract
describes where the squashFS archive will end up
on the ISO.
And yeah, this is the spec.
It's fairly short, and I will give you the link.
And we also implemented the converter for this spec,
so we don't have to implement the container bits, right?
Because we can just use a container file,
or whatever is your favorite container building engine,
way of building containers,
but we also implemented the converter,
and you know, I work on the image builder,
so we implemented an image builder,
and the new boot-sigineric ISO type,
it's a stupid name because we are actually not
able to type to boot-sig, but yeah,
we will need to probably change it in the new future,
we will see.
And yeah, project placement,
if you've never heard of image builder,
I'm sorry, the name is Ferdogeneric.
It's a wonderful tool for building these images,
ISOs, and more for Ferdora,
a centralized treatment, and the Xervotips,
it's used for some of the official artifacts
of all these distributions,
and it supports the standard new table stuff,
or even like mootsy stuff.
So if you want to build some images,
just visit the link and use it.
It's pretty neat, also runs in Port-Man,
so it's great if you're actually using one of these
immutable distributions,
because you can just use Port-Man and it works,
and you don't have to install anything.
Anyhow, so let's look at the example.
So this is a very basic container
that will actually fulfill the contract.
So I am using Versite as the base,
which is amazing, because I told you before
that it's based on the way how wootsy containers are laid out.
So a Versite container, well, it contains a tree,
an operating system, tree doesn't already boot, right?
Like it has system, the all the services
can run KDE, or ground, or in the case of Versite,
it has KDE.
So it's perfect.
So curdle solved, amazing.
Now you need to put some extra packages in that.
For example, like Dracolid LifeSyscripts,
this is needed, so the life and matter and works,
because ISOs are weird, right?
Like they are only by default,
but systems like to ride,
so you need to put like,
over the squash, as they are, it's a bit messy.
But these are like some packages need for it.
Rep to FA, you know, the base images of Versite,
they don't have the Rep 2 modules for CD booting,
so an extra package.
And then, sorry, sorry, sorry, I don't know.
And ISO Md5, some, why?
The default experience is that we use the container,
not only as the source of truth
for the squash, if it's in for the ISO,
but also as the build root,
which is so very same default and I like it,
because there is much low risk of having a mismatch, right?
Like if you just use a random random,
a random squashFS, MK, squashFS, executable,
as the way to create this squashFS,
your kernel might not understand it,
because there would be a mismatch,
but usual in one distribution,
like the maintainers try to, do, you know, have it in line.
Well, squashFS is, you know, boring,
but doesn't change, but we saw issues in image builder,
for example, of XFS, like when there was new feature,
like the kernel couldn't read it and we had to fix it.
So, but I think that generally it's a great idea
to mix that.
I will talk later about when it's not desirable,
but they stay tuned.
Then you need to regenerate,
or it's not, or it's not my first,
because the default in intrameth,
has that shipped in Vazite, it kind of boot from an ISO,
because it doesn't have the right modules,
so just add a module, and that's it.
Then there is like a weird line for fixing the boot
or the location, there was a boot update in federal,
like they are modernizing the boot stack,
and it kind of supplies us.
So, you will fix this in this spec for sure.
Yeah, so that's the intrameth part.
And, you know, basically the spec says
that the usual modules kernel intrameth has,
that's the path where the spec says
that it expects an intrameth as so,
that's the connection between this pack
and what we are doing here.
This is just so, we would a live Katie session,
easy peasy, and this is currently
how we designed to configure the crop to bootloader.
So, we event quite simple for now,
but basically what usually people
want is to customize the intrameth time out,
like that's actually what most distributions care about.
It feels like, so you can just define
and hear an assembly, I'm all, man,
I would like feedback if I'm all is good, not,
but this is what we use for now.
And that's it.
And this fulfills the contract
and it will boot, you know,
well, let me show you.
And if you build this container file
and to use this small image builder command
to convert it to an ISO,
it will give you an ISO from a container.
It's quite simple, right?
And the container is actually the source of truth for this,
because there is very little secret, special,
not secret, but special source in image builder.
It literally tries to take as much as the source
from the container as possible,
like we make assumptions about some of the layout bits
and grab, but otherwise everything comes from the container
and you can push it, you can pull it, you can,
it's a container.
So it's quite simple.
And yeah, as I told you earlier,
image builder is also a little bit container,
so you just need poor man.
So it is really simple to run this in a GitHub action
because you just basically,
two poor man calls in there.
And the current state.
So this is, this is currently still something
that we mark as experimental.
And like the docs isn't finished,
current lives only in my small repository.
So let's go there and explore what we did there.
And now comes the hard part.
Cool.
OK, so this is the small GitHub repository.
Basically, it contains, oh, long screen.
It contains the contract in the rig me.
It's Andre Budai, by the way, slash, boot CI source.
It's in the, thank you.
It's in the slides are in pre-talk,
so you can find in there.
I lost, sorry.
So this is the spec that I copied in the slides.
And there are a few examples already in the repository.
So there is Buzzite, but there is like, full Buzzite.
So basically, Buzzite nowadays,
it used Titanoboa to create ISO.
And I basically did the same thing with my approach,
as the Uble folks do.
But the container is now the source of true for the ISO.
And it's amazing.
Like it contains a KD environment.
There are footpacks pre-installed.
And there is an affluent installer.
So you can already do everything that Titanoboa does
for Buzzite and I'm pretty sure.
But there is Kinoid, which is Federal Abbey KDE.
In the table one, there is Bluffin LTS, which
was quite excited to get it.
It's life environment of CentOS 3.0, and the cool part
is that actually in the world of CentOS 3.
And we don't have many life images.
And this is a life image.
And this is maybe, well, I know that some six build life images,
but I'm just proud that we have now CentOS 3.10
product in life image.
But the really cool part is that the spec is very
dysthroagnostic.
So there are small, tiny, deby, and Ubuntu containers,
because if you notice what we need is kernel,
any drama, fast, graph, all these distributions have this.
So you can just build whatever you want.
So I just build some examples of deby, and Ubuntu.
And they are already there with container files.
So that's pretty cool.
And the last one is Federalized Toler.
So indeed, it's not used as much nowadays,
but previously, I saw the directly booted intern in Toler,
and this is it.
So it's a very minimal Federalized Toler
that just in a text mode, it deploys a bootsy container.
Have two minutes.
So OK.
And the repository also, it has all the GitHub actions
for building some actual building.
All these distributed, oh, wrong window.
You know, present the route is cool until it isn't.
So it has all the GitHub actions for building
this stuff in GitHub actions, workforce,
rolling in GitHub actions.
So we are actually building all these images
on a very commit, uploading to black, black, black, black,
black, black, black, black, black, black, black, black,
and it just works because it just needs performance.
So very, very simple in a GitHub actions environment.
And we don't have time.
I mean, OK.
We don't have much time.
So this is the BN thing.
And it just has a few virtual machines,
but you probably already saw some virtual machines.
This is a boot.
The BN, innovate.
This is the blue fin, LPS thing.
Yeah, you probably saw a grown before.
This is Beside, or it is here.
This is Beside.
The cool thing here is, of course,
that there is the installer.
So we can just click next next next.
And I will end up with Beside install my virtual machine.
So yeah, this is what I built with the stuff
that I created.
And OK.
So if you're interested, go to the upstream thing.
If you want to get in touch, go to my matrix channel.
The spec isn't finalized.
We are looking for a feedback.
We would really love to make this useful
for distribution developers, future plans.
Bootabde, maybe we can merge this with bootabde at some point,
but bootabde focuses on these images.
So this is something that I would like to discuss with the team.
Custom Build Roots, very quickly.
Currently, we use the same Build Roots for the same image
and folder Build Root.
And for the ISO, but if you really want to make a minimum ISO,
you don't want to have to store your ISO in it.
So I would like to support custom Build Roots.
So you can decouple these two things.
Maybe in multiple cameras, I heard from some people
that they would like to have an ISO or multiple cameras.
Maybe some scholarship assumption
are of a different bootloader as we can discuss all of that.
And yeah, big thanks to Simon DeVeiger.
He unfortunately had to leave this morning.
He was my brother in crime.
Michael, I don't know, it is here.
But he laid out the basics for this.
The image builder team, the lovely folks that helped me
from do this, and the university community,
I don't know if anyone is from there is here.
But I read your source codes like 100 times.
You are doing a good amazing job.
Anyway, thank you.
And yeah.