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

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

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.
> (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?
Cheers,

--
Julien Grall