Last Updated on October 26, 2023

How to figure out why kernel configuration fragments are not applied at all or not applied as you expected?


This post shows you how to figure out why kernel configuration fragments are not applied at all or not applied as you expected – see .ssc/.cfg files.


So you read your daily dose of the Yocto Project® Mega Manual and came across chapters like Adding Recipe-Space Kernel Features and Working with Advanced Metadata (yocto-kernel-cache).

Possible issues

You start to play around with it, but .scc files just don’t work for you. They don’t do what you expected.

Now what?

Bruce (the Yocto Project® kernel maintainer) promised a new and improved way in the next release of Poky, but for now, he says: “The config.queue and merge-config logs are the files of most interest (in the current state of things, there will be better files soon). Starting with gatesgarth you will see on your build console more kernel tooling-related info. The config.queue is in work-shared/$MACHINE/kernel-source/.kmeta/ and the merge-config artifacts are one directory deeper under cfg/.”

Let’s inspect some of the files under work-shared/${MACHINE}/kernel-source/.kmeta


The bsp_definition defines my kernel type (arm64-ml-std) and looks like this:



The config.queue of my arm64-ml-std kernel looks like this:

configs///defconfig # non-hardware
configs//ktypes/std/std.cfg # non-hardware
configs//features/ikconfig/ikconfig.cfg # non-hardware
configs//features/posix-mqueue/posix-mqueue.cfg # non-hardware
configs//features/ramdisk/ramdisk.cfg # non-hardware
configs//features/mtd/mtd.cfg # non-hardware
configs//features/snvs-rtc/snvs-rtc.cfg # non-hardware
configs//features/tun/tun.cfg # non-hardware
configs//features/btrfs/btrfs.cfg # non-hardware
configs//features/tracepoints/tracepoints.cfg # non-hardware
configs//features/syn-cookies/syn-cookies.cfg # non-hardware

That seems promising.

It looks like my kernel type, .scc files and .cfg files are actually used. In case they are not picked up it’s helpful to know that those variables show up in a file called meta-series  (meaning they need to be defined somewhere).


# _mark arm64-ml-std.scc start 
# _define KMACHINE 'arm64-ml' 
# _define KTYPE 'std' 
# _define KARCH 'aarch64' 
# _mark std.scc start

The file above is quite useful since you see in which order .scc files and patches are applied. You can see this in the next excerpt of “meta-series”:

kconf /workdir/build/phyboard-polis-imx8mm-wic/tmp/work/phyboard_polis_imx8mm-resy-linux/linux-yocto-custom/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/arm64-ml-base/features/tracepoints/tracepoints.cfg # non-hardware
# _mark tracepoints.scc end
# _mark syn-cookies.scc start
kconf /workdir/build/phyboard-polis-imx8mm-wic/tmp/work/phyboard_polis_imx8mm-resy-linux/linux-yocto-custom/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/arm64-ml-base/features/syn-cookies/syn-cookies.cfg # non-hardware
# _mark syn-cookies.scc end
# _mark std-collection.scc end
# _mark std.scc end
# _mark arm64-ml-std.scc end
# _mark arm64-ml-user-patches.scc start
patch patches//patches/phyboard-polis-imx8mm/dts/0001-freescale-imx8mm-phyboard-polis-rdk.dts-dependencies.patch
# _mark arm64-ml-user-patches.scc end

The .scc files are processed in the same order as they appear in my top level kernel type (arm64-ml-std) file. You can see one patch in the end.

tree .kernel-meta/

I guess you got the idea. Here is the tree with all files:

student@e450-tr1:/workdir$ tree .kernel-meta/
├── bsp_definition
├── cfg
│   ├── merge_config_build.log
│   └── scratch
├── config.queue
├── configs
│   ├── defconfig
│   ├── features
│   │   ├── btrfs
│   │   │   └── btrfs.cfg
│   │   ├── ikconfig
│   │   │   └── ikconfig.cfg
│   │   ├── mtd
│   │   │   └── mtd.cfg
│   │   ├── posix-mqueue
│   │   │   └── posix-mqueue.cfg
│   │   ├── ramdisk
│   │   │   └── ramdisk.cfg
│   │   ├── snvs-rtc
│   │   │   └── snvs-rtc.cfg
│   │   ├── syn-cookies
│   │   │   └── syn-cookies.cfg
│   │   ├── tracepoints
│   │   │   └── tracepoints.cfg
│   │   └── tun
│   │       └── tun.cfg
│   └── ktypes
│       └── std
│           └── std.cfg
├── meta-series
├── non-hardware_frags.txt
├── patches
│   └── patches
│       └── phyboard-polis-imx8mm
│           └── dts
│               └── 0001-freescale-imx8mm-phyboard-polis-rdk.dts-dependencies.patch
├── patch.queue
└── series -> patch.queue

19 directories, 19 files


In case some configuration fragments are not applied as you expected you might also have a look at the cfg/merge_config_build.log:

Using .kernel-meta/configs///defconfig as base
Merging .kernel-meta/configs//ktypes/std/std.cfg
Merging .kernel-meta/configs//features/ikconfig/ikconfig.cfg
Merging .kernel-meta/configs//features/posix-mqueue/posix-mqueue.cfg
Merging .kernel-meta/configs//features/ramdisk/ramdisk.cfg
Merging .kernel-meta/configs//features/mtd/mtd.cfg
Value of CONFIG_MTD_CFI_ADV_OPTIONS is redefined by fragment .kernel-meta/configs//features/mtd/mtd.cfg:
New value: # CONFIG_MTD_CFI_ADV_OPTIONS is not set

Merging .kernel-meta/configs//features/snvs-rtc/snvs-rtc.cfg
Merging .kernel-meta/configs//features/tun/tun.cfg
Value of CONFIG_TUN is redefined by fragment .kernel-meta/configs//features/tun/tun.cfg:
Previous value: CONFIG_TUN=y
New value: CONFIG_TUN=m

Merging .kernel-meta/configs//features/btrfs/btrfs.cfg
Value of CONFIG_BTRFS_FS is redefined by fragment .kernel-meta/configs//features/btrfs/btrfs.cfg:
Previous value: CONFIG_BTRFS_FS=m
New value: CONFIG_BTRFS_FS=y

Merging .kernel-meta/configs//features/tracepoints/tracepoints.cfg
Value of CONFIG_FTRACE is redefined by fragment .kernel-meta/configs//features/tracepoints/tracepoints.cfg:
Previous value: # CONFIG_FTRACE is not set
New value: CONFIG_FTRACE=y

Merging .kernel-meta/configs//features/syn-cookies/syn-cookies.cfg
make[1]: Entering directory '/workdir/build/phyboard-polis-imx8mm-wic/tmp/work/phyboard_polis_imx8mm-resy-linux/linux-yocto-custom/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/linux-phyboard_polis_imx8mm-std-build'
  GEN     Makefile
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --alldefconfig Kconfig
# configuration written to .config
make[1]: Leaving directory '/workdir/build/phyboard-polis-imx8mm-wic/tmp/work/phyboard_polis_imx8mm-resy-linux/linux-yocto-custom/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/linux-phyboard_polis_imx8mm-std-build'
Value requested for CONFIG_ACPI_APEI_PCIEAER not in final .config
Requested value:  CONFIG_ACPI_APEI_PCIEAER=y
Actual value:

Value requested for CONFIG_USB_CONN_GPIO not in final .config
Requested value:  CONFIG_USB_CONN_GPIO=m
Actual value:     CONFIG_USB_CONN_GPIO=y

Value requested for CONFIG_BUILD_BIN2C not in final .config
Requested value:  CONFIG_BUILD_BIN2C=y
Actual value:

Value requested for CONFIG_MTD_IMPA7 not in final .config
Requested value:  # CONFIG_MTD_IMPA7 is not set
Actual value:


I hope this helps. If you still don’t see your configuration changes, you could also try KERNEL_FEATURES:append e.g. to conditionally include kernel metadata. Those features happen after all the kernel tooling so it should work.

Maybe like that:

# --> EW-7811UN USB/Wifi dongle
# USB realtek wifi
# conditionally include kernel fragment:
KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'wifi', ' features/rtl8xxxu/rtl8xxxu.scc', '', d)}"
# which seems to work
# conditionally automatically load the kernel module
KERNEL_MODULE_AUTOLOAD += " ${@bb.utils.contains("MACHINE_FEATURES", "wifi", "rtl8xxxu", "",d)}"
# make sure 'wifi' is also set in DISTRO_FEATURES to install various extra things
# and make wifi work out of the box
# <-- EW-7811UN USB/Wifi dongle


For a blog post that describes how to build the upstream kernel without the Yocto Project® have a look here. If you want to learn how Embedded Linux works have a look here. To learn more about the Yocto Project® have a look here.

Upcoming Events

Our 3 points

of differentiation

We provide host and target hardware during all our teaching.

Three or more people from the same company? We provide private customized training – consulting included.

Subject matter experts develop high-quality, job-related, up-to-date, authentic courseware.