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

Re: [PATCH v3 2/2] gitlab-ci: add an ARM32 qemu-based smoke test



On Mon, 21 Mar 2022, Julien Grall wrote:
> On 21/03/2022 19:47, Stefano Stabellini wrote:
> > On Sun, 20 Mar 2022, Julien Grall wrote:
> > > On 20/03/2022 01:46, Stefano Stabellini wrote:
> > > > On Fri, 18 Mar 2022, Stefano Stabellini wrote:
> > > > > Add a minimal ARM32 smoke test based on qemu-system-arm, as provided
> > > > > by
> > > > > the test-artifacts qemu container. The minimal test simply boots Xen
> > > > > (built from previous build stages) and Dom0. The test is fetching the
> > > > > Dom0 kernel and initrd from Debian Jessie: they work just fine and
> > > > > this
> > > > > way we don't have to maintain a build for them too.
> > > > 
> > > > 
> > > > Thanks to the Xen fix recently submitted
> > > > (https://marc.info/?l=xen-devel&m=164774063802402) I'll be able to
> > > > update this script to use Debian Bullseye. I am thinking of merging the
> > > > below directly with this patch.
> > > > 
> > > > 
> > > > ---
> > > > 
> > > > automation: upgrade Debian to Bullseye for testing Xen aarch32
> > > > 
> > > > Also change initrd. As the new netboot initrd from Debian Bullseye is
> > > > huge (22MB), use a tiny initrd from Alpine Linux instead (only 2.5MB).
> > > 
> > > This is sounds odd to me. So we are going to use Bullseye but not really
> > > because we want to use a different initrd.
> > > 
> > > Why can't you get everything from the same place?
> > 
> > Because it doesn't work :-(
> > 
> > 
> > > > Also note that the huge Debian Bullseye initrd would cause QEMU to
> > > > crash due to the -device loader parameter.
> > > 
> > > Can you provide more details? Was this reported to QEMU?
> > 
> > QEMU core dumps when provided with the Debian Bullseye initrd binary to
> > load. I guessed it was due to the size and tried with a smaller size.
> > Everything worked with a smaller initrd. I also think that it is not a
> > good idea to use a 22MB initrd anyway so decided against the Debian
> > Bullseye initrd. 
> 
> Why is it a bad idea? In general, bigger file allows us to test corner cases.

That is also true.

This test is minimal, there is only dom0 booting, no domUs. To me, it
makes sense that also the initrd is small. In general 20-25MB is the
regular full size of a Linux arm64 rootfs. I think it makes sense to
stay below 10-15MB for arm32 if we can.

We could go up in size if we added the Xen tools and a domU to the
initrd and tested xl create. There is a test like that for arm64.

We can add more tests like that.


> > (For reference 22MB is basically the size of a fully
> > featured Yocto-build rootfs.) I did not file a bug to qemu-devel yet and
> > didn't investigate further on the QEMU side as I ran out of time.
> > 
> > Alpine Linux provides a very nice 2.5MB initrd. I tried to use both
> > kernel and initrd from Alpine Linux but unfortunately the Alpine Linux
> > kernel doesn't boot. I don't know why but I think it is because it might
> > be missing the console driver. I am not sure. There are a lot of
> > combinations that don't work and it is time consuming to investigate
> > them all. I have been trying to investigate only the most critical
> > things -- they are too many!
> > 
> > I should add that the Debian initrd is not the ideal initrd because it
> > is made to start the Debian installer. Here we just want a tiny busybox
> > initrd.
> > 
> > In general, I think it would be better if we could use the kernel and
> > initrd from the same source but I couldn't find one that works. I could
> > build one myself but it would be one more thing to maintain in
> > gitlab-ci. Also using u-boot might solve the problem of loading the
> > binary but again we would have to maintain a u-boot arm32 build in
> > gitlab-ci.
> > 
> > So in order of preference best to worst in my opinion:
> > 
> > 1) kernel and initrd from the same source
> > 2) kernel and initrd from different sources
> > 3) build your own kernel/initrd/u-boot
> > 
> > So I ended up doing 2). I tested it and it is sufficient to get the test
> > up and running.
> 
> Thanks for the explanation. So I think we should not call that an "Upgrade to
> Bullseye" because you are not using Debian. Instead, you borrowed a working
> kernel that happens to have everything you need built-in.
> 
> Also, can you update the commit message and provide a summary of this
> discussion?

Yes I can do that, thanks for the review!



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.