Repository navigation
BMC/BIOS configuration audit + routine KVM screenshot verification system #1811
Description
Relocated from dezren39/darwin-nix#502 on 2026-10-28 - it was filed in the wrong repo; developing-today/code is its home. Original content follows, verbatim.
Problem
The core machines share one motherboard/CPU spec and should be setting-identical, but BIOS and BMC ("ASM") firmware versions and settings have never been audited. Undocumented divergence is exactly the failure mode Drew wants eliminated: everything bootstrappable and declarative, nothing that "just existed forever".
Source: idea register 2026-10-20 (goal stand-up-lab-cluster-talm-talos-cozystack-postgres-rustfs).
What we want
A system that:
- knows every device's KVM/BMC IP address and can reach it programmatically;
- screenshots and verifies every BIOS/BMC setting on a routine basis (KVM-over-IP capture, or Redfish/IPMI reads where the platform exposes settings directly);
- diffs each machine against the golden config for the core spec and reports drift;
- emits the verified settings as a reappliable config (declarative file in git), so a board swap or reset is a re-apply, not archaeology — "make some config out of it and pray we never have to touch it."
Acceptance / first steps
- From the hardware-inventory issue: the canonical list of BMC/KVM IPs and current BIOS + BMC firmware versions per machine.
- Pick the access method per platform (Redfish API preferred; scripted KVM screenshot + OCR/template-match as fallback) and prototype on one core machine.
- Define the golden settings profile for the core motherboard (every BIOS and BMC setting we care about) as a checked-in file.
- One-by-one audit of all core machines against the profile; fix or record every divergence.
- Schedule the routine re-verification (cron/CI-style job) and decide where drift reports land.
Open questions
- Does the BMC expose BIOS settings via Redfish on this platform, or is screenshot verification the only path?
- Firmware update policy: converge all core machines to one BIOS/BMC version, or freeze at "verified identical settings" per version?
Acceptance criteria
- A BMC/BIOS audit exists for the core machines: firmware versions and settings per machine, with divergences listed.
- A repeatable check (script or documented routine) can re-verify settings parity, including the KVM screenshot verification described in the body.
- Divergences found are either corrected or filed as follow-up issues and linked.
Metadata
Metadata
Assignees
Labels
Large: multi-day or open-ended; expect staged check-insInfrastructure / host-portability workIntake review done: acceptance criteria, links, and normalized labels addedOrdinary priority (the default)Queue or user escalation stateFiled directly by a humanQueue or user escalation stateQueue packet kind: verify, reproduce, and route this itemQueue or user escalation state
Activity
developing-today commentedon Oct 28, 2026
CODE-745
dezren39 commentedon Oct 28, 2026
Comments carried over from dezren39/darwin-nix#502 (verbatim, in order):
dezren39 - 2026-10-26T21:33:31Z
Intake review
🤖 Fleet monitor intake pass (protocol §5).
Related: the 2026-10-20 lab-cluster idea register (linked in the body); sibling issues dezren39/darwin-nix#501, dezren39/darwin-nix#503, dezren39/darwin-nix#504, dezren39/darwin-nix#505.
Live check: still open and unlabelled at intake; no merged PR resolves it — the body states BIOS/BMC versions and settings have never been audited.
Notes / risks: this needs physical/BMC access to the basement machines, so it may sit blocked on access rather than on design; the audit inventory should land alongside dezren39/darwin-nix#501's hardware inventory.
Suggested approach: pair with dezren39/darwin-nix#501: gather BMC/BIOS state while gathering hardware stats, record divergences, and make the parity check repeatable.
dezren39 - 2026-10-27T03:26:02Z
Superseded by #1081 (firmware / BIOS / BMC audit epic)
The basement cluster program was seeded into its standard structure on 2026-10-26 (roadmap + epics + sub-issue tasks in developing-today/code, all in org Project #4 as Area=lab-cluster). Do not start work from this issue - work is tracked at #1081 (firmware / BIOS / BMC audit epic). Full mapping is on nixdezren39/nix#508. Left open for Drew to close as superseded.
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
Triage — task 7744 (lane code-f): BLOCKED on Drew / lab inputs, escalated
Verified at main
91c3b193: #1811 is OPEN, part of EPIC #1817 (Basement Talos/Cozystack cluster). Nothing in this repo implements or inventories any of it yet — code search for BMC finds only planning/roadmap mentions (planning/roadmaps/basement-cluster.md, the 2026-10-27 status doc); there is no hardware-inventory artifact and no audit tooling in the tree.Why this cannot proceed from the queue (blockers, in order):
Ordering once unblocked: hardware inventory (IPs + firmware versions) → Redfish capability probe on one core machine → Drew's firmware-policy call → golden profile file → per-machine audit → scheduled re-verification.
My read for Drew: this is lab-program work under EPIC #1817, not a code fix; the smallest useful next step is the hardware-inventory pass on the core machines, which also unblocks the access-method question. Escalating rather than inventing scope.