From b959d1b9c23736a93982e5e60261b5d1e9f38319 Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Wed, 2 Sep 2026 02:49:17 -0700 Subject: [PATCH 1/2] fix(os/yocto): gate dstack.cfg on the built kernel config check-kernel-config.sh exists because a kconfig fragment line is a wish, not a guarantee: kconfig silently drops a request whose dependencies are not met and silently clamps a tristate. The mkosi backend runs it over its whole fragment. The yocto backend ran it over dstack-docker.cfg only, leaving dstack.cfg's seventy-odd assertions unchecked. The reason was three of those assertions being false. CONFIG_SCSI, CONFIG_INPUT and CONFIG_HOTPLUG_CPU lose to machine-level KERNEL_FEATURES -- features/scsi/disk.scc is appended for the dstack machine and the machine's own feature set brings the other two -- so the built kernel has all three enabled while the fragment claims otherwise. Three lines that could not be satisfied kept the other seventy unverified along with them, which is a bad trade. Drop the three and gate the file. The fragment now says only what the build actually does, and every remaining line is checked before anything ships. This matters more than it did last week: the sixteen =n lines added in "drop guest kernel drivers no CVM can reach" went into this same file. They were verified by hand with bitbake -c configure, but nothing stopped a later KERNEL_FEATURES addition from quietly pulling one of those drivers back while the fragment still claimed it was off -- exactly the state CONFIG_SCSI is in today. Not addressed here: whether the yocto image can actually drop SCSI. The mkosi guest kernel does, verified, so the two guest kernels genuinely differ on it. Settling that needs a boot test on GCP and AWS, where the root disk may be virtio-scsi rather than virtio-blk, so it belongs in its own change rather than being guessed at from a build that cannot boot. Verified against the real built .config: the gate passes with both fragments, and fails as it should when CONFIG_SCSI=n is put back or when any other force-enabled symbol is asserted off. --- .../recipes-kernel/linux/files/dstack.cfg | 17 ++++++++++++++--- os/yocto/scripts/export-artifacts.sh | 13 +++++++------ 2 files changed, 21 insertions(+), 9 deletions(-) diff --git a/os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg b/os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg index 81ee54d79..d8d37b19e 100644 --- a/os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg +++ b/os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg @@ -41,12 +41,9 @@ CONFIG_KPROBES=y CONFIG_PM=n CONFIG_SUSPEND=n CONFIG_PM_SLEEP=n -CONFIG_HOTPLUG_CPU=n CONFIG_HOTPLUG_PCI=n CONFIG_BT=n CONFIG_MMC=n -CONFIG_SCSI=n -CONFIG_INPUT=n CONFIG_WLAN=n # dm-verity verifies the rootfs in the initramfs (no modules loaded yet), so the @@ -127,3 +124,17 @@ CONFIG_NVRAM=n CONFIG_PROVIDE_OHCI1394_DMA_INIT=n CONFIG_EARLY_PRINTK_DBGP=n CONFIG_NETCONSOLE=n + + +# CONFIG_SCSI, CONFIG_INPUT and CONFIG_HOTPLUG_CPU are deliberately absent even +# though the mkosi guest kernel turns all three off. KERNEL_FEATURES for the +# dstack machine pulls in features/scsi/disk.scc, and the machine's own feature +# set brings the other two, so a =n here loses the merge and the built kernel +# has them enabled regardless. Asserting them was worse than not asserting +# them: the three lines were the only reason this whole file could not be +# checked, which left the other seventy assertions unverified as well. +# +# Whether the yocto image can actually drop SCSI -- the mkosi one does, so the +# two guest kernels differ here -- needs a boot test on GCP and AWS, where the +# root disk may be virtio-scsi rather than virtio-blk. That belongs in its own +# change. diff --git a/os/yocto/scripts/export-artifacts.sh b/os/yocto/scripts/export-artifacts.sh index bfa059669..dca204cef 100755 --- a/os/yocto/scripts/export-artifacts.sh +++ b/os/yocto/scripts/export-artifacts.sh @@ -112,16 +112,17 @@ fi # it here before anything is published -- shipping a guest image whose kernel # quietly lacks an asserted capability is the failure this guards against. # -# Only dstack-docker.cfg is gated for now. dstack.cfg still has six lines the -# build does not satisfy (CONFIG_HOTPLUG_CPU/SCSI/INPUT are forced back on by -# machine-level features, and CONFIG_TLS/CRYPTO_GCM/CRYPTO_CHACHA20POLY1305 do -# not come out as asserted); each needs its own decision rather than a blanket -# edit, so gating it belongs in a follow-up. +# Both fragments are gated. dstack.cfg used to be exempt because three of its +# lines were not satisfied by the build -- CONFIG_SCSI, CONFIG_INPUT and +# CONFIG_HOTPLUG_CPU lose to machine-level KERNEL_FEATURES -- and those three +# kept the other seventy assertions unchecked along with them. They have been +# dropped from the fragment, which now says only what the build actually does. KERNEL_CONFIG_FILE="$COMMON_IMG_DIR/kernel-config" if [ -f "$KERNEL_CONFIG_FILE" ]; then "$REPO_ROOT/os/common/scripts/check-kernel-config.sh" \ "$KERNEL_CONFIG_FILE" \ - "$YOCTO_DIR/layers/meta-dstack/recipes-kernel/linux/files/dstack-docker.cfg" + "$YOCTO_DIR/layers/meta-dstack/recipes-kernel/linux/files/dstack-docker.cfg" \ + "$YOCTO_DIR/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg" else echo "Error: kernel config not found: $KERNEL_CONFIG_FILE" >&2 exit 1 From 091e51f8846ce398a93849476c60775178919feb Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Wed, 2 Sep 2026 02:53:17 -0700 Subject: [PATCH 2/2] docs(os/yocto): name the actual cause for each dropped assertion The comment attributed all three to machine-level KERNEL_FEATURES. That is only true of one of them, and only indirectly. HOTPLUG_CPU is def_bool y with no prompt, so no fragment can set it anywhere -- the mkosi guest kernel has it enabled too and simply never asserted otherwise. INPUT has a prompt only under EXPERT, which this machine does not set, so it falls back to default y, and CONFIG_VT=y selects it as well; mkosi turns it off only because it has EXPERT=y and VT=n together. SCSI is the one KERNEL_FEATURES case, and even there the feature sets CONFIG_BLK_DEV_SD=y, which depends on SCSI and drags it in. Getting this right matters for the follow-up: two of the three cannot be fixed by touching KERNEL_FEATURES at all. --- .../recipes-kernel/linux/files/dstack.cfg | 27 ++++++++++++++----- os/yocto/scripts/export-artifacts.sh | 9 ++++--- 2 files changed, 25 insertions(+), 11 deletions(-) diff --git a/os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg b/os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg index d8d37b19e..9f49c406b 100644 --- a/os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg +++ b/os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg @@ -126,13 +126,26 @@ CONFIG_EARLY_PRINTK_DBGP=n CONFIG_NETCONSOLE=n -# CONFIG_SCSI, CONFIG_INPUT and CONFIG_HOTPLUG_CPU are deliberately absent even -# though the mkosi guest kernel turns all three off. KERNEL_FEATURES for the -# dstack machine pulls in features/scsi/disk.scc, and the machine's own feature -# set brings the other two, so a =n here loses the merge and the built kernel -# has them enabled regardless. Asserting them was worse than not asserting -# them: the three lines were the only reason this whole file could not be -# checked, which left the other seventy assertions unverified as well. +# CONFIG_SCSI, CONFIG_INPUT and CONFIG_HOTPLUG_CPU are deliberately absent. +# Each was asserted =n here and each came out y in the built kernel, for a +# different reason: +# +# HOTPLUG_CPU is `def_bool y, depends on SMP` in arch/x86/Kconfig, with no +# prompt. No fragment anywhere can set it. The mkosi guest kernel has it +# enabled too; it simply never claimed otherwise. +# +# INPUT only gets a prompt `if EXPERT`, and CONFIG_EXPERT is not set for this +# machine, so it falls back to its `default y`. CONFIG_VT=y also selects it. +# The mkosi kernel manages to turn it off because it has EXPERT=y *and* VT=n +# -- neither alone would be enough. +# +# SCSI is pulled in sideways: KERNEL_FEATURES appends features/scsi/disk.scc +# for the dstack machine, whose disk.cfg sets CONFIG_BLK_DEV_SD=y, and +# BLK_DEV_SD depends on SCSI. +# +# Asserting them was worse than leaving them out: these three were the only +# reason this whole file could not be checked, which left the other seventy +# assertions unverified along with them. # # Whether the yocto image can actually drop SCSI -- the mkosi one does, so the # two guest kernels differ here -- needs a boot test on GCP and AWS, where the diff --git a/os/yocto/scripts/export-artifacts.sh b/os/yocto/scripts/export-artifacts.sh index dca204cef..e5944d4e4 100755 --- a/os/yocto/scripts/export-artifacts.sh +++ b/os/yocto/scripts/export-artifacts.sh @@ -113,10 +113,11 @@ fi # quietly lacks an asserted capability is the failure this guards against. # # Both fragments are gated. dstack.cfg used to be exempt because three of its -# lines were not satisfied by the build -- CONFIG_SCSI, CONFIG_INPUT and -# CONFIG_HOTPLUG_CPU lose to machine-level KERNEL_FEATURES -- and those three -# kept the other seventy assertions unchecked along with them. They have been -# dropped from the fragment, which now says only what the build actually does. +# lines were not satisfied by the build: CONFIG_HOTPLUG_CPU has no prompt to +# set, CONFIG_INPUT has none either without EXPERT, and CONFIG_SCSI is pulled +# in by the SCSI disk driver that KERNEL_FEATURES enables. Those three kept the +# other seventy assertions unchecked along with them; the fragment documents +# each case and now says only what the build actually does. KERNEL_CONFIG_FILE="$COMMON_IMG_DIR/kernel-config" if [ -f "$KERNEL_CONFIG_FILE" ]; then "$REPO_ROOT/os/common/scripts/check-kernel-config.sh" \