fix(tests/os): the 4 persistent KVM battery failures — plant db poisoning + a wallet p2pool refuses to run

[VijitSingh97]

Diagnoses and fixes the 4 persistent KVM battery failures against the RC20 tree (kvm-battery2.log). All four were harness-leg defects; the product finding uncovered along the way is filed as #829, not patched here.

Failures 1–3 — keep-reinstall leg (added by #807): one root cause

podman --root "$T/containers/storage" load — the plant — also writes a libpod database (db.sql + libpod/) into the graphroot, and that db records the mktemp mount path as the static/graph root. podman refuses a store whose recorded paths differ from its own, so after the reinstall every podman command on the target failed with:

Error: database static dir "/tmp/tmp.ZQJsW0ZxUN/containers/storage/libpod" does not
match our static dir "/data/containers/storage/libpod": database configuration mismatch

…invisibly, because _ssh drops stderr. Hence all three symptoms at once: the wizard container could never start (no :80), podman images printed nothing (id: none — read as "empty store"), and nothing served the marker.

Why the bench passed the same code path the same day: on the real bench the old image was loaded by the machine itself, against /data/containers/storage — recorded paths match. Only the harness plant ever embeds a foreign path. The PR #807 author flagged the plant as the risk; that instinct was exact.

Fix: the plant now drops db.sql + libpod/ after capturing the image ID — modelling the machine that really ran the product (its first real boot recreates the db against the right paths, images intact). Mechanism and fix verified against the appliance rootfs image's own podman 5.4.2, then the full --phase install leg re-run on gouda.

Failure 4 — provision-phase local-miner leg (added by #812): two layers, neither a budget

Layer 1 (harness bug; product half filed as #829): the harness wallet 4 + 94×A passes the host's shape gate but fails the base58 checksum — and p2pool SIGABRTs on it at startup (exit=134 in the container probe; Exited (139) crash-loop in the guest). The leg's only probe (proxy logs accepted) sat downstream of a corpse. The harness now submits a checksum-valid public address (XMRig's donation wallet, plainly labelled).

Layer 2 (environment, by product design): even with a valid wallet, an accepted share needs p2pool to hold a job, a job needs a synced node — and on a fresh machine the product itself holds mining until the chains sync (#35). Confirmed live in the kept guest:

Container p2pool stop: ok (HTTP 204)
Container xmrig-proxy stop: ok (HTTP 204)
Required chain(s) still syncing — holding p2pool, xmrig-proxy until synced.

A KVM guest syncing Monero over Tor onto a 40 GiB scratch disk never clears that gate: no budget is honest, 15 minutes or 15 hours. The bench accepted a share in under two minutes because the bench has a synced node — that assertion lives in the bench release e2e, where it already runs.

Fix: the leg now proves the pre-sync appliance link by link — built-in worker up (unchanged), the hold is the deliberate one (sync-gate line present and p2pool stopped clean; the #829 crash-loop dies non-zero under the same hold line, so the new leg still catches that class), and the rendered worker config dials the machine's own stratum (#796).

Verification

• --phase install re-run on gouda: green (was 3 failures)
• --phase provision re-run on gouda: green (was 1 failure)
• make lint clean; docs/dev/appliance-release.md provision row updated to match the leg

🤖 Generated with Claude Code