On Thu, Jan 22, 2026 at 02:22:28PM +0400, Marc-André Lureau wrote: > Hi > > On Thu, Jan 22, 2026 at 2:14 PM Daniel P. Berrangé <[email protected]> > wrote: > > > > 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. > > > That's right, the goal here is not to cover all possible images though. > > I picked Fedora here as an example, because it is the best supported > distribution in mkosi.
IMHO to be worth the effort of integrating mkosi *and* maintaining its use in QEMU long term, it has to address a broad set of problems that we face in the functional tests. IMHO the inherant dependency on distros is the underlying problem we have, as we try to achieve testing coverage across all the machine types in QEMU. It leads us to having a random selection of different approaches, and mkosi does not look like it will reduce that problem, or help us fill in the gaps we have. > > 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. > > mkosi can produce initrd images, which can be small enough and > customizable. Although I lack the details of what is possible, this is > part of the project research. > > Imho, building all images from scratch cannot be sustainable. I'd say the opposite - relying on distros, whether using mkosi or not, is not sustainable. 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. 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 :|
