Bug 16299

If you are building linux-yocto, or a proper out of tree BSP, those patches are not applied by design in the tooling. Patches are skipped for the core branches.

linux-yocto is building in master, it is building with my most recent updates that are pending and it is building in all supported stable branches.

I'll need more information about how you've created "my-machine" in your BSP layer.

As per Bruce's request, more info please.

Hi Bruce and Randy,
Thank you so much for the follow-up and apologies for the long delay in responding -- a bit hectic at work the past few days.

Up until now I've always been building from the most recent commit on the same branch as the release I'm using (wrynose, in this case). To keep things organized and not worry about tooling I use kas (https://kas.readthedocs.io/en/latest/).

Here's my kas YAML file for reference:
--------------8<--------------8<--------------8<--------------
header:
  version: 20

build_system: oe

distro: poky
machine: my-machine
target: my-machine-sdcard

repos:
  bitbake:
    url: https://git.openembedded.org/bitbake
    commit: 33581c84f3a85008239acbd940501a35de48dc91
    path: layers/bitbake
    layers: {}

  openembedded-core:
    url: https://git.openembedded.org/openembedded-core
    commit: 06dd66e6220e5ce4ed4b9af4d8231ae5f0a8ce80
    path: layers/openembedded-core
    layers:
      meta:

  meta-yocto:
    url: https://git.yoctoproject.org/meta-yocto
    commit: 904846ae078ee20de073040ebb77c86e19250f56
    path: layers/meta-yocto
    layers:
      meta-poky:

  meta-openembedded:
    url: https://git.openembedded.org/meta-openembedded
    commit: 420222862f5a6d95023b8f5f3b7e1808b2264ef9
    path: layers/meta-openembedded
    layers:
      meta-oe:
      meta-filesystems:
      meta-networking:
      meta-python:
      meta-multimedia:
      meta-webserver:

  meta-intel:
    url: https://git.yoctoproject.org/git/meta-intel.git
    commit: ff8ad78a0e3531060aa712b708cc01178c564a69
    path: layers/meta-intel

  meta-virtualization:
    url: https://git.yoctoproject.org/git/meta-virtualization.git
    commit: e1bdfe90563487f0a3253cd4b0d5bb7fa5194d83
    path: layers/meta-virtualization

  meta-swupdate:
    url: https://github.com/sbabic/meta-swupdate.git
    commit: 74532b19cb5939d39ca777264e1029534279e6f3
    path: layers/meta-swupdate

  meta-aws:
    url: https://github.com/aws4embeddedlinux/meta-aws.git
    tag: master-2026.20.0
    commit: 8bc16e7bb3fa0eee9a96f0d93fdac0b2fd978933
    path: layers/meta-aws

  meta-mylayer:
    url: .... (removed for privacy) ...
    branch: wrynose
    path: layers/meta-mylayer

local_conf_header:
  meta-mylayer: |
    PACKAGE_CLASSES = "package_rpm"
    EXTRA_IMAGE_FEATURES += "debug-tweaks"
    SERIAL_CONSOLES:forcevariable = "115200;ttyS0"
    OE_TERMINAL = "screen"
    RM_OLD_IMAGE = "1"
--------------8<--------------8<--------------8<--------------

The resulting bblayers.conf is:
--------------8<--------------8<--------------8<--------------
BBLAYERS ?= " \
    ${TOPDIR}/../layers/meta-aws \
    ${TOPDIR}/../layers/meta-intel \
    ${TOPDIR}/../layers/meta-openembedded/meta-filesystems \
    ${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
    ${TOPDIR}/../layers/meta-openembedded/meta-networking \
    ${TOPDIR}/../layers/meta-openembedded/meta-oe \
    ${TOPDIR}/../layers/meta-openembedded/meta-python \
    ${TOPDIR}/../layers/meta-openembedded/meta-webserver \
    ${TOPDIR}/../layers/meta-swupdate \
    ${TOPDIR}/../layers/meta-virtualization \
    ${TOPDIR}/../layers/meta-yocto/meta-poky \
    ${TOPDIR}/../layers/meta-mylayer \
    ${TOPDIR}/../layers/openembedded-core/meta"
BBPATH ?= "${TOPDIR}"
BBFILES ??= ""
--------------8<--------------8<--------------8<--------------

The resulting local.conf is:
--------------8<--------------8<--------------8<--------------
PACKAGE_CLASSES = "package_rpm"
EXTRA_IMAGE_FEATURES += "debug-tweaks"
SERIAL_CONSOLES:forcevariable = "115200;ttyS0"
OE_TERMINAL = "screen"
RM_OLD_IMAGE = "1"

MACHINE ??= "my-machine"
DISTRO ??= "poky"
BBMULTICONFIG ?= ""
--------------8<--------------8<--------------8<--------------

Not sure what more detail is needed; please let me know.

Best,
Dimitri

I missed parts of the machine setup that Bruce asked for:

--------------8<--------------8<--------------8<--------------
DEFAULTTUNE ?= "core2-64"

require conf/machine/include/meta-intel.inc
require conf/machine/include/intel-core2-32-common.inc
require conf/machine/include/intel-common-pkgarch.inc

MACHINE_FEATURES += " \
	intel-ucode \
	pcbios \
	efi \
	rtc \
	wifi \
	bluetooth \
"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"

REQUIRED_VERSION_swupdate = "2025.12"
REQUIRED_VERSION_swupdate:my-machine = "2025.12"

SERIAL_CONSOLE = "115200 ttyS0"
APPEND += "rootwait console=ttyS0,115200 console=tty0"

DISTRO_FEATURES:append = " \
	efi \
	systemd \
	pam \
	alsa \
	x11 \
	opengl \
	wayland \
	virtualization \
"

# The preferred kernel provider
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
IMAGE_INSTALL:append = " kernel-image-bzimage"

# core-base-utils instead of busybox
PREFERRED_PROVIDER_virtual/base-utils = "packagegroup-core-base-utils"
VIRTUAL-RUNTIME_base-utils = "packagegroup-core-base-utils"

# systemd as init and dev manager
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
VIRTUAL-RUNTIME_dev_manager = "udev"

# shadow-base as login manager
VIRTUAL-RUNTIME_login_manager = "shadow-base"

# GRUB with EFI support as boot manager
EFI_PROVIDER = "grub-efi"

# Preferred providers for hwclock and syslog
VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux"
VIRTUAL-RUNTIME_base-utils-syslog = "sysklogd"
--------------8<--------------8<--------------8<--------------

I started migrating from kirkstone a short while ago and haven't yet built everything; I started with the kernel and ran into the issue described here.

Thanks, 

On to Bruce.
Got what you need Bruce ?

I need to see the bbappend that is adding the machine definition (.scc) file to the build, as well as the contents of the .scc file defining the machine.

It is those parts that need to be done in a specific way to inhibit patch application for the core linux-yocto elements.

Hi Bruce,
The details you asked for:

linux-yocto_6.18.bbappend:
--------------8<--------------8<--------------8<--------------
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

KMACHINE:my-machine ?= "common-pc-64"
KBRANCH:my-machine ?= "v6.18/standard/base"
COMPATIBLE_MACHINE:my-machine = "my-machine"

SRC_URI += " \
    file://my-machine-standard.scc \
    file://my-extras.cfg \
    file://my-extras.scc \
"

do_patch:prepend() {
    sed -i \
        -e '/x86_64_defconfig-Fix-warnings.patch/d' \
        -e '/cpu-amd-inhibit-SMP-check-for-qemux86.patch/d' \
        ${STAGING_KERNEL_DIR}/.kernel-meta/patch.queue
}
--------------8<--------------8<--------------8<--------------


my-machine-standard.scc:
--------------8<--------------8<--------------8<--------------
define KMACHINE my-machine
define KTYPE standard
define KARCH x86_64

include my-machine.scc
--------------8<--------------8<--------------8<--------------


my-machine.scc:
--------------8<--------------8<--------------8<--------------
kconf non-hardware ktypes/standard/standard.cfg

include ktypes/base/base.scc

include bsp/intel-x86/intel-x86-64.scc
include arch/x86/x86.scc

include cfg/x86_64.scc
include cfg/virtio.scc
include cfg/8250.scc
include cfg/systemd.scc
include cfg/smp.scc
include cfg/usb-mass-storage.scc
include cfg/boot-live.scc
include cfg/efi.scc
include cfg/efi-ext.scc

include cfg/fs/devtmpfs.scc
include cfg/fs/debugfs.scc
include cfg/fs/btrfs.scc
include cfg/fs/ext4.scc
include cfg/fs/vfat.scc

include cfg/net/ipsec.scc
include cfg/net/ipv6.scc
include cfg/net/ip_nf.scc
include cfg/net/ip6_nf.scc
include cfg/net/bridge.scc

include features/bfq.scc
include features/firmware/firmware.scc
include features/lttng/lttng.scc
include features/blktrace/blktrace.scc
include features/systemtap/systemtap.scc
include features/utrace/utrace.scc
include features/seccomp/seccomp.scc
include features/hrt/hrt.scc
include features/ftrace/ftrace.scc
include features/uprobe/uprobe.scc
include features/kprobes/kprobes.scc
include features/tmpfs/tmpfs-posix-acl.scc
include features/cgroups/cgroups.scc
include features/net_sched/net_sched.scc
include features/kexec/kexec.scc
include features/cryptodev/cryptodev.scc
include features/kvm/kvm.scc
include features/tipc/tipc.scc
include features/xip/xip.scc
include features/oprofile/oprofile.scc
include features/ramconsole/ramconsole.scc
include features/vdso/vdso.scc
include features/fuse/fuse.scc
include features/serial/8250.scc
include features/input/input.scc
include features/edac/edac.scc
include features/rfkill/rfkill.scc
include features/bpf/bpf.scc
include features/power/intel.scc
include features/ixgbe/ixgbe.scc
include features/igb/igb.scc
include features/nfsd/nfsd-enable.scc
include features/sound/snd_hda_intel.scc
include features/latencytop/latencytop.scc
include features/profiling/profiling.scc

include features/netfilter/netfilter.scc
include features/nf_tables/nf_tables.scc
include cgl/features/audit/audit.scc

# Intel DPDK and QAT
include features/intel-dpdk/intel-dpdk.scc
include features/pci-iov/pci-iov.scc
include features/pci/pci.scc
include features/ciphers/ciphers.scc

include backports/backports.scc

# custom additions
include my-extras.scc
--------------8<--------------8<--------------8<--------------


my-extras.scc:
--------------8<--------------8<--------------8<--------------
define KFEATURE_DESCRIPTION "Enable extra kernel features"
define KFEATURE_COMPATIBILITY all
kconf non-hardware my-extras.cfg
--------------8<--------------8<--------------8<--------------


my-extras.cfg:
--------------8<--------------8<--------------8<--------------
# wireguard support
CONFIG_WIREGUARD=m
CONFIG_CRYPTO_LIB_CHACHA=y
CONFIG_CRYPTO_LIB_CURVE25519_GENERIC=y
CONFIG_CRYPTO_LIB_CURVE25519=y
CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y
CONFIG_CRYPTO_LIB_POLY1305=y
CONFIG_CRYPTO_LIB_CHACHA20POLY1305=y
CONFIG_CRYPTO_LIB_SHA256=y

# ipset support
CONFIG_IP_SET=m

# FIB and NF support for nftables
CONFIG_NFT_FIB=m
CONFIG_NFT_FIB_INET=m
CONFIG_NFT_FIB_IPV4=m
CONFIG_NFT_FIB_IPV6=m
CONFIG_IP6_NF_SECURITY=m
CONFIG_IP6_NF_MATCH_RPFILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m

# Hyper-V and VBox support
CONFIG_HYPERVISOR_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_X86_HV_CALLBACK_VECTOR=y
CONFIG_KVM_GUEST=y
CONFIG_ARCH_CPUIDLE_HALTPOLL=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_HALTPOLL_CPUIDLE=y
CONFIG_MMU_GATHER_TABLE_FREE=y
CONFIG_MMU_GATHER_RCU_TABLE_FREE=y
CONFIG_PTP_1588_CLOCK_KVM=y
CONFIG_HYPERV=y
CONFIG_PCI_HYPERV=y
CONFIG_PCI_HYPERV_INTERFACE=y
CONFIG_HYPERV_STORAGE=y
CONFIG_HYPERV_NET=y
CONFIG_HYPERV_VSOCKETS=y
CONFIG_HYPERV_KEYBOARD=y
CONFIG_HYPERV_TIMER=y
CONFIG_HYPERV_BALLOON=y
CONFIG_HYPERV_IOMMU=y
CONFIG_FB_HYPERV=y
CONFIG_DRM_VBOXVIDEO=m
CONFIG_VBOXGUEST=m

# IEEE 802.11 overrides
CONFIG_CFG80211=y
CONFIG_MAC80211=y
CONFIG_IXGBE=y
--------------8<--------------8<--------------8<--------------

Perfect. I'm 99% sure I see it at a glance, but I need to run some tests to be sure. 

Stay tuned.

Thanks Dimitri, that confirms it. The problem is in how the machine .scc
is being delivered to the build, not in its contents.

Patch application for the core linux-yocto elements is only inhibited for
the *discovered* BSP description -- the .scc that the tooling locates on the
kernel-meta search path via KMACHINE/KTYPE. For that BSP (and everything it
includes), the kern-tools deliberately skip the "patch" directives, because
the branch you check out (v6.18/standard/base) already contains those commits.

What you have right now does two things that defeat that:

1. KMACHINE:my-machine = "common-pc-64"
   So the *discovered* BSP is the in-tree common-pc-64 -- its patches are
   correctly skipped. But that is not where your configuration is coming from.

2. SRC_URI += "file://my-machine-standard.scc ..."
   Your own description (which include's arch/x86/x86.scc, bsp/intel-x86,
   ktypes/..., etc.) arrives as a plain SRC_URI .scc fragment. A bare
   file://*.scc is treated as a configuration fragment and is processed in
   BOTH passes -- config AND patch. So every "patch" directive reachable from
   your include tree (the arch/x86 fixups, etc.) gets force-applied, and they
   fail because they are already upstream in 6.18. That is what your sed in
   do_patch:prepend is papering over.

The fix is to let your description be *discovered* as the BSP rather than fed
in as a fragment. Two changes:

(a) Point KMACHINE at your own machine so the tooling finds your .scc:

    KMACHINE:my-machine ?= "my-machine"
    KBRANCH:my-machine  ?= "v6.18/standard/base"

    (your my-machine-standard.scc already has "define KMACHINE my-machine /
     define KTYPE standard", so the BSP search will match it.)

(b) Deliver your .scc files inside a directory tagged "type=kmeta" instead of
    as individual file://*.scc entries. The kmeta tag is what puts the dir on
    the search path (so it can be discovered) WITHOUT adding the files to the
    patch queue. This is exactly the recipe-space form shown in the manual:

    SRC_URI:append:my-machine = " file://my-machine;type=kmeta;destsuffix=my-machine"

    Lay the files out under your layer like:

      recipes-kernel/linux/files/my-machine/my-machine-standard.scc
      recipes-kernel/linux/files/my-machine/my-machine.scc
      recipes-kernel/linux/files/my-machine/my-extras.scc
      recipes-kernel/linux/files/my-machine/my-extras.cfg

    and drop the individual "file://my-machine-standard.scc",
    "file://my-extras.scc", "file://my-extras.cfg" lines from SRC_URI.

(c) Remove the do_patch:prepend sed hack entirely -- it is no longer needed.

With that, the BSP search discovers my-machine-standard.scc as the BSP
definition for my-machine/standard, its configuration is applied as before,
and the patch directives from it and everything it includes (arch/x86,
bsp/intel-x86, ...) are skipped by design -- the same way they are skipped for
common-pc-64. It is also future-proof: you will not have to chase the sed list
as patches rotate in and out of the kmeta across versions.

The bbappend ends up looking roughly like:

    FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

    KMACHINE:my-machine ?= "my-machine"
    KBRANCH:my-machine  ?= "v6.18/standard/base"
    COMPATIBLE_MACHINE:my-machine = "my-machine"

    SRC_URI:append:my-machine = " file://my-machine;type=kmeta;destsuffix=my-machine"

For reference, the delivery format (type=kmeta;destsuffix=) is documented under
"Kernel Metadata Outside the Recipe-Space" in the "Working with Advanced
Metadata (yocto-kernel-cache)" manual:

    https://docs.yoctoproject.org/kernel-dev/advanced.html

One caveat: that section documents the *delivery* format but does not currently
spell out the patch-skipping behavior that bit you here (a discovered BSP has
its patches inhibited; a bare file://*.scc fragment does not). I will get that
clarified in the docs so the next person does not hit the same wall.

(If you do not actually need a custom BSP and only want to add config on top of
the stock Intel machine, the other option is to keep KMACHINE = common-pc-64
and add only your fragments via KERNEL_FEATURES -- with no arch/bsp/ktype
includes of your own. But the discovered-BSP approach above is the right one if
you want my-machine to stand on its own.)

Thank you Bruce,
Your guidance and detailed explanations are very much appreciated.

I followed the discovered-BSP approach that you suggested; the two patches in question were dutifully skipped and the kernel build was successful.

All the best,
Dimitri