Daniel P. Berrangé <[email protected]> writes: > 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 is why I've been building my iamges with buildroot. It provides for a lean user-space with exactly what you want and it can create a software BOM for the whole thing. But it also allows me to bring in more complex things if I need to like the vkmark tests for example. > 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 -- Alex Bennée Virtualisation Tech Lead @ Linaro
