WEBVTT 00:00.000 --> 00:06.840 All right, does this work? 00:06.840 --> 00:07.560 I think it does. 00:07.560 --> 00:08.840 OK, amazing. 00:08.840 --> 00:10.800 So I'm on tape. 00:10.800 --> 00:14.400 And I am building images at Red Hat. 00:14.400 --> 00:17.600 And today, I would like to talk about building ISOs. 00:17.600 --> 00:19.680 So these things that in the past, 00:19.680 --> 00:21.680 you downloaded them, you burned them on your CD, 00:21.680 --> 00:23.560 then you plugged them into the CD drive, 00:23.560 --> 00:25.680 and you installed your system. 00:25.680 --> 00:28.960 Nowadays, you usually put them on a USB disk, which creates 00:28.960 --> 00:33.000 a lot of friction, because CDs and USB disks are different, 00:33.000 --> 00:35.360 or you just plug them in a VM. 00:35.360 --> 00:37.200 So this is an ISO. 00:37.200 --> 00:43.760 And this talk is about building them from container images. 00:43.760 --> 00:46.000 It's not only because of my t-shirt. 00:46.000 --> 00:51.360 It's also because a lot of people nowadays think, 00:51.360 --> 00:54.920 and I agree with them, that using container images 00:54.920 --> 00:58.600 as the source of truth for their operating systems 00:58.600 --> 01:02.280 and for their machines is a good idea. 01:02.280 --> 01:06.920 So basically how this works is that, if you are not 01:06.920 --> 01:11.120 aware, I'm sure you are, is that when you install a machine 01:11.120 --> 01:16.240 from such a distribution, you basically get the container, 01:16.240 --> 01:19.600 and then you explore it on a partition drive. 01:19.600 --> 01:20.720 And it just works, right? 01:20.720 --> 01:22.720 You need to do some special bits with putt loader, 01:22.720 --> 01:24.160 but that's it. 01:24.160 --> 01:25.400 And then when you update the system, 01:25.400 --> 01:27.120 you basically put another container, 01:27.120 --> 01:29.520 and you kind of somehow reboot into it. 01:29.520 --> 01:30.880 That's basically the story. 01:30.880 --> 01:33.360 But the container image is really the source of truth. 01:33.360 --> 01:36.840 This will be kind of the multi-autist of this presentation. 01:36.840 --> 01:39.240 And yeah, there are many, many parties 01:39.240 --> 01:40.840 who actually did it. 01:40.840 --> 01:42.640 I think that the most popular one right now 01:42.640 --> 01:45.120 is universal rule, and especially a buzz-eyed, 01:45.120 --> 01:48.320 with the demise of Windows 10, it goes really popular, right? 01:48.320 --> 01:54.320 Everyone wants to game on Linux, amazing world in 2026. 01:54.320 --> 01:57.600 But there is a helium OS, which is kind of like, 01:57.600 --> 02:02.840 I think it's based on CentroStream with KDOG, I don't know. 02:02.840 --> 02:06.840 We at Redhead, we actually have our image mode based on it, 02:06.840 --> 02:10.960 which is basically well-bought in our shipped in containers. 02:10.960 --> 02:13.640 And all of these three projects are using Booty, 02:13.640 --> 02:18.120 which is kind of the backend for it. 02:18.120 --> 02:21.360 It's the software that does the container pooling, 02:21.360 --> 02:23.920 and then exploring and all these things. 02:23.960 --> 02:28.160 But there are also projects that use containers, 02:28.160 --> 02:30.800 but they don't use mootsy-like cars. 02:30.800 --> 02:33.160 I think the next topic is about cars, right? 02:33.160 --> 02:35.040 In this room, or element of my renter. 02:35.040 --> 02:38.560 So apparently, it's so popular that we have even, 02:38.560 --> 02:41.400 like, multiple competing solutions. 02:41.400 --> 02:43.680 So yeah. 02:43.680 --> 02:48.680 But the problem that I saw is that there is no good tooling for ISOs. 02:49.240 --> 02:52.080 There is no good tooling for ISOs. 02:52.080 --> 02:55.800 I mean, in the Booty, we're, oh, we are not in, amazing. 02:55.800 --> 03:00.200 So maybe we've been fixed, we will see. 03:00.200 --> 03:03.840 So like, we have, for example, in the Booty bot, 03:03.840 --> 03:06.040 and I will relate to the Booty bot a lot, 03:06.040 --> 03:07.800 because that's where I live. 03:10.240 --> 03:12.080 We have a good tooling for creating like, 03:12.080 --> 03:14.600 this image is an installing them and whatever, 03:14.600 --> 03:18.920 but for actually creating these ISOs, 03:18.920 --> 03:22.000 it's still kind of sucks to be honest. 03:23.000 --> 03:26.440 So, and you know, ISOs are somewhat different, 03:26.440 --> 03:28.320 like ISOs isn't a disk image, 03:28.320 --> 03:30.920 like there are some specialties that you need to handle. 03:32.000 --> 03:35.800 So, you know, I wanted to mention some existing solutions. 03:36.720 --> 03:39.200 I will start with a one that's not even a solution, 03:39.200 --> 03:42.160 but I just wanted to mention it for the sake of telling this 03:42.160 --> 03:43.000 how story. 03:43.000 --> 03:47.160 So, about two years ago, when Booty became a thing, 03:48.360 --> 03:52.680 we in an image builder, which is the software that I'm working on, 03:52.680 --> 03:57.680 we were tasked with creating the installation experience, 03:59.160 --> 04:02.200 and we came up with this weird ISO that is, 04:02.200 --> 04:04.120 we thought that it would be a great idea that, you know, 04:04.120 --> 04:06.480 people they just want to install the container 04:06.480 --> 04:08.600 on the Booty container or their machine, 04:08.600 --> 04:11.400 so we provided a very guided and open-ended thing, 04:11.400 --> 04:13.240 basically, you just call something like, 04:13.240 --> 04:15.800 image builder build, Booty, image builder build, ISO, 04:15.800 --> 04:20.680 and it would take a container and it would do weird things. 04:20.680 --> 04:23.880 Like, we actually not use the container in the process, 04:23.880 --> 04:26.160 we just picked some parts from it, 04:26.160 --> 04:30.240 and actually created the rotary again from scratch, 04:30.240 --> 04:32.440 and there were no customizations, 04:32.440 --> 04:37.040 and yeah, it was bad, because, 04:37.040 --> 04:40.720 well, I mean, for certain use cases, it's good, 04:40.720 --> 04:45.240 but we kind of failed to implement what people 04:45.240 --> 04:47.960 and expected from this road. 04:47.960 --> 04:50.880 Like, people expect that they can do all sorts of customizations 04:50.880 --> 04:53.440 in their container, like they can, you know, 04:53.440 --> 04:55.080 override whatever they want, you know, 04:55.080 --> 04:58.080 custom, kernel, or custom package, is custom, whatever, 04:58.080 --> 05:00.760 and we provided a thing with almost no customizations, 05:00.760 --> 05:03.280 so yeah, yes, it solves a solution, 05:03.280 --> 05:05.720 but we realize that many people, 05:05.720 --> 05:08.160 they want to customize also, they are so ISO, 05:08.160 --> 05:11.680 and yeah, I kind of, somewhat hated, 05:11.680 --> 05:13.120 but it was my idea to implement it, 05:13.120 --> 05:14.760 so it's fine that I hated it, too. 05:15.920 --> 05:18.720 And the second project that I want to mention here 05:18.720 --> 05:21.080 is this wonderful name, 05:21.080 --> 05:25.320 Titanoboa, I think, it's like ancient snake, 05:25.320 --> 05:26.960 huge dinosaur snake. 05:28.360 --> 05:31.960 This is a project made by the U-blue folks, 05:31.960 --> 05:35.560 and it's like a just file and a GitHub action, 05:36.320 --> 05:40.320 and it's much better, because it actually, 05:40.320 --> 05:42.080 you feed it the container image, 05:42.080 --> 05:45.280 that you should, the one that you want to install, 05:45.280 --> 05:50.280 so for example, Buzzite, and you create the ISO out of it, 05:50.280 --> 05:53.080 so you know, all of the customizations are in. 05:53.080 --> 05:58.080 However, like Titanoboa, it's not there yet, I think, 05:58.600 --> 06:01.400 because it actually modifies the container image 06:01.400 --> 06:06.400 in the process, and it's actually a tie to Fedora, 06:08.280 --> 06:10.280 like there are literally in the source code, 06:10.280 --> 06:12.800 like DNF installed record live, or something like this, 06:12.800 --> 06:15.000 so you know, it's tied to the RPAM ecosystem. 06:16.280 --> 06:19.640 And I simply don't have a way to simply, 06:19.640 --> 06:24.000 like when, before converting the container image to an ISO, 06:24.000 --> 06:25.840 I don't have an easy way to just put them in, 06:25.840 --> 06:27.520 run the container and inspect it, 06:27.520 --> 06:30.000 you know, just play around, see if everything is there, 06:30.000 --> 06:35.000 because like the logic is hidden in the Titanoboa sources, 06:36.120 --> 06:39.720 so the container is still not the source of truth for this. 06:39.720 --> 06:44.720 So yeah, I think that neither of these solutions are there yet, 06:46.920 --> 06:51.920 so now let's step back a bit and think of what we really want, 06:51.920 --> 06:53.880 and let's actually think about the disc images 06:53.880 --> 06:58.880 because I think that these are like solved issue kind of, I think, 06:58.880 --> 07:02.160 and basically the process, it consists of two steps 07:02.160 --> 07:05.280 when we are talking about, you know, shipping operating system 07:05.280 --> 07:08.440 and this container, so firstly, you build the container image, 07:08.440 --> 07:12.080 somehow, doesn't matter how, and it defines all content 07:12.080 --> 07:17.080 in the source of truth for your distribution operating system, 07:17.080 --> 07:18.800 however you want to call it. 07:18.800 --> 07:23.160 And then you convert it to a disc image, 07:23.160 --> 07:24.880 it's always two-step process, right? 07:24.880 --> 07:27.320 So basically that means exploring a table 07:27.320 --> 07:32.000 and the partition disc in the right way. 07:33.280 --> 07:37.720 And this is important because not everything 07:37.720 --> 07:40.560 can be expressed in a table by default, right? 07:40.560 --> 07:43.880 Like not everything that it's installed on your machine 07:43.880 --> 07:47.480 can be like easily expressed as a table 07:47.480 --> 07:49.440 for example partition in, right? 07:49.440 --> 07:52.920 But we actually thought about it at like our tooling image builder, 07:52.920 --> 07:56.760 it has a support for Jason that you include in the container file 07:56.760 --> 07:58.040 and image builder does the read it 07:58.040 --> 08:00.560 and partitions the disc accordingly. 08:00.560 --> 08:03.560 So the container image became the source of truth also 08:03.560 --> 08:05.280 for the partitioning. 08:05.280 --> 08:09.880 And yeah, the bootholder, for example, like bootholder, 08:09.880 --> 08:13.080 I mean, okay, in the world of just Fibooting, 08:13.080 --> 08:17.240 it's like almost everything is in the file system 08:17.240 --> 08:21.320 except that you need to mark the Fib partition in the right way. 08:21.320 --> 08:25.760 But, but, but, but, like our CBooting, right? 08:25.760 --> 08:30.760 Like how do you express, how do you express what? 08:33.160 --> 08:37.440 You know, the Fibooting process in a container file 08:37.440 --> 08:39.480 when you just need to put the right block 08:39.480 --> 08:42.320 at the right place at the disc, like this is how 08:42.320 --> 08:44.120 booting works in the legacy world. 08:44.120 --> 08:46.920 So, but unfortunately in the boot of the, 08:46.920 --> 08:48.040 we just can handle it. 08:48.040 --> 08:51.440 Like it's a standard that, or not a standard, 08:51.440 --> 08:55.040 but it's a tool that like decoratively 08:55.040 --> 08:59.000 describes how to put the, the right bootholder 08:59.000 --> 09:01.040 at the right places. 09:01.040 --> 09:04.920 So now moving to the ISO world, 09:04.920 --> 09:07.120 I think it should be the same thing. 09:07.120 --> 09:10.400 So you should be able to build a container image 09:10.400 --> 09:12.520 and it serves as a source of truth. 09:12.520 --> 09:14.560 And you know, I can, it's a container image. 09:14.560 --> 09:17.080 So I can polymer run it, I can push it in the registry, 09:17.080 --> 09:20.240 I can sign it, you can do all sorts of cool stuff 09:20.240 --> 09:22.320 with a container image, right? 09:22.320 --> 09:24.640 And then you need to polymerize it on ISO 09:24.640 --> 09:26.080 in the right way. 09:27.200 --> 09:31.200 And the right way, in the terms of ISOs, means that, 09:31.200 --> 09:36.200 so the basic thing here is that when the boot, 09:36.200 --> 09:39.880 if boot process finished, the goal 09:39.880 --> 09:43.120 is that your container image, thank you, 09:43.120 --> 09:48.120 that your container image is the root file system, 09:49.560 --> 09:51.160 that is the image. 09:51.160 --> 09:52.600 And usually in the world of ISO, 09:52.600 --> 09:54.800 that means that you put the whole thing in a squash FS 09:54.800 --> 09:57.840 or a cipher or a error FS or whatever you want. 09:57.840 --> 10:00.040 Squash FS is the most common one. 10:02.080 --> 10:04.800 So that's the easy part, but you know, 10:04.800 --> 10:07.360 for ISOs, you actually squash FS is just one part, 10:07.360 --> 10:09.120 but you also need the kernel to be there, 10:09.120 --> 10:11.360 the bootholder, the enitram FS, 10:11.360 --> 10:13.280 and you need to configure the bootholder, 10:13.280 --> 10:15.880 so the ISO label are sort of think. 10:15.880 --> 10:19.560 And basically, I realize that we need a contract 10:19.560 --> 10:21.440 between these two steps, right? 10:21.440 --> 10:24.200 Like, it needs to be defined 10:25.200 --> 10:28.880 where you put all these important bits 10:28.880 --> 10:30.520 that are needed in the ISO, 10:30.520 --> 10:34.320 and they are outside of the main squash FS archive. 10:34.320 --> 10:38.440 And so the converter knows where to find them, 10:38.440 --> 10:40.640 and where to, you know, how to structure the ISO. 10:40.640 --> 10:42.080 So we need the contract. 10:42.080 --> 10:46.200 And this is exactly what we defined. 10:46.280 --> 10:50.520 So I called it a container native ISO contract. 10:50.520 --> 10:52.520 Yeah, it might be a stupid name, 10:52.520 --> 10:55.880 but it's a basic very tiny specification 10:55.880 --> 10:59.880 that allows a container image to be the source of true for, 10:59.880 --> 11:02.360 you know, all these ISO weird quirks. 11:03.320 --> 11:06.160 And the thing that I very natural a date 11:06.160 --> 11:08.280 is that it very much resembles 11:08.280 --> 11:09.640 how bootsy containers work, 11:09.640 --> 11:12.080 so you know, like, I don't know, 11:12.080 --> 11:13.840 I will talk about it later. 11:13.840 --> 11:18.840 And it is opinionated, but for pragmatic reasons 11:19.520 --> 11:22.240 and only when there are pragmatic reasons, 11:22.240 --> 11:25.040 and the big thing is, of course, the bootloader. 11:25.040 --> 11:27.400 I mean, there are many, many bootloaders, 11:27.400 --> 11:31.600 but I know that some of them are really cool, you know, 11:31.600 --> 11:34.560 but some of them work everywhere, and that's crap. 11:34.560 --> 11:39.560 So, sorry, that's just true, I think. 11:40.040 --> 11:43.640 So, currently, the spec just hard cause 11:43.640 --> 11:44.800 that you need to use, you know, 11:44.800 --> 11:46.880 the usual editor hybrid ISO setup, 11:46.880 --> 11:48.520 so it's bootable using, like I say, 11:48.520 --> 11:51.800 and FA, from USB drives and CD ROMs. 11:53.080 --> 11:56.120 And the bootloader, it works. 11:56.120 --> 11:57.120 Yeah. 11:57.120 --> 12:03.120 And so the spec, so it describes where to put the right files 12:03.120 --> 12:06.080 into the image, into the container image, 12:06.080 --> 12:11.080 so the converter that also is a part of this contract, 12:11.200 --> 12:14.720 where it can find it, and the spec also defines 12:14.720 --> 12:17.440 where the converter puts them inside the image 12:17.440 --> 12:19.320 because certain things are a kind, I know, 12:19.320 --> 12:20.480 mangled together. 12:20.480 --> 12:23.080 So, the important bits, you know, 12:23.080 --> 12:25.160 of course, you know, a shame, grab tools, 12:25.160 --> 12:28.160 so the kernel, the bootloader bits, kernel, 12:28.160 --> 12:31.080 and it's arguments, very, very. 12:31.080 --> 12:33.120 The inner RAMFS is in the container image, 12:33.120 --> 12:35.640 and of course, very, and then the ISO, 12:35.640 --> 12:37.400 then a subset of grab tools, settings, 12:37.400 --> 12:39.920 this is something that I would like feedback on, 12:39.920 --> 12:44.360 the ISO label, and then the contract, 12:44.360 --> 12:45.640 you know, so the contract is that, 12:45.640 --> 12:47.840 of course, the squashFS, the whole container image 12:47.840 --> 12:51.160 becomes the squashFS, but the contract 12:51.160 --> 12:53.640 describes where the squashFS archive will end up 12:53.640 --> 12:55.080 on the ISO. 12:55.080 --> 12:57.920 And yeah, this is the spec. 12:59.200 --> 13:03.360 It's fairly short, and I will give you the link. 13:03.360 --> 13:06.520 And we also implemented the converter for this spec, 13:06.520 --> 13:10.040 so we don't have to implement the container bits, right? 13:10.040 --> 13:13.000 Because we can just use a container file, 13:13.000 --> 13:16.880 or whatever is your favorite container building engine, 13:19.080 --> 13:20.720 way of building containers, 13:20.720 --> 13:24.680 but we also implemented the converter, 13:24.680 --> 13:26.560 and you know, I work on the image builder, 13:26.560 --> 13:27.880 so we implemented an image builder, 13:27.880 --> 13:30.000 and the new boot-sigineric ISO type, 13:30.000 --> 13:31.840 it's a stupid name because we are actually not 13:31.840 --> 13:34.000 able to type to boot-sig, but yeah, 13:34.000 --> 13:35.800 we will need to probably change it in the new future, 13:35.800 --> 13:36.800 we will see. 13:36.800 --> 13:38.800 And yeah, project placement, 13:38.800 --> 13:40.320 if you've never heard of image builder, 13:40.320 --> 13:42.000 I'm sorry, the name is Ferdogeneric. 13:43.200 --> 13:45.520 It's a wonderful tool for building these images, 13:45.520 --> 13:47.200 ISOs, and more for Ferdora, 13:47.200 --> 13:48.760 a centralized treatment, and the Xervotips, 13:48.760 --> 13:50.360 it's used for some of the official artifacts 13:50.360 --> 13:52.280 of all these distributions, 13:52.280 --> 13:56.000 and it supports the standard new table stuff, 13:56.000 --> 13:57.640 or even like mootsy stuff. 13:57.640 --> 13:59.520 So if you want to build some images, 13:59.520 --> 14:01.240 just visit the link and use it. 14:01.240 --> 14:03.040 It's pretty neat, also runs in Port-Man, 14:03.040 --> 14:05.240 so it's great if you're actually using one of these 14:05.240 --> 14:06.240 immutable distributions, 14:06.240 --> 14:08.520 because you can just use Port-Man and it works, 14:08.520 --> 14:10.560 and you don't have to install anything. 14:10.560 --> 14:15.560 Anyhow, so let's look at the example. 14:18.560 --> 14:22.120 So this is a very basic container 14:22.120 --> 14:24.400 that will actually fulfill the contract. 14:24.400 --> 14:26.840 So I am using Versite as the base, 14:26.840 --> 14:28.800 which is amazing, because I told you before 14:28.800 --> 14:32.080 that it's based on the way how wootsy containers are laid out. 14:32.080 --> 14:35.360 So a Versite container, well, it contains a tree, 14:35.360 --> 14:37.480 an operating system, tree doesn't already boot, right? 14:37.480 --> 14:39.280 Like it has system, the all the services 14:39.280 --> 14:42.840 can run KDE, or ground, or in the case of Versite, 14:42.840 --> 14:43.920 it has KDE. 14:43.920 --> 14:44.880 So it's perfect. 14:46.800 --> 14:49.400 So curdle solved, amazing. 14:50.360 --> 14:53.200 Now you need to put some extra packages in that. 14:54.920 --> 14:57.160 For example, like Dracolid LifeSyscripts, 14:57.160 --> 14:58.920 this is needed, so the life and matter and works, 14:58.920 --> 15:00.320 because ISOs are weird, right? 15:00.320 --> 15:02.440 Like they are only by default, 15:02.440 --> 15:03.680 but systems like to ride, 15:03.680 --> 15:04.560 so you need to put like, 15:04.560 --> 15:07.960 over the squash, as they are, it's a bit messy. 15:09.280 --> 15:11.960 But these are like some packages need for it. 15:11.960 --> 15:15.960 Rep to FA, you know, the base images of Versite, 15:15.960 --> 15:19.640 they don't have the Rep 2 modules for CD booting, 15:19.640 --> 15:21.080 so an extra package. 15:21.080 --> 15:24.880 And then, sorry, sorry, sorry, I don't know. 15:25.360 --> 15:28.360 And ISO Md5, some, why? 15:29.520 --> 15:33.760 The default experience is that we use the container, 15:33.760 --> 15:35.600 not only as the source of truth 15:35.600 --> 15:38.160 for the squash, if it's in for the ISO, 15:38.160 --> 15:39.760 but also as the build root, 15:41.360 --> 15:44.240 which is so very same default and I like it, 15:44.240 --> 15:48.440 because there is much low risk of having a mismatch, right? 15:48.440 --> 15:52.280 Like if you just use a random random, 15:53.240 --> 15:56.960 a random squashFS, MK, squashFS, executable, 15:56.960 --> 16:01.960 as the way to create this squashFS, 16:02.480 --> 16:04.000 your kernel might not understand it, 16:04.000 --> 16:05.040 because there would be a mismatch, 16:05.040 --> 16:06.480 but usual in one distribution, 16:06.480 --> 16:09.280 like the maintainers try to, do, you know, have it in line. 16:09.280 --> 16:11.680 Well, squashFS is, you know, boring, 16:11.680 --> 16:15.160 but doesn't change, but we saw issues in image builder, 16:15.160 --> 16:18.160 for example, of XFS, like when there was new feature, 16:18.160 --> 16:20.520 like the kernel couldn't read it and we had to fix it. 16:20.520 --> 16:22.960 So, but I think that generally it's a great idea 16:22.960 --> 16:24.280 to mix that. 16:24.280 --> 16:26.760 I will talk later about when it's not desirable, 16:26.760 --> 16:28.680 but they stay tuned. 16:28.680 --> 16:31.840 Then you need to regenerate, 16:31.840 --> 16:32.960 or it's not, or it's not my first, 16:32.960 --> 16:34.240 because the default in intrameth, 16:34.240 --> 16:37.200 has that shipped in Vazite, it kind of boot from an ISO, 16:37.200 --> 16:38.800 because it doesn't have the right modules, 16:38.800 --> 16:41.360 so just add a module, and that's it. 16:41.360 --> 16:44.720 Then there is like a weird line for fixing the boot 16:44.720 --> 16:47.360 or the location, there was a boot update in federal, 16:47.360 --> 16:49.240 like they are modernizing the boot stack, 16:49.240 --> 16:50.440 and it kind of supplies us. 16:50.440 --> 16:53.000 So, you will fix this in this spec for sure. 16:55.000 --> 16:57.360 Yeah, so that's the intrameth part. 16:57.360 --> 16:59.160 And, you know, basically the spec says 16:59.160 --> 17:01.440 that the usual modules kernel intrameth has, 17:01.440 --> 17:03.840 that's the path where the spec says 17:03.840 --> 17:05.880 that it expects an intrameth as so, 17:05.880 --> 17:07.400 that's the connection between this pack 17:07.400 --> 17:09.000 and what we are doing here. 17:10.120 --> 17:13.600 This is just so, we would a live Katie session, 17:13.600 --> 17:17.200 easy peasy, and this is currently 17:17.200 --> 17:22.200 how we designed to configure the crop to bootloader. 17:23.120 --> 17:26.400 So, we event quite simple for now, 17:26.400 --> 17:28.080 but basically what usually people 17:28.080 --> 17:30.120 want is to customize the intrameth time out, 17:30.120 --> 17:33.280 like that's actually what most distributions care about. 17:33.280 --> 17:35.200 It feels like, so you can just define 17:35.200 --> 17:38.840 and hear an assembly, I'm all, man, 17:38.840 --> 17:41.880 I would like feedback if I'm all is good, not, 17:41.880 --> 17:43.960 but this is what we use for now. 17:44.280 --> 17:46.480 And that's it. 17:46.480 --> 17:49.240 And this fulfills the contract 17:49.240 --> 17:52.280 and it will boot, you know, 17:52.280 --> 17:53.680 well, let me show you. 17:53.680 --> 17:57.160 And if you build this container file 17:57.160 --> 18:00.240 and to use this small image builder command 18:00.240 --> 18:02.280 to convert it to an ISO, 18:02.280 --> 18:04.440 it will give you an ISO from a container. 18:04.440 --> 18:05.720 It's quite simple, right? 18:05.720 --> 18:10.120 And the container is actually the source of truth for this, 18:10.120 --> 18:14.560 because there is very little secret, special, 18:14.560 --> 18:17.200 not secret, but special source in image builder. 18:17.200 --> 18:20.200 It literally tries to take as much as the source 18:20.200 --> 18:22.040 from the container as possible, 18:22.040 --> 18:24.840 like we make assumptions about some of the layout bits 18:24.840 --> 18:28.840 and grab, but otherwise everything comes from the container 18:28.840 --> 18:31.400 and you can push it, you can pull it, you can, 18:31.400 --> 18:32.560 it's a container. 18:32.560 --> 18:33.560 So it's quite simple. 18:33.560 --> 18:35.840 And yeah, as I told you earlier, 18:35.840 --> 18:37.680 image builder is also a little bit container, 18:37.680 --> 18:39.360 so you just need poor man. 18:39.360 --> 18:42.240 So it is really simple to run this in a GitHub action 18:42.240 --> 18:44.000 because you just basically, 18:44.000 --> 18:46.640 two poor man calls in there. 18:46.640 --> 18:50.000 And the current state. 18:50.000 --> 18:53.640 So this is, this is currently still something 18:53.640 --> 18:55.000 that we mark as experimental. 18:55.000 --> 18:56.520 And like the docs isn't finished, 18:56.520 --> 18:59.800 current lives only in my small repository. 18:59.800 --> 19:04.800 So let's go there and explore what we did there. 19:04.800 --> 19:06.760 And now comes the hard part. 19:14.800 --> 19:16.640 Cool. 19:16.640 --> 19:20.400 OK, so this is the small GitHub repository. 19:20.400 --> 19:25.120 Basically, it contains, oh, long screen. 19:25.120 --> 19:28.240 It contains the contract in the rig me. 19:28.240 --> 19:32.320 It's Andre Budai, by the way, slash, boot CI source. 19:32.320 --> 19:33.840 It's in the, thank you. 19:33.840 --> 19:36.000 It's in the slides are in pre-talk, 19:36.000 --> 19:37.200 so you can find in there. 19:39.760 --> 19:40.880 I lost, sorry. 19:40.880 --> 19:44.360 So this is the spec that I copied in the slides. 19:44.360 --> 19:47.960 And there are a few examples already in the repository. 19:47.960 --> 19:52.160 So there is Buzzite, but there is like, full Buzzite. 19:52.160 --> 19:53.680 So basically, Buzzite nowadays, 19:53.680 --> 19:57.240 it used Titanoboa to create ISO. 19:57.240 --> 20:01.600 And I basically did the same thing with my approach, 20:01.600 --> 20:03.400 as the Uble folks do. 20:03.400 --> 20:07.000 But the container is now the source of true for the ISO. 20:07.000 --> 20:08.360 And it's amazing. 20:08.360 --> 20:10.240 Like it contains a KD environment. 20:10.240 --> 20:12.480 There are footpacks pre-installed. 20:12.480 --> 20:15.200 And there is an affluent installer. 20:15.200 --> 20:19.080 So you can already do everything that Titanoboa does 20:19.080 --> 20:21.040 for Buzzite and I'm pretty sure. 20:21.040 --> 20:25.280 But there is Kinoid, which is Federal Abbey KDE. 20:25.280 --> 20:28.280 In the table one, there is Bluffin LTS, which 20:29.240 --> 20:31.840 was quite excited to get it. 20:31.840 --> 20:37.640 It's life environment of CentOS 3.0, and the cool part 20:37.640 --> 20:40.200 is that actually in the world of CentOS 3. 20:40.200 --> 20:43.400 And we don't have many life images. 20:43.400 --> 20:44.600 And this is a life image. 20:44.600 --> 20:49.480 And this is maybe, well, I know that some six build life images, 20:49.480 --> 20:52.280 but I'm just proud that we have now CentOS 3.10 20:52.280 --> 20:54.240 product in life image. 20:54.240 --> 20:57.720 But the really cool part is that the spec is very 20:57.720 --> 20:59.040 dysthroagnostic. 20:59.040 --> 21:03.760 So there are small, tiny, deby, and Ubuntu containers, 21:03.760 --> 21:08.600 because if you notice what we need is kernel, 21:08.600 --> 21:12.040 any drama, fast, graph, all these distributions have this. 21:12.040 --> 21:13.480 So you can just build whatever you want. 21:13.480 --> 21:16.520 So I just build some examples of deby, and Ubuntu. 21:16.520 --> 21:19.080 And they are already there with container files. 21:19.080 --> 21:20.520 So that's pretty cool. 21:20.520 --> 21:23.600 And the last one is Federalized Toler. 21:23.600 --> 21:28.000 So indeed, it's not used as much nowadays, 21:28.000 --> 21:31.640 but previously, I saw the directly booted intern in Toler, 21:31.640 --> 21:32.600 and this is it. 21:32.600 --> 21:34.600 So it's a very minimal Federalized Toler 21:34.600 --> 21:40.120 that just in a text mode, it deploys a bootsy container. 21:40.120 --> 21:42.560 Have two minutes. 21:42.560 --> 21:45.000 So OK. 21:45.000 --> 21:48.720 And the repository also, it has all the GitHub actions 21:48.720 --> 21:50.400 for building some actual building. 21:50.400 --> 21:52.320 All these distributed, oh, wrong window. 21:56.160 --> 22:00.800 You know, present the route is cool until it isn't. 22:00.800 --> 22:03.600 So it has all the GitHub actions for building 22:03.600 --> 22:06.360 this stuff in GitHub actions, workforce, 22:06.360 --> 22:07.920 rolling in GitHub actions. 22:07.920 --> 22:09.600 So we are actually building all these images 22:09.600 --> 22:12.880 on a very commit, uploading to black, black, black, black, 22:12.880 --> 22:15.080 black, black, black, black, black, black, black, black, 22:15.080 --> 22:17.240 and it just works because it just needs performance. 22:17.240 --> 22:20.640 So very, very simple in a GitHub actions environment. 22:20.640 --> 22:23.840 And we don't have time. 22:23.840 --> 22:26.120 I mean, OK. 22:26.120 --> 22:26.920 We don't have much time. 22:26.920 --> 22:29.720 So this is the BN thing. 22:29.720 --> 22:31.520 And it just has a few virtual machines, 22:31.520 --> 22:33.760 but you probably already saw some virtual machines. 22:33.760 --> 22:34.520 This is a boot. 22:34.520 --> 22:36.840 The BN, innovate. 22:36.840 --> 22:38.920 This is the blue fin, LPS thing. 22:42.400 --> 22:45.640 Yeah, you probably saw a grown before. 22:45.640 --> 22:49.600 This is Beside, or it is here. 22:49.600 --> 22:52.120 This is Beside. 22:52.120 --> 22:53.880 The cool thing here is, of course, 22:53.880 --> 22:56.200 that there is the installer. 22:56.200 --> 22:57.720 So we can just click next next next. 22:57.720 --> 23:01.040 And I will end up with Beside install my virtual machine. 23:01.040 --> 23:04.840 So yeah, this is what I built with the stuff 23:04.840 --> 23:06.800 that I created. 23:06.800 --> 23:08.680 And OK. 23:08.680 --> 23:12.200 So if you're interested, go to the upstream thing. 23:12.200 --> 23:15.280 If you want to get in touch, go to my matrix channel. 23:15.280 --> 23:16.480 The spec isn't finalized. 23:16.480 --> 23:17.840 We are looking for a feedback. 23:17.840 --> 23:21.120 We would really love to make this useful 23:21.120 --> 23:26.080 for distribution developers, future plans. 23:26.080 --> 23:28.920 Bootabde, maybe we can merge this with bootabde at some point, 23:28.920 --> 23:31.120 but bootabde focuses on these images. 23:31.120 --> 23:34.360 So this is something that I would like to discuss with the team. 23:34.360 --> 23:37.280 Custom Build Roots, very quickly. 23:37.280 --> 23:39.720 Currently, we use the same Build Roots for the same image 23:39.720 --> 23:40.480 and folder Build Root. 23:40.480 --> 23:43.040 And for the ISO, but if you really want to make a minimum ISO, 23:43.040 --> 23:44.560 you don't want to have to store your ISO in it. 23:44.560 --> 23:46.280 So I would like to support custom Build Roots. 23:46.280 --> 23:49.200 So you can decouple these two things. 23:49.200 --> 23:52.000 Maybe in multiple cameras, I heard from some people 23:52.000 --> 23:55.080 that they would like to have an ISO or multiple cameras. 23:55.080 --> 23:56.280 Maybe some scholarship assumption 23:56.280 --> 23:59.080 are of a different bootloader as we can discuss all of that. 23:59.080 --> 24:01.960 And yeah, big thanks to Simon DeVeiger. 24:01.960 --> 24:04.400 He unfortunately had to leave this morning. 24:04.400 --> 24:06.000 He was my brother in crime. 24:06.000 --> 24:07.800 Michael, I don't know, it is here. 24:07.800 --> 24:10.560 But he laid out the basics for this. 24:10.560 --> 24:13.600 The image builder team, the lovely folks that helped me 24:13.600 --> 24:15.800 from do this, and the university community, 24:15.800 --> 24:17.800 I don't know if anyone is from there is here. 24:17.800 --> 24:23.520 But I read your source codes like 100 times. 24:23.520 --> 24:25.200 You are doing a good amazing job. 24:25.200 --> 24:26.600 Anyway, thank you. 24:26.600 --> 24:28.000 And yeah.