https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1961/steps/12/logs/stdio

qemuarm64-ptest ubuntu2004-arm-1

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1956/steps/12/logs/stdio

qemuarm64-ptest ubuntu2004-arm-1

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1962/steps/12/logs/stdio

qemuarm64-ptest ubuntu2004-arm-1

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1970/steps/12/logs/stdio

qemuarm64-ptest ubuntu1804-arm-1

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1968/steps/12/logs/stdio

qemuarm64-ptest ubuntu2004-arm-1

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1966/steps/12/logs/stdio

qemuarm64-ptest ubuntu1804-arm-1

Patch on the list to fix most issues in the tests, but those tests fail as we don't have vfat in the qemu kernels.

Bruce, can we get vfat in the qemu kernels please?

As Ross mentioned on IRC, we have some distro/machine features that indicate vfat support.

I've added a KERNEL_FEATURE to linux-yocto.inc that triggers off of the vfat MACHINE_FEATURE and will configure things for vfat support.

I'll include it in my next pull request.

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1974/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1975/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1976/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1977/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1980/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1981/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1982/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1985/steps/12/logs/stdio

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1986/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1987/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1988/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1992/steps/12/logs/stdio

My fault: I failed to specify ordering.

Those tests will fail until Bruce's "linux-yocto: add vfat KERNEL_FEATURE when MACHINE_FEATURES include vfat' merges.

Patches on the list to skip those if vfat isn't present.

Closing: the tests now skip if vfat isn't enabled, and vfat is enabled in the qemu builds.

This commit:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2b44ac076c7068aa0316d15fff49f02491eccb69

broke our build with the following error:

ERROR: linux-stable-5.4+gitAUTOINC+82ffbc138a-r1 do_kernel_metadata: Feature 'cfg/fs/vfat.scc' not found, this will cause configuration failures.
ERROR: linux-stable-5.4+gitAUTOINC+82ffbc138a-r1 do_kernel_metadata: Check the SRC_URI for meta-data repositories or directories that may be missing
ERROR: linux-stable-5.4+gitAUTOINC+82ffbc138a-r1 do_kernel_metadata: Set KERNEL_DANGLING_FEATURES_WARN_ONLY to ignore this issue

The KERNEL_FEATURES check seems overly tied to a specific implementation and can error out in situations where nothing is wrong. 

Our situation looks like this:

* We use https://github.com/gregkh/linux as kernel source
* We use our own kernel recipe.
* That recipe that applies a few platform-specific patches plus a defconfig
* The recipe includes recipes-kernel/linux/linux-yocto.inc 
* The defconfig includes CONFIG_VFAT_FS=y
* DISTRO_FEATURES includes vfat

Because DISTRO_FEATURES includes vfat, KERNEL_FEATURES includes vfat, so CONFIG_VFAT_FS needs to be set. But it is set in the defconfig, so a config fragment isn't needed. 

I worked around this by replacing linux-yocto.inc in our kernel recipe with a subset of directives from that file:

-require recipes-kernel/linux/linux-yocto.inc
+inherit kernel
+inherit kernel-yocto
+B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
+
+do_install_append(){
+       if [ -n "${KMETA}" ]; then
+               rm -rf ${STAGING_KERNEL_DIR}/${KMETA}
+       fi
+}
+
+LIC_FILES_CHKSUM ?= "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
+
+DEPENDS += "xz-native bc-native"

I didn't want to use the KERNEL_DANGLING_FEATURES_WARN_ONLY flag because I prefer to build without warnings, but that is what this project did:  https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/36159 

I think it would be better for kconfig checks to be done against the .config file that will be used in the build, rather than against the intermediate files that generate that .config.

Correction, this is the commit caused our problem:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/linux/linux-yocto.inc?h=hardknott&id=06af9f81e973894482a9c5136ecc267bca0c2f30

If you're just using a defconfig and your own recipe, then you don't really need to include linux-yocto, as that's where the fragment handling comes in.

FWIW, you can trivially tell linux-yocto to use a defconfig and mainline kernel release, or alternatively there is a set of 'pure mainline kernel' recipes in https://git.sr.ht/~pbarker/meta-linux-mainline/.

Thanks, Ross. That's pretty much what I did, and it works fine. (I don't see any need to re-open this ticket; I just wanted to post the error in case it helps someone else out.)

Thanks also for the link to Paul Barker's linux-stable recipe. My recipe is a modification of the linux-yocto recipe; Paul's is cleaner.