agent's diff parser failed on kernel config changes
Fixes a patch agent diff parser failing on kernel configuration changes, where comparing kernel config files (for example /boot config files or the running config) across a kernel update produces parse errors or thousands of false diffs because the config format, ordering, or defaults changed between versions. Use when kernel-change detection breaks after kernel updates. Not for detecting application config drift, which uses different tooling.
TL;DR
Kernel configs are generated artifacts with version-specific structure: new symbols appear, defaults flip, and the file header and ordering change, so a naive text diff or a strict parser melts down exactly when a kernel update happens. Parse the config into a symbol-to-value map (set, unset, module, built-in, string), compare maps semantically, and classify changes into expected-new-version noise (new symbols at defaults) versus meaningful changes (a previously set symbol removed or flipped). Report only the meaningful set, with the full map diff available as evidence.
agent's diff parser failed on kernel config changesUse this when
- The agent errors out reading the new kernel config, or reports thousands of changed lines after a routine kernel update.
- The flagged changes are almost all new symbols or reordered entries.
- A symbol the fleet actually cares about (a filesystem, a security option) changing would be invisible in the flood.
Not for this skill when
- The config file is missing because the distro does not ship one in boot. Read the running config from proc config.gz or the package files instead.
- The comparison is between two hand-maintained configs for the same kernel. A plain diff is appropriate there.
Steps
- Collect sample config pairs (previous and new kernel) from representative hosts and reproduce the parser failure or flood offline. Verify: the failure mode is reproduced with real files
- Rewrite the comparison as a semantic map diff: parse each config into symbol states, ignoring comments, ordering, and header lines. Verify: identical-semantics files with different ordering produce an empty diff
- Define meaningful change rules with the platform owner: a set symbol becoming unset or absent, a value flip on a watchlist of security and filesystem symbols, versus new symbols appearing at defaults. Verify: the rules are written down and the watchlist is explicit
- Classify and re-run on the sample pairs. Verify: the output is a short list of meaningful changes with the noise summarized as counts
- Wire the classifier into the wave post-checks and add the sample pairs as regression fixtures. Verify: the next kernel update produces a readable kernel-change note in the wave report
Variant phrasings
kernel config diff parser fails new version semantic diff
The main phrasing.
config symbol map compare built-in module unset
The implementation phrasing.
kernel update config changes noise vs meaningful watchlist
The triage phrasing.
Compatibility: Compatibility: Linux kernels shipping config in boot or via proc config.gz (IKCONFIG); symbol semantics are kconfig-standard across distros.
Why it happens
Kernel configuration is a database wearing a text file costume. Each release adds and occasionally removes symbols, and the generated file reflects the whole kconfig tree, not just your choices. Text-diff tooling measures the file; the agent needs to measure the choices. The semantic map approach also makes the watchlist idea possible: a handful of symbols (SELinux, filesystems, virtualization options) deserve human eyes when they change, and everything else deserves a count, not an alarm.
Edge cases / pitfalls
- A symbol that disappears entirely can mean a feature was removed or renamed and split; check the new symbol set for the successor before declaring a regression.
- Distros patch their kernels, so the same version number on two distros can have different symbol sets; keep fixtures per distro.
- The running config and the boot file can differ after a partial update; record which source each reading came from.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstQp6LYXJNJngLE0kENJr1g