fix(os/yocto): gate dstack.cfg on the built kernel config - #1166
Open
kvinwang wants to merge 2 commits into
Open
fix(os/yocto): gate dstack.cfg on the built kernel config#1166kvinwang wants to merge 2 commits into
kvinwang wants to merge 2 commits into
Conversation
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.
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The change is narrow, aligns with the existing multi-fragment checker contract, and the fragment adjustments are consistent with the stated goal of making Yocto kernel assertions enforceable.
Pull request overview
This PR brings the Yocto guest-kernel pipeline in line with the mkosi backend by ensuring the full Yocto kernel fragment set is verified against the built kernel .config before artifacts are exported/shipped.
Changes:
- Gate
os/yocto/.../dstack.cfgwithcheck-kernel-config.shduring Yocto artifact export (in addition to the already-gateddstack-docker.cfg). - Remove three
=nassertions (CONFIG_HOTPLUG_CPU,CONFIG_SCSI,CONFIG_INPUT) from the Yoctodstack.cfgfragment because they do not match the kernel produced by the Yocto machine configuration. - Add an explanatory note to
dstack.cfgdocumenting why those assertions are intentionally absent and why dropping them enables gating the rest of the fragment.
File summaries
| File | Description |
|---|---|
| os/yocto/scripts/export-artifacts.sh | Extend kernel-config gating to include both Yocto kernel fragments during artifact export. |
| os/yocto/layers/meta-dstack/recipes-kernel/linux/files/dstack.cfg | Remove unsatisfied assertions and document why those symbols are intentionally not asserted in Yocto. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
check-kernel-config.shexists because, in its own words, "a 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.cfgonly:That left
dstack.cfg's 73 assertions completely unchecked.Why it was exempt
Three of them are false. Compared against a real built
.config:They lose to machine-level
KERNEL_FEATURES—linux-yocto%.bbappendappendsfeatures/scsi/disk.sccfor the dstack machine, and the machine's own feature set brings the other two. The fragment claims the kernel has them off; it does not.Three lines that could not be satisfied kept the other seventy unverified along with them. That is a bad trade, and it is the whole reason the exemption existed.
What changed
Drop the three, gate the file. The fragment now says only what the build actually does, and every remaining line is checked before anything ships.
Why this got more urgent
The sixteen
=nlines added in #1160 went into this same file. They were verified by hand withbitbake -c configure, but nothing stopped a laterKERNEL_FEATURESaddition from quietly pulling one of those drivers back while the fragment still claimed it was off — which is exactly the stateCONFIG_SCSIis in today. The gate is what turns those sixteen from a one-time check into an invariant.Not addressed here
Whether the yocto image can actually drop SCSI. The mkosi guest kernel does — verified in #1160,
CONFIG_SCSI=nsurvives itsolddefconfig— so the two guest kernels genuinely differ on it, along withCONFIG_INPUT.Settling that needs a boot test on GCP and AWS, where the root disk may be virtio-scsi rather than virtio-blk. Guessing from a build that cannot boot is how you turn a documentation problem into an outage, so it belongs in its own change. The fragment carries a comment saying so.
Testing
Against the real built
.configfrombitbake -c configure virtual/kernel:CONFIG_SCSI=nput backwanted CONFIG_SCSI=n, got CONFIG_SCSI=y→ exit 1bash -nandshellcheck -x -P SCRIPTDIRclean onexport-artifacts.sh(noteos/yoctois excluded from the repo's shellcheck hook, so this was run by hand).