Re: [OE-core] [PATCH 3/3] oeqa selftest uboot.py: add qemu KVM test case

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

Hi,

On Tue, May 27, 2025 at 08:34:52AM +0200, Mathieu Dubois-Briand wrote:
> On Mon May 26, 2025 at 10:45 AM CEST, Mikko Rapeli wrote:
> > On Fri, May 23, 2025 at 05:16:58PM +0300, Mikko Rapeli via lists.openembedded.org wrote:
> >> On Fri, May 23, 2025 at 03:15:51PM +0200, Mathieu Dubois-Briand wrote:
> >> > On Thu May 22, 2025 at 3:41 PM CEST, Mikko Rapeli via lists.openembedded.org wrote:
> >> > > Add a test case to boot target system via u-boot
> >> > > using qemu with KVM. This was broken recently
> >> > > and workaround proposed to u-boot. Test case
> >> > > works with genericarm64 and qemuarm64 target machines
> >> > > compiled and tested on aarch64 build host with KVM
> >> > > support.
> >> > >
> >> > > Test execution time with full sstate cache is
> >> > > around 170 seconds. qemu boot itself takes just
> >> > > a few seconds to full userspace.
> >> > >
> >> > > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> >> > > ---
> >> > 
> >> > Hi Mikko,
> >> > 
> >> > I saw your other mail saying you will make an update, but as I had
> >> > already picked these patches, here is the build result: the selftest is
> >> > failing on armhost:
> >> > 
> >> > ---
> >> > 2025-05-23 08:50:18,542 - oe-selftest - INFO - uboot.UBootTest.test_boot_uboot_kvm_to_full_target (subunit.RemotedTestCase)
> >> > 2025-05-23 08:50:18,543 - oe-selftest - INFO -  ... ERROR
> >> > ...
> >> > QEMU 10.0.0 monitor - type 'help' for more information
> >> > (qemu)
> >> > Waiting at most 1000 seconds for login banner (05/23/25 08:33:29)
> >> > Connection from 127.0.0.1:43786
> >> > Target didn't reach login banner in 1000 seconds (05/23/25 08:50:12)
> >> > Last 25 lines of login console (1721):
> >> > Scanning bootdev 'virtio-blk#36.bootdev':
> >> > Scanning bootdev 'virtio-net#32.bootdev':
> >> > BOOTP broadcast 1
> >> > ...
> >> > BOOTP broadcast 17
> >> > 
> >> > Retry time exceeded; starting again
> >> > No more bootdevs
> >> > ---  -----------  ------  --------  ----  ------------------------  ----------------
> >> > (1 bootflow, 1 valid)
> >> > =>
> >> > ...
> >> > RuntimeError: core-image-minimal - FAILED to start qemu - check the task log and the boot log
> >> > ---
> >> > 
> >> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1749
> >> 
> >> Thanks, I will take a look. Boot to u-boot seems to ok so KVM is working on
> >> the aarch64 build machine but something in wic image ESP partition detection is not
> >> working in the same way as on my aarch64 build machine and qemuarm64 and
> >> genericarm64 configs.
> >> 
> >> I will compare the runqemu and qemu-system-aarch64 arguments to figure out what is
> >> different.
> >> 
> >> One problem I thought I solved was to change from virtio scsi to virtio blk emulation
> >> but that seems to be effecttive albeit with a warning:
> >> 
> >> https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/2468510/raw_inline
> >> 
> >> runqemu - WARNING - Unknown QB_DRIVE_TYPE: vd
> >> runqemu - WARNING - Failed to figure out drive type, consider define or fix QB_DRIVE_TYPE
> >> runqemu - WARNING - Trying to use virtio block drive
> >> 
> >> u-boot defconfig does not have scsi support but virtio blk works for disk with ESP
> >> partition in fat format.
> >
> > I reviewed the runqemu and qemu-system-aarch64 arguments but could not see major differences.
> > One difference is that autobuilder runs with tap and I with slirp networking, but that
> > should not affect rootfs/ESP partition detection in u-boot. I've sent out v4 now.
> > If this still fails on autobuilder, then I'd need know what config fragments
> > are applied. I've configured qemuarm64 and genericarm64 with
> > ". oe-init-build-env" and then added TEST_RUNQEMUPARAMS += "slirp"
> > and SANITY_TESTED_DISTROS = "" to conf/local.conf. Maybe autobuilder
> > scripts add something more.
> >
> > Cheers,
> >
> > -Mikko
> 
> Hi Mikko,
> 
> Thanks for the new version, but I confirm it still fails.
> 
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1772

Is it possible to grab the full boot log
/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/build-st-1032659/tmp/work/qemuarm64-poky-linux/core-image-minimal/1.0/testimage/qemu_boot_log.20250526163143 ?

It was referred in
https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/2499407/raw_inline

That shows multiple tries to boot qemu into the rootfs.
One of them try the ext4 rootfs image which should not be possible
since the test configures wic with an ESP partition and
u-boot should be able to detect that if the block devices
was correct setup in qemu.

Maybe these logs are from previous test and not the one which is failing
which could be the last boot try in the log.

> About the configuration, I believe everything is there:
> 
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/1772/steps/14/logs/stdio
> 
> But anyway, here is the configuration on the worker:
> 
> $ cat conf/auto.conf
> MACHINE = "qemuarm64"
> DISTRO = "poky"
> SDKMACHINE = "aarch64"
> PACKAGE_CLASSES = "package_rpm"
> DL_DIR = '/srv/autobuilder/valkyrie.yocto.io/current_sources'
> SSTATE_DIR ?= '/srv/autobuilder/valkyrie.yocto.io/pub/sstate'
> RPM_GPG_SIGN_CHUNK = '1'
> IMAGE_INSTALL:append = ' ssh-pregen-hostkeys'
> SANITY_TESTED_DISTROS = ''
> BB_HASHSERVE = 'wss://hashserv-eu.yoctoproject.org/ws'
> OE_FRAGMENTS += 'core/yocto-autobuilder/autobuilder core/yocto-autobuilder/autobuilder-resource-constraints'
> 
> local.conf is unmodified (local.conf.sample).

Thanks, I will try again to reproduce. Something is different
but what...

Cheers,

-Mikko
 
> Best regards,
> Mathieu
> 
> -- 
> Mathieu Dubois-Briand, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>