On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote: > Hi Marc-André, > I haven't seen discussion about the project ideas you posted, so I'll > try to kick it off here for the mkosi idea here. > > Thomas: Would you like to co-mentor the following project with > Marc-André? Also, do you have any concerns about the project idea from > the maintainer perspective? > > === Reproducible Test Image Building with mkosi ===
> This project proposes using mkosi to build minimal, reproducible test > images directly from distribution packages. mkosi is a tool for > building clean OS images from distribution packages, with excellent > support for Fedora and other distributions. It should be able to > produces deterministic outputs. Aside from what I mentioned already, the other issue I anticipate with mkosi is the mismatch between what hardware QEMU needs to be able to cover, vs what hardware the distros actually support. Fedora in particular is pretty narrow in its coverage. Debian is considerably broader. Neither will support all the QEMU targets, let alone all the machine types within the target. While there is value in testing a full blown OS image, IMHO, for most of what we need it is considerable overkill, and thus makes functional tests slower than they would otherwise need to be. IMHO, our baseline for functional testing images ought to be a Linux Kconfig recipe used to build a dedicate kernel, plus a busybox build for the target. This would let us create either a self contained initrd, or a tiny root disk, both of which would reliably boot in a barely more than a second or two, even under TCG. This would have a number of other benefits * Not dependent on distros supporting the given QEMU target and machine type. As long as a Linux port exists and busybox compiles, we can test it * Identical test image functionality for every single target and machine type. No hodge-podge of different 3rd party guest OS. * Stable forever, with all changes entirely under our own control. No distro changes that arbitrarily break our CI. * Easier to debug when it breaks, since there would be a small well defined set of logic running in the guest userspace * Fairly easy for QEMU to provide the complete and corresponding source for any binary images, since we've built it all from scratch * Tiny & fast downloads of pre-built images. This would not eliminate the need for testing real OS images, but would significantly downgrade their importance. Functional tests could be in three groups - 'quick', as today, 'slow' the smoke tests with our miny kernel+busybox, 'thorough' the full OS images. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
