fix(ci): derive KVER from the defconfig instead of hardcoding it

[mcfbytes]

Fixes the six ci-tests.sh failures on #39.

Cause

scripts/ci-tests.sh:90 was literally KVER=6.18.38. Every module check scopes to usr/lib/modules/$KVER/, so when the kernel moved to 6.18.39 they all started looking in a directory that no longer exists:

FAIL  modules.dep non-empty
FAIL  modules.alias non-empty
FAIL  module vermagic (6.18.38, ARMv7)
FAIL  xone: all 9 .ko.xz modules present
FAIL  out-of-tree WiFi: 8812au + 8821au .ko.xz present
FAIL  in-kernel WiFi: rtw88_8814au.ko.xz present

The build was fine.

Why derive rather than bump the number

What makes this worth fixing properly is how it failed. The messages point at the wrong subsystem — "kernel-module packages are stamped; a kernel bump needs make <pkg>-dirclean + rebuild" — which is a real failure mode this project has actually hit before. So the output reads as a genuine stale-kmod regression rather than a stale constant. A hardcoded version here doesn't fail safe, it fails misleadingly, and bumping it to 6.18.39 would just re-arm the same trap for the next bump.

It now derives from configs/mister_de10nano_defconfig — the same source of truth scripts/export-kernel-tree.sh and renovate-hash-sync.yml already read — with a hard failure if it can't be read.

Two details preserved deliberately:

• Reads the MAIN image's defconfig specifically. The existing comment is careful that these checks must not glob across variant trees, since mister_rt.fragment overrides this symbol for the RT variant (7.2-rc3). Deriving from the main defconfig keeps exactly that scoping.
• Anchored to ^, last match. The defconfig explains this symbol in a comment that quotes it verbatim, so an unanchored match returns two lines — the exact bug fixed in fix(ci): anchor kernel version grep — unanchored match built a URL with a newline #42. Verified: 2 matches unanchored, 1 anchored.

Renovate: nothing needed

A derived value has nothing to pin. #46's coverage (both defconfigs plus the RT fragment) is already on this branch, so all three real pins are managed. I also confirmed no other hardcoded kernel version remains in build logic — build.yml, release.yml, and mk-sdcard.sh all derive theirs; regen-triage.sh's 5.15.1 is the stock fork kernel and unrelated to this pin.

Verification

Ran ci-tests.sh against a synthetic rootfs.tar carrying usr/lib/modules/6.18.39/:

PASS  modules.dep non-empty
PASS  modules.alias non-empty
PASS  module vermagic (6.18.39, ARMv7): consistent across all 12 modules
PASS  xone: all 9 .ko.xz modules present
PASS  out-of-tree WiFi: 8812au + 8821au .ko.xz present
PASS  in-kernel WiFi: rtw88_8814au.ko.xz present

All six flipped. (Other checks in that run fail on fixture gaps — I didn't fake btusb modaliases or the xone firmware blob — not related to this change.) shellcheck clean.

Touches only scripts/ci-tests.sh, so no conflict with #46.

Note on branching: feat/ci-rt-kernel is checked out in your /mnt/source/Buildroot_MiSTer-rt-ci worktree (4 behind origin at the time), so I branched off it and opened this PR rather than pushing into a branch you have live.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UFdgJXQKvrucXeKDami499

[Copilot]

Pull request overview

This pull request fixes scripts/ci-tests.sh module/vermagic checks by deriving the kernel version (KVER) from the main Buildroot defconfig rather than hardcoding it, preventing CI breakage whenever the kernel version pin is bumped.

Changes:

• Replace hardcoded KVER=... with extraction from configs/mister_de10nano_defconfig.
• Add a clear fatal error path when the defconfig value can’t be read (to avoid misleading downstream failures).
• Document why the value must be derived and why it must be sourced from the main defconfig (not RT/variant pins).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.