On 1/23/26 12:44 AM, Marc-André Lureau 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.
It's a just a filesystem, so you're free to include what you want. An
advantage on custom solutions is that Dockerfile is a standardized format.
I wonder how this workflow can be extended and compare to mkosi
(beside the limitation to produce tar/fs image)
mkosi takes care of more things for you, like setting up users, probably
supports partitioning your disk, and make it bootable. See it as
something like debootstrap + install.
The container based approach above give you an ext4 filesystem, the rest
is up to you.
For qemu VM testing, it would fit better along with our Dockerfile &
lcitool usage.
It's nice and easy to prototype indeed. As well, unrelated, but I think
it's better for everyone to spend time learning Dockerfiles instead of
an ad-hoc solution QEMU wants to use. The worse would be custom python
scripts reinventing the wheel and recompiling everything: long to
iterate and impossible to decipher except for the one who wrote it.
I wish a tool would help to (cross) create & boot such (reproducible)
images & vm easily.
I was looking exactly at this, and I've been surprised that nobody
except bootc tried reusing existing containers: it seems to be a perfect
match. Beyond the convenience, you get build caching for free, which is
very important when you iterate on system images. And you can host the
result directly and for free on dockerhub, even if that's several GB.
Bootc forces the usage of a specific "base" image, which, IMHO, goes
against what people should expect. Now, instead of having a normal
Dockerfile, you have a Dockerfile based on a black box you can't modify
easily. If I'm wrong and if someone is familiar with bootc here, I would
be happy to hear the opposite.
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
All that said, containers are just a suggestion. If mkosi is a good
tool, I would be happy to see it used. Just avoid going down the rabbit
hole reimplementing everything like it has been suggested on this
thread: we would not have one problem only, but two problems instead.
Regards,
Pierrick
