qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "make check-acceptance" takes way too long


From: Kashyap Chamarthy
Subject: Re: "make check-acceptance" takes way too long
Date: Tue, 1 Feb 2022 12:06:33 +0100

On Tue, Jan 25, 2022 at 10:20:11AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > IMHO the ideal scenario would be for us to have a kernel, initrd
> > containing just busybox tools for the key arch targets we care
> > about. Those could be used with direct kernel boot or stuffed
> > into a disk iamge. Either way, they would boot in ~1 second,
> > even with TCG, and would be able to execute simple shell scripts
> > to test a decent amount of QEMU functionality.
> 
> I have some test images based on buildroot which are essentially that.
> https://gitlab.com/kraxel/br-kraxel/
> 
> Still a significant download, but much smaller than a full fedora or
> ubuntu cloud image and it boots much faster too.  Not down to only one
> second though.

Any objection to using CirrOS[1] images for boot-testing?   FWIW,
OpenStack upstream CI boots thousands of guests each day with these for
many years now.  It boots quick, and also satisfies one of Peter's
other requirements: AArch64 images.

A downside of CirrOS is it doesn't have a package manager, so installing
custom packages is a PITA.  The main use-case of CirrOS images
is any kind of boot-testing only.

To make the booting even quicker with CirrOS, do disable the "metadata
service lookup" (this is queried 20 times) at boot time.  It can be
trivially done by making this change in this file
/etc/cirros-init/config (in the disk image):

    - DATASOURCE_LIST="nocloud configdrive ec2"
    + DATASOURCE_LIST="nocloud"


[1] https://download.cirros-cloud.net/0.5.2/

        * * *

Another alternative that satisfies Peter's main requirements seem to be:
Alpine Linux:

(1) It has a small foot print -- under 50MB; 
(2) It supports x86 _and_ AArch64; and
(3) It has a proper package management system.


-- 
/kashyap




reply via email to

[Prev in Thread] Current Thread [Next in Thread]