final walk Phase A + the five checks; R-239 (delivery gap) and R-240 filed
gates / gates (push) Failing after 13m22s
gates / gates (push) Failing after 13m22s
Phase A complete on a NEW venue (demo-hp VM 324, customer finalwalk). Installed
from the published ISO — verified byte-identical to iso.felhom.eu — claimed, app
deployed, three sentinels placed, escrow ceremony 6/6 with restic_pw_sealed=true,
R held in one 0600 file on DooPlex, off-site backup taken and the three sentinels
PROVEN IN THE SNAPSHOT BY NAME (snapshot 1da4f80d, 12.0 MB).
THE HEADLINE: a fresh install lands on agent 0.127.0 (vouched, no hand upgrade —
that half works) and controller 0.203.0, while the newest is 0.205.0. The vouched
golden still bakes 0.203.0, so tonight's box has neither R-237 nor R-234. Filed as
R-239: a delivery gap, not a regression. Every closure claimed for those two is
true of the code and false of the fleet until a golden is baked and vouched.
The five checks, on that box:
T1 ok + the old bare-count warning (no next step)
T2 FAILS — both runs say "elindult", the second as a success flash
T3 FAILS — toggle off hides an existing snapshot; wizard 302s away
T4 ok, and the wording is still "Sikeres" beside "nothing is selected" -> R-240
T5 PASSES — driven as a browser does, prepare -> full_prep -> confirm -> commit
completed; R-238 confirmed a harness artifact, not a product defect
HARNESS FAULT, caught by the §4 gate: the first off-site run reported ok with a
26.6 KB repo — impossible for a 12 MB sentinel. I had placed the files under
.../adatok/felhom-data/userdata/... while this box's namespace root is
/mnt/felhom-drives/adatok directly. The product was correct throughout; proving by
listing rather than by a green status is what caught it before any destruction.
Nothing destroyed. The venue stands.
This commit is contained in:
@@ -0,0 +1,112 @@
|
||||
# THE FINAL WALK (R-201) — overnight, unattended — journal
|
||||
|
||||
**Venue:** `demo-hp` VM **324 `finalwalk-appliance`** (`finalwalk.felhom.eu` @ 192.168.0.142), guest
|
||||
LXC **9201**, hub customer **`finalwalk`**, host id **`finalwalk-ed05d6`**. All three earlier venues
|
||||
were torn down on 2026-08-06; nothing was reused except a **freed** Storage Box sub-account number.
|
||||
|
||||
**Written before the destruction, per §9.9.**
|
||||
|
||||
---
|
||||
|
||||
## THE HEADLINE FINDING — a fresh install does NOT get the fixes
|
||||
|
||||
| | landed on | vouched |
|
||||
|---|---|---|
|
||||
| agent | **0.127.0** ✅ | 0.127.0 |
|
||||
| controller | **0.203.0** ❌ | golden 0.203.0 |
|
||||
| newest released controller | **0.205.0** | — |
|
||||
|
||||
**No hand upgrade was needed and none was applied — that part works.** But the vouched golden still
|
||||
bakes controller **0.203.0**, so a box installed tonight is **two releases behind**: it has neither
|
||||
**R-237** (v0.204.0, the restore list keyed on the store) nor **R-234** (v0.205.0, the skipped-app
|
||||
verdict and the single-flight message).
|
||||
|
||||
**This is not a regression — it is a delivery gap.** The fixes exist, are tested and are pushed; what
|
||||
is missing is a golden carrying them and a vouch. Three of tonight's five checks measure exactly those
|
||||
fixes, and they measure the OLD behaviour because that is what a customer receives.
|
||||
|
||||
Timeline: bind **21:56:42Z** → agent 0.127.0 ONLINE **21:59:01Z** (2 m 19 s) → controller 0.203.0
|
||||
reporting **22:01:03Z** → guest 9201 running.
|
||||
|
||||
---
|
||||
|
||||
## Phase A — the fixture (six records, §4)
|
||||
|
||||
**1. Installed from the published ISO.** `felhom-installer-1.26.1-pve9.2-1.iso`, verified
|
||||
**byte-identical to the published copy** (`sha256 f3cc86d5f0ec…59a6` local == iso.felhom.eu). Served
|
||||
installer script tag confirmed `installer-v1.25.0` on both git-syncs.
|
||||
|
||||
All three known TUI traps handled: GRUB's graphical default (down+ret inside one command, terminal
|
||||
installer first try); the Hungarian keymap switched to **U.S. English** — **positive control:** the
|
||||
administrator email rendered `finalwalk@felhom.eu`, and `@` is `shift-2` on US vs `AltGr+V` on HU, the
|
||||
only available evidence for the 24 masked password characters; and `--boot` set in its own `qm set`
|
||||
with the ISO detached, both verified from `qm config` **before first boot** (`boot: order=scsi0`,
|
||||
`ide2` lines = 0), with auto-reboot unchecked and confirmed `[ ]` with focus moved away.
|
||||
|
||||
Day-0 fired unaided: pairing code **`T63-485`**, matching MAC `bc:24:11:c6:73:d0`.
|
||||
|
||||
**2. Claimed** through the real `/claim` form. The reset-code hatch was used — **permitted in Phase A
|
||||
by §3**, and it is a guest command line, so it is counted as such and does not touch the Phase-B rule.
|
||||
|
||||
**3. App + three sentinels.** `calibre-web` deployed with `HDD_PATH=/mnt/felhom-drives/adatok`,
|
||||
`state: running` **and `health_probe.healthy: true`**.
|
||||
|
||||
| # | file | bytes | sha256 |
|
||||
|---|---|---|---|
|
||||
| A | `FINALWALK-SENTINEL-A.txt` | 57 | `863fa61c091c64488d8224b12f3915bfe264c46f9cad3d3d874b2ce725a1e5ee` |
|
||||
| B | `FINALWALK-őrszem-ékezetes-árvíztűrő.txt` | 80 | `b56668663035a332ae9b8a77b5847c8310c7ff48c5c2068114060561389ccf23` |
|
||||
| C | `FINALWALK-SENTINEL-C-12MB.bin` | 12 582 912 | `28630aa93119af0790b749671ef3896dbab88f8d239da8313ef5631fa068efda` |
|
||||
|
||||
Sentinel B's filename **as hex**, identical at source and on the box:
|
||||
`46494e414c57414c4b2d c591 72737a656d2d c3a9 6b657a657465732d c3a1 7276 c3ad 7a74 c5b1 72 c591 2e747874`
|
||||
— `ő é á í ű ő`, **no `efbfbd`**. Written from explicit bytes via `pct push` + a Python placer; no
|
||||
shell chain ever saw the name.
|
||||
|
||||
**4. Escrow ceremony.** Preflight **6 of 6 green** (`pbs_storage_id` · `dr_tier` · `age_binary` ·
|
||||
`hub_upload` · `staged_secret` · `sudo_grant`), `agent_supported: true`.
|
||||
Result: `phase: done` · **`restic_pw_sealed: TRUE`** · `uploaded: true` · `entropy_bits: 129.24` ·
|
||||
`key_fingerprint: 81:dc:91:ce:a1:d0:50:3a:…:68:d5`.
|
||||
|
||||
**R** was claimed ONE-SHOT and streamed file→file to `~/.config/finalwalk/R_finalwalk.txt` (`0600`,
|
||||
**DooPlex only**); the guest and jump-host copies were `shred -u`'d and the raw response deleted. It
|
||||
was never rendered, never an argument, never a log line. Shape only: **10 words, 85 characters**.
|
||||
|
||||
**5. Off-site backup, and the sentinels proved BY NAME.**
|
||||
|
||||
```
|
||||
1da4f80d 2026-08-06 22:24:33 finalwalk [felhom-offbox, calibre-web]
|
||||
/mnt/felhom-drives/adatok/userdata/media/books/FINALWALK-SENTINEL-A.txt 57
|
||||
/mnt/felhom-drives/adatok/userdata/media/books/FINALWALK-SENTINEL-C-12MB.bin 12582912
|
||||
/mnt/felhom-drives/adatok/userdata/media/books/FINALWALK-őrszem-ékezetes-árvíztűrő.txt 80
|
||||
```
|
||||
|
||||
> **HARNESS FAULT, and the §4 gate is what caught it.** The FIRST run reported **`ok` with a 26.6 KB
|
||||
> repository** — impossible for a 12 MB incompressible sentinel. Listing showed why: I had placed the
|
||||
> files under `…/adatok/**felhom-data**/userdata/…`, while this box's namespace root is
|
||||
> `/mnt/felhom-drives/adatok` **directly**, so they were never in the app's data at all. **The product
|
||||
> was correct throughout** — it captured the unit and the declared mandatory path, including
|
||||
> calibre-web's real `metadata.db`. Moved to the right path, re-run: 12.0 MB and all three listed. The
|
||||
> gate's rule — *prove by listing, never by a green status* — is exactly what stopped a destruction
|
||||
> that would have proven nothing.
|
||||
|
||||
**6. Pre-destruction truth.** Controller `0.203.0` · agent `0.127.0` · PBS wrapper **matches
|
||||
vouched** · guests **1/1** · DR recipe **present** · key escrow **present** · snapshot `1da4f80d` ·
|
||||
1 snapshot · **12.0 MB** · repo `sftp:u629488-sub4@…:/home/felhom-repo` port 23.
|
||||
|
||||
---
|
||||
|
||||
## The five checks (§5) — on controller 0.203.0, which is what a customer gets
|
||||
|
||||
| | check | observable | verdict |
|
||||
|---|---|---|---|
|
||||
| **T1** | selected app that cannot be captured (`opengist`, not deployed) → run | verdict **`ok`**; warning „Figyelmeztetés: 1 alkalmazásnak nincs elérhető mentése, ezek kimaradtak: opengist"; counters intact (1 snapshot, 12.0 MB, `last_success` advanced) | **old behaviour.** v0.205.0 also keeps `ok` for an *undeployed* app — deliberately — but says which, why and what to do. Here the message is a bare count with **no next step** |
|
||||
| **T2** | two off-site runs back to back | run #1 „A távoli mentés elindult…"; run #2 **the same message**, `flash_error` count **0** | **FAILS.** This is R-234's measured cause, live. v0.205.0 answers „Már fut egy távoli mentés — ez a kérés nem indított újat…" as an error |
|
||||
| **T3** | toggle future-backup **off** for an app that HAS a snapshot, then open the restore page | restore entries for calibre-web: **0**; wizard **302** away | **FAILS.** R-237 exactly: the customer's existing backup is hidden by a setting about the future |
|
||||
| **T4** | off-site run with nothing selected | verdict `ok`; warning **„Sikeres — nincs mentésre jelölt alkalmazás"** | unchanged, as required — **and the wording is still *"successful"* beside *"nothing is covered"*. Filed (§8) |
|
||||
| **T5** | full-restore wizard driven **as a browser does** | prepare → `&full_prep=calibre-web&full_size=12.8 MB` → following it revealed the confirm → commit → **`ok: true`**, „A(z) calibre-web teljes mentése visszaállítva ellenőrző mappába" | **PASSES.** R-238 confirmed a **harness artifact**, not a product defect — carrying the state the wizard hands back makes it complete |
|
||||
|
||||
**Live sentinels re-verified after T5: all three MATCH** (the verification restore writes to a
|
||||
separate folder and left live data untouched).
|
||||
|
||||
**T2 and T3 are the same finding as the headline**, seen from the customer's side: the fixes are
|
||||
written and pushed but not delivered, so tonight's box still exhibits both defects.
|
||||
Reference in New Issue
Block a user