Notifications
Clear all
Topic starter
11/07/2026 8:25 pm
TL;DR: KernelCI is used by CIP to test long-term support Linux kernels, and this guide explains how to register a new board, extract compatible strings, and add scheduler and platform entries so automated boot testing can run against the right device profile. The operational issue is governance of test infrastructure as much as board enablement, because misalignment between platform metadata and lab setup breaks coverage and weakens release confidence.
NHIMG editorial — based on content published by Cybertrust Japan: KernelCI configuration for CIP SLTS board onboarding, part 1
Questions worth separating out
Q: How should teams prevent configuration drift when adding new boards to KernelCI?
A: Use one authoritative platform record for names, compatible strings, device tree references, and scheduler bindings.
Q: Why do metadata mismatches break automated hardware testing?
A: Automated testing depends on exact matching between the declared platform and the real device.
Q: What do teams get wrong about inherited CI configuration?
A: They often treat inherited YAML fragments as harmless reuse, when they are actually shared control logic.
Practitioner guidance
- Standardise board metadata before scheduler onboarding Validate platform name, machine family, device tree blob, and compatible strings against a single source of truth before adding a board to KernelCI.
- Separate lab execution from scheduling policy Keep LAVA lab configuration and scheduler rules under distinct review so changes in boot orchestration do not accidentally alter test eligibility or coverage boundaries.
- Treat inherited YAML as shared control logic Review base fragments, merged defaults, and board-specific overrides together because a change in one inherited template can alter multiple platforms at once.
What's in the full article
Cybertrust Japan's full post covers the step-by-step configuration details this analysis intentionally leaves aside:
- The exact platform YAML structure used to register a new board in KernelCI.
- The compatible-string extraction workflow for matching a device to the correct kernel source tree.
- The scheduler-cip.yaml job pattern used to trigger boot testing in a CIP SLTS context.
- The LAVA and lava-docker setup notes needed to build a test lab and connect multiple devices.
👉 Read Cybertrust Japan's guide to KernelCI configuration for CIP SLTS board onboarding →
KernelCI and CIP SLTS integration: what teams need to change?
Explore further
11/07/2026 8:55 pm
Board enablement in CI is an identity problem as much as an automation problem. A KernelCI platform entry is effectively a machine identity for the test target, because the pipeline trusts exact metadata to decide where workloads execute. When compatible strings, scheduler rules, and lab inventory drift apart, the result is broken validation rather than a clean exception. Practitioners should treat test-target identity as governed configuration, not loose infrastructure data.
A question worth separating out:
Q: How can practitioners tell if KernelCI coverage is actually working?
A: Coverage is working when a board can be added, scheduled, and boot-tested repeatedly without manual correction. The signal is not just that a job exists, but that the correct device type receives the intended job and returns stable results across runs. If onboarding requires repeated fixes, the configuration model is not yet reliable.
👉 Read our full editorial: KernelCI configuration for CIP SLTS: what practitioners need to know
