On Fri, Jan 23, 2026 at 3:44 AM Marc-André Lureau <[email protected]> wrote: > > 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.
Hi Marc-André, I would like to submit QEMU's GSoC application in the next day or two. A minimum of 4 project ideas is mentioned in the latest guidelines from Google and we're currently at 3 ideas. Do you want to update the project idea based on the feedback so we can add it to the list? https://wiki.qemu.org/Internships/ProjectIdeas/mkosiTestAssets Thanks, Stefan
