Hi On Thu, Jan 22, 2026 at 7:46 PM Pierrick Bouvier <[email protected]> wrote: > > On 1/22/26 3:28 AM, Marc-André Lureau wrote: > > Hi > > > > On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <[email protected]> > > wrote: > >> > >> On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote: > >>> On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <[email protected]> > >>> wrote: > >>>> Once we have written some scripts that can build gcc, binutils, linux, > >>>> busybox we've opened the door to be able to support every machine type > >>>> on every target, provided there has been a gcc/binutils/linux port at > >>>> some time (which covers practically everything). Adding new machines > >>>> becomes cheap then - just a matter of identifying the Linux Kconfig > >>>> settings, and everything else stays the same. Adding new targets means > >>>> adding a new binutils build target, which should again we relatively > >>>> cheap, and also infrequent. This has potential to be massively more > >>>> sustainable than a reliance on distros, and should put us on a pathway > >>>> that would let us cover almost everything we ship. > >>> > >>> Isn't that essentially reimplementing half of buildroot, or the > >>> system image builder that Rob Landley uses to produce toybox > >>> test images ? > >> > >> If we can use existing tools to achieve this, that's fine. > >> > > > > Imho, both approaches are complementary. Building images from scratch, > > like toybox, to cover esoteric minimal systems. And more complete and > > common OSes with mkosi which allows you to have things like python, > > mesa, networking, systemd, tpm tools, etc for testing.. We don't want > > to build that from scratch, do we? > > > > I ran into this need recently, and simply used podman (or docker) for > this purpose. > > $ podman build -t rootfs - < Dockerfile > $ container=$(podman create rootfs) > $ podman export -o /dev/stdout $container | > /sbin/mke2fs -t ext4 -d - out.ext4 10g > $ podman rm -f $container > > It allows to create image for any distro (used it for alpine and > debian), as long as they publish a docker container. As well, it gives > flexibility to have a custom init, skipping a lengthy emulated boot with > a full system. As a bonus, it's quick to build, and does not require > recompiling the world to get something. > > You can debug things too by running the container on your host machine, > which is convenient. >
Very nice! I didn't realize you could export and reuse a container that way. I wonder how this workflow can be extended and compare to mkosi (beside the limitation to produce tar/fs image) For qemu VM testing, it would fit better along with our Dockerfile & lcitool usage. I wish a tool would help to (cross) create & boot such (reproducible) images & vm easily. > I took a look at bootc, but was not really convinced of what it added > for my use case compared to the 4 commands above. > Having a regular VM bootable image could be desirable for some cases (tpm, secure boot testing for ex). -- Marc-André Lureau
