Re: [OE-core] [PATCH v2 2/9] testimage.bbclass: detect slirp from TEST_RUNQEMUPARAMS

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Wed, Aug 23, 2023 at 11:49:39AM +0100, Richard Purdie wrote:
> On Wed, 2023-08-23 at 12:47 +0300, Mikko Rapeli wrote:
> > On Wed, Aug 23, 2023 at 10:06:41AM +0100, Richard Purdie wrote:
> > > On Wed, 2023-08-23 at 10:31 +0300, Mikko Rapeli wrote:
> > > > Hi,
> > > > 
> > > > On Tue, Aug 22, 2023 at 11:25:58PM -0700, Khem Raj wrote:
> > > > > will this work when running multiple instances of qemu ?
> > > > > e.g.  try bitbake core-image-ptest-all
> > > > 
> > > > I was not aware of core-image-ptest-all. Tried to build it but it doesn't
> > > > seem to be compatible with IMAGE_FEATURES += "ssh-server-dropbear" which is
> > > > needed to test core-image-minimal:
> > > > 
> > > > Error: 
> > > >  Problem: package packagegroup-core-ssh-dropbear-1.0-r1.noarch from oe-repo requires dropbear, but none of the providers can be installed
> > > >   - package dropbear-2022.83-r0.core2_64 from oe-repo conflicts with openssh provided by openssh-9.3p2-r0.core2_64 from oe-repo
> > > >   - package openssh-9.3p2-r0.core2_64 from oe-repo conflicts with dropbear provided by dropbear-2022.83-r0.core2_64 from oe-repo
> > > >   - conflicting requests
> > > > (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
> > > > 
> > > > oeqa runtime testing core-image-minimal without ssh server doesn't make sense as all tests will
> > > > just be skipped.
> > > 
> > > The autobuilder actually does that, the minimal image is just tested
> > > with the small number of non-network tests. The main thing was to test
> > > it does actually boot to a login prompt. We have other tests which test
> > > the other areas with other images.
> > 
> > Yes, granted it's enough to test that boot to serial console login works.
> > 
> > > The reason for the above is that there will be ptest openssh images
> > > which conflict with the dropbear ones. You can likely avoid that by
> > > using:
> > > 
> > > IMAGE_FEATURES:append:pn-core-image-minimal =  " ssh-server-dropbear"
> > > 
> > > The ptest images are designed to only include the ptest in question so
> > > in theory are otherwise as minimal as the dependencies allow.
> > 
> > Alright, this I could try. But I fear there is a log more missing from my
> > plain poky and default machine target to get the selftests and tests running.
> 
> There is no secret magic config the autobuilder uses. You keep asking
> me for this and there isn't anything. It is actually starting to annoy
> me a bit as there isn't anything "hidden".

If I can't run the tests for poky the way yocto upstream does, then I'm afraid
I can't really help with the issues you've seeing with the tests.

> The configurations used are all from this file:
> 
> https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json

Ok so https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/1948
for example uses yocto-autobuilder-helper at commit
af5d072a654a060c3ee61b5f394f52632e20200b. And the full repo
URL is visible not in the snippet there but in the full stdio download
of "Fetch yocto-autobuilder-helper" step. It was the web UI confusing me.

I'm sorry if these are all obvious to you and other developers but not
to me.

> Yes, there is a block of high level config around numbers of threads,
> disk space monitoring, pressure regulation values and so on but we
> purposefully keep the config to be as close to standard poky as we can.
>
> When we run selftest we do a couple of things. Firstly we split the
> machine and toolchain targets into separate areas.  We also split
> reproducibility to it's own target and test mirroring elsewhere too.
> This results in a slightly more complex selftest invocation:
> 
> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1 oe-selftest -a --skip-tests distrodata.Distrodata.test_checkpkg buildoptions.SourceMirroring.test_yocto_source_mirror reproducible -T machine -T toolchain-user -T toolchain-system -j 15
> 
> The only test which I don't think we run anywhere any more is the
> test_checkpkg target.
> 
> You can see all this from the logs buildbot shows from it's UI on the
> autobuilder too.

Thanks, this explains alot!

I'm still wondering how the build hosts are setup with "modprobe vgem" and that
build user account is in "render" group (on Ubuntu at least). Should these
be added to some documentation too?

> > This magic is somewhere in the autobuilder related git repositories, but from plain
> > poky checkout with a specific commit from master branch I don't know which versions
> > and repos to use so that the tests would be passing.
> > 
> > With these modifications in local.conf:
> > 
> > IMAGE_CLASSES += "testimage"
> > TEST_RUNQEMUPARAMS += "slirp"
> 
> We do not use slirp on the autobuilder. We never have and we're
> unlikely ever to do so and it is not something we officially support
> for this. This is likely the biggest source of problems.

Sadly I can't figure out how to setup runqemu and testimage.bbclass and
oe-selftests networking without slirp and for my testing needs it has been good
enough, now also with oe-selftests.

> I appreciate that gives some networking challenges for people in
> constrained environments but we did that primarily to allow for
> simplifications in the rest of the setup.
> 
> > IMAGE_FEATURES += "ssh-server-dropbear"
> 
> I've already explained that this one does likely cause problems. We
> simply don't run many tests against minimal images. 
>
> > # update kernel to latest available in poky
> > PREFERRED_VERSION_linux-yocto = ""
> 
> Not sure why this is needed?

I'm trying to test the 6.4 kernel update and reproduce the issues you've seen
there too.

> > SANITY_TESTED_DISTROS = ""
> 
> This one we've discussed. It really should be fixed in a better way but
> isn't anywhere near the top of the priority list.

I'll try to get to this.

Cheers,

-Mikko