test(os): combine #1931 #1945 #1966 RC2 KVM gate - #2002
Conversation
…ironment too A pithead verb run by hand over SSH reads /etc/environment through PAM, never a unit's drop-in, so on the RC1 image `./pithead backup` restarted the stack from the org's registry (no 2.0.0 there) and left it down. The tar-append copies the rootfs's own /etc/environment out (it carries PITHEAD_ENGINE), appends the pin, and appends the file back as a leaf so mkimage's tar -xf lands it whole. verify-image --test asserts the pin beside the engine line; release mode refuses any PITHEAD_REGISTRY= line there. Measured: synthetic tar, both lines extracted; the new assertion on the RC1 image (built before this fix) fails exactly one row, 119/1 against the chain's 119/0. Positive control (an image built with the fix) waits for the bench. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NeSaJPWy7AkhYcYpGVkxBJ
…re it backs up The leg read "provisioned" off two identical `podman ps` readings, which cannot see the wizard's `up` still inside its tor-health wait, holding the mutation lock. The backup then waited that `up` out and, when it died, archived and restarted the wreck, and the red said "could not take the source backup" instead of naming the failed setup. tests/os/provisioning-settled.sh: settled when neither pithead-firstboot nor pithead-boot is `activating` (word-anchored: `deactivating` is on its way out), bounded, with a verdict line that carries the units and the wizard's spooled error. run.sh swaps the settle loop for it, line-neutral at its ceiling. Ten fixture rows in test-appliance-boot-remint.sh drive the helper with a stubbed _ssh; five mutants each red their own rows. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NeSaJPWy7AkhYcYpGVkxBJ
…ce-regressions-followup # Conflicts: # tests/stack/test-lifecycle.sh
…939-1947-1982-kvm-gate
|
Independent exact-head review: PASS at The correctness and security reviews found and rechecked the fail-closed VM teardown, libvirt query errors, nested restore-artifact retention, approval-fixture cleanup, root-owned release staging, detached parent-lock continuity, RigForge re-arm ordering, immutable Compose provenance, and post-promotion digest visibility retry. No critical, high, or medium actionable defect remains in the PR delta. Bounded local evidence: release domain 58/0; parent-lock 31/0; borrowed-pool re-arm 9/0; focused appliance and procedure controls passed. Fresh CI and the exact-image KVM battery remain separate execution gates before merge. |
Summary
This combines and supersedes #1939, #1947, and #1982 so their interacting appliance changes can be reviewed, run through CI, and exercised by one exact-image KVM lifecycle against the current
develophead and RigForge v1.17.3.Closes #1931.
Closes #1945.
Closes #1966.
Closes #1994.
Validation
fd511612634a21ada55a349684c13a3a284f1aebThe three remaining local
selftest-e2e-phasesfailures are the known BSDwcwhitespace difference; the changed phase, token, launch-intent, PID, and drain assertions pass locally and are exercised by Linux CI.Companion release
Requires p2pool-starter-stack/rigforge#492 (
test: fail closed across combined appliance gates). The two must be tested together: this branch carries the immutable RigForge build override through the appliance lifecycle and forwards the rollback input to the detached matrix runner, and #492 is the v1.17.4 companion those gates run against. Neither should merge without the combined acceptance matrix covering both.CI status
Both red checks at head
d3a8a96care inherited fromdevelop, not introduced here:google.golang.org/grpc v1.83.1, vendored into thecosignanddocker-composebinaries.developpins that raise inos/rootfs/Dockerfile; this branch does not touch the pin. The bump tov1.83.2is already committed on Refactor repository into feature folders and finish oversized module splits #2005 and clears it there.2a231511, which belongs to Refactor repository into feature folders and finish oversized module splits #2005's branch and is not an ancestor of this head. gitleaks scans every pushed ref, so an unrelated in-flight branch reddens this job on every open PR.Both clear once #2005 lands on
develop; nothing to change here.