Rehearsal 2026-08-09 COMPLETE: data BYTE-IDENTICAL, journey needs a shell twice
gates / gates (push) Successful in 23s
gates / gates (push) Successful in 23s
The walk finished. All four planted files came back byte-identical out of snapshot 41c830db, including two Hungarian accented filenames verified as RAW NAME BYTES (NFC preserved) — the discriminator the Gate 0 positive control was built for, having been watched failing on an NFC->NFD rename that renders the same. Unlock 21s, restore 13.2s. It finished only because a terminal was available twice: - R-273 CLOSED. v0.128.0 was published as a package and never git-tagged, so every install died at 5/8. Tag pushed on operator instruction after an INDEPENDENT download proved the package sha equalled the vouched value; --resume then reached Day-0 SUCCESS in 3m49s on controller 0.210.0. The two guards that would stop the class recurring are still owed. - R-280 NEW, rank 1. A reinstalled box cannot re-attach its own data drive by any dashboard route: /api/disks/candidates returns empty because both lists are built from the UNCLAIMED-disk scan, and the drive is claimed precisely because it is also the backup target. Correct for "initialise", over-broad for "attach", which is non-destructive by definition. The restore page meanwhile says "Ez ket kattintas" and points at that empty list. Cleared by POSTing /mnt/sys_drive — an internal path no household could produce. Also new: R-281 the hub said NOTHING through the entire reinstall and the sealed-backup tripwire did not fire on a real unseal (positive control: 2 events all day fleet-wide); R-282 one code with three names and a mail pointing at a page the box does not show; R-283 hub reads "Claimed 18d ago" while the box serves its setup page; R-284 "almost full" over a 93%-free store. R-274 NARROWED by measurement rather than left as written: the resume path fetched the vouched golden correctly, because --resume skips the preflight that does local discovery. What survives is real — discovery is sort|tail -1 with no manifest comparison — but a FRESH install taking a stale golden is still not observed, and the row says so. Two of my own claims were refuted by test and are recorded as refuted, not quietly dropped: the leftover sudoers file is inert (sudo skips dotted names), and demo-hp's off-site tier was healthy all along.
This commit is contained in:
@@ -1,8 +1,9 @@
|
||||
# REHEARSAL — the BYO reinstall walk (2026-08-09)
|
||||
|
||||
> **Status: IN PROGRESS.** Pre-phase and Gate 0 are complete; STOP 1 passed. The walk (P1–P7) has not
|
||||
> started. This file is written before the destructive phase deliberately — a finding that exists only
|
||||
> in a session that later crashes is a finding nobody has.
|
||||
> **Status: COMPLETE.** All phases walked; the integrity verdict is **BYTE-IDENTICAL**. §1–§8 were
|
||||
> written before the destructive phase deliberately — a finding that exists only in a session that
|
||||
> later crashes is a finding nobody has — and are left as written, including one claim later refuted
|
||||
> by test (§8.3 → §9a) and one by measurement (§7.2 F-9).
|
||||
|
||||
**Venue: `demo-hp` (HP t740, `felhom-host`, guest 9201, customer `demo-hp`).** Operator-approved at
|
||||
STOP 1. **Driven from DooPlex.** All times UTC unless marked; the host runs CEST (UTC+2).
|
||||
@@ -512,14 +513,200 @@ which golden it takes.**
|
||||
|
||||
---
|
||||
|
||||
## 10. Where the run stands
|
||||
## 9a. P3 resumed — and the install succeeded
|
||||
|
||||
**Reached: P1 ✓, P2 ✓, P3 ✗ (blocked).** P4–P7 not attempted.
|
||||
**Unblocked on operator instruction ("proceed").** `v0.128.0` was annotated at `28ba8593b8` and pushed
|
||||
after an **independent download** confirmed the published package's sha256 equals the hub's vouched
|
||||
`c6eba73b…`. Both config URLs then served 200. `--resume` completed in **3 m 49 s**
|
||||
(09:30:30 → 09:34:19 UTC): `Day-0 provision SUCCESS`, controller **0.210.0**, agent **0.128.0**, guest
|
||||
9201 onboot, pool member, all 16 ACL assertions green, controller healthy in ~18 s.
|
||||
|
||||
**The honest answer to §2's question is: NOT YET ANSWERABLE, and the reason is itself the answer for
|
||||
today.** A machine wiped today cannot be set up again at all — not because the data is gone (it is
|
||||
safe, in snapshot `41c830db` and in two local tiers), but because the install refuses at step 5 of 8 on
|
||||
a missing git tag. The walk found a hard stop before it ever reached the question about data.
|
||||
**R-274 partly refuted, and recorded as such.** Step 7 fetched the **vouched 0.210.0** — because
|
||||
`--resume` skips preflight, and preflight is where local auto-discovery sets `GOLDEN_VOLID`. So the
|
||||
fresh and resume paths disagree, and the resume path is the safe one. What survives: discovery is
|
||||
`sort | tail -1` (newest local) with **no manifest comparison**, so a box whose newest local golden
|
||||
predates the vouched one still installs stale. Full text in the register.
|
||||
|
||||
**The dataset is intact and waiting.** Nothing about Gate 0 needs redoing when the walk resumes:
|
||||
snapshot `41c830db` holds all four files, the before-manifest is committed, and the comparator is proven.
|
||||
## 10. P4 — first contact, as the customer
|
||||
|
||||
**A clean pass, and worth saying so plainly.** Within four minutes of the install finishing, the
|
||||
customer's own URL — fetched from outside the box, over the public internet — served:
|
||||
|
||||
> **A szerver beállítása** · Demo HP
|
||||
> *Add meg az e-mailben kapott beállító kódot, majd válassz saját jelszót a vezérlőpult védelméhez.*
|
||||
> Beállító kód · Új jelszó (min. 12 karakter) · Új jelszó megerősítése
|
||||
> *Nem kaptad meg a kódot? Új kód kérése*
|
||||
|
||||
Unprompted, in Hungarian, naming the customer, with a self-service route if the code never arrived,
|
||||
and nothing anywhere asking for a command line. The hub showed the host **ONLINE** at agent 0.128.0.
|
||||
|
||||
**Two findings here, neither fatal:** the hub still read *"Claimed 18d ago"* while the box was serving
|
||||
its first-run page (**R-283**), and the code that arrives is named three different things across the
|
||||
three surfaces, with the mail pointing at an „Elfelejtett jelszó" page the box does not show
|
||||
(**R-282**). The reset code was nonetheless **accepted on the setup page** — 302 and a session — so
|
||||
this is naming, not function.
|
||||
|
||||
## 11. P5 — getting the machine back to work
|
||||
|
||||
### 11.1 The recovery screen, unsought — the headline pass
|
||||
|
||||
The **first thing** on the dashboard after claiming, with nothing sought:
|
||||
|
||||
> **Adatok visszaszerzése** — *Ezt a gépet újratelepítették. A korábbi, házon kívüli mentéseid
|
||||
> megvannak* — a sealed package held centrally, **sealed at 2026-08-04T11:11:37Z**, openable only with
|
||||
> the customer's code; *nobody can replace it — not Felhom, not support, not the operator*; and
|
||||
> **„Ebben a lépésben semmit nem állítunk vissza és semmi nem változik."**
|
||||
> Field: **Helyreállítási kód (tíz szó)**.
|
||||
|
||||
R-193's screen meeting reality on a genuinely rebuilt box. It answered all three of its questions and
|
||||
its seal date matches `host_escrow.created_at` exactly.
|
||||
|
||||
*(Nit: the seal date is rendered raw as `2026-08-04T11:11:37Z` to a Hungarian household — ISO-8601 in
|
||||
UTC where a localised date belongs.)*
|
||||
|
||||
### 11.2 STOP 3 — the unlock
|
||||
|
||||
Entered at the box's own screen, from a file, never on a command line. **21 seconds**, and it listed
|
||||
what it found without restoring anything:
|
||||
|
||||
| app | legutóbbi mentés | méret |
|
||||
|---|---|---|
|
||||
| **calibre-web** | 2026-08-09 10:30 (CEST) | **3.8 MB** |
|
||||
| felhom-offbox | ″ | 6.8 KB |
|
||||
| opengist | ″ | 182.3 KB |
|
||||
| privatebin | ″ | 6.8 KB |
|
||||
|
||||
That is exactly the Gate 0 snapshot set, seen from the customer's side.
|
||||
|
||||
### 11.3 The wall — R-280, and it is rank 1
|
||||
|
||||
The restore page diagnoses the situation perfectly and then sends the customer to an empty page:
|
||||
|
||||
> *„Előbb csatold vissza az adatmeghajtót. … **Ez két kattintás:** Tárhely → Meghajtók, »Meglévő
|
||||
> meghajtó csatolása«. Utána gyere vissza ide."*
|
||||
|
||||
**It is not two clicks; it is zero possible clicks.** `GET /api/disks/candidates` →
|
||||
`{"initialize":[],"attach":[]}`. The agent is fine — `GET /api/disks` returns the NVMe in full — but
|
||||
`handleDiskCandidates` builds *both* lists from the **unclaimed-disk** scan, and demo-hp's NVMe is
|
||||
deliberately both the user-data drive and the `felhom-backup` target, so it is claimed and never
|
||||
offered. Correct for `initialize`; over-broad for `attach`, which is non-destructive by definition.
|
||||
|
||||
It cascades: no store → Calibre-Web's install page degrades to *„Nincs regisztrált adattároló — adja
|
||||
meg kézzel az útvonalat"*; no app → every restore row reads „Nincs telepítve".
|
||||
|
||||
**Escape hatch used, and recorded as off-path:** `POST /settings/storage/add` with
|
||||
`storage_path=/mnt/sys_drive` succeeded first try — an internal path, the very one registered before
|
||||
the wipe, that no household customer could produce. Everything unblocked immediately afterwards and
|
||||
the deploy form became a proper picker („Tárhely (sys_drive) — 64.2 GB szabad").
|
||||
|
||||
### 11.4 App redeploy
|
||||
|
||||
`calibre-web` deployed from the catalogue through the dashboard's own API in **1 m 36 s**, running and
|
||||
healthy. The catalogue itself was complete and in Hungarian, every app „Nincs telepítve".
|
||||
|
||||
*(Also observed: the deploy page warned „A kiválasztott tárhely majdnem megtelt." over an option
|
||||
carrying `data-free-percent="93"` and „64.2 GB szabad" — an apparent inverted threshold, **R-284**.)*
|
||||
|
||||
## 12. P6 — getting the data back
|
||||
|
||||
Three options, each explained, none starting without a question. **R-204 item 3 is visibly fixed:**
|
||||
option 1 states in as many words that it does *not* bring the customer's own files back.
|
||||
|
||||
| step | wall clock |
|
||||
|---|---|
|
||||
| full-restore **prepare** (3.8 MB) | **8 s** |
|
||||
| full-restore **execute** | **13.2 s** (10:27:32.08 → 10:27:45.29 UTC) |
|
||||
|
||||
> *„A(z) calibre-web teljes mentése visszaállítva ellenőrző mappába:
|
||||
> `/mnt/sys_drive/felhom-data/backups/offsite-restore/calibre-web` — a saját fájljaiddal együtt. A
|
||||
> meglévő adatok változatlanok."*
|
||||
|
||||
Restored to a **verification folder**, not into place — honest about it, and R-213's territory.
|
||||
|
||||
### THE INTEGRITY VERDICT — **BYTE-IDENTICAL**
|
||||
|
||||
```
|
||||
expected 4 file(s); found 4
|
||||
VERDICT: BYTE-IDENTICAL
|
||||
```
|
||||
|
||||
Compared against `GATE0-before-manifest.json`, keyed on **raw name bytes**:
|
||||
|
||||
| sha256 | bytes | name |
|
||||
|---|---|---|
|
||||
| `54b773c46bbfd994…` | 3 145 728 | `binary-3mb.bin` |
|
||||
| `52a5c5ebfcac247f…` | 59 | **`árvíztűrő-tükörfúrógép.txt`** — name bytes `c3a1…` identical, NFC preserved |
|
||||
| `15d2024dfc224162…` | 25 | **`nested/őszibarack.md`** — name bytes identical |
|
||||
| `924497918e55fe6d…` | 21 | `plain.txt` |
|
||||
|
||||
Four expected, four restored, zero differences. The accented filenames survived as **bytes**, not
|
||||
merely as rendered text — the discriminator the Gate 0 positive control was built to enforce.
|
||||
|
||||
## 13. P7 — what the hub thought was happening
|
||||
|
||||
**It thought nothing.** Across the whole reinstall the hub recorded **zero events and zero
|
||||
notifications** for demo-hp. Positive control (standing rule 3): the hub logged **2 events all day
|
||||
across all customers**, newest `db_dump_completed` at 00:30:07 — the store is reachable and the
|
||||
silence is real.
|
||||
|
||||
- **The good half:** no false alarm fired during a legitimate reinstall, which is what P7 watches for.
|
||||
- **The owed half (R-281):** `escrow_blob_served` exists as the tripwire for exactly this moment —
|
||||
*"If no recovery is in progress on that box, investigate"* — and **has fired for demo-hp before**
|
||||
(last 2026-08-04 20:12:54). Today's real unseal fired it not at all. A reinstall and a stolen
|
||||
machine look identical to the operator.
|
||||
|
||||
## 14. Teardown — all four layers
|
||||
|
||||
1. **The machine** — my instruments (`fp.py`, `restored.json`, the installer, the passphrase file)
|
||||
removed. Guest 9201 running and healthy. **`drill-r50` (VM 300) untouched throughout**, as predicted.
|
||||
2. **The host** — `local-lvm` 36.97 % → 21.85 % (bare) → **32.35 %** (rebuilt). Pre-existing leftovers
|
||||
found and deliberately **not** removed, recorded instead: `c11-scratch`, the orphaned
|
||||
`vzdump-lxc-9100` archives (now three).
|
||||
3. **The hub** — **no customer or appliance record created**; `demo-hp` retained deliberately per the
|
||||
runbook. Nothing to delete.
|
||||
4. **The off-site side** — **18 snapshots, newest still `9e38b84c` / `78b93f04` at 08:30 UTC**, i.e.
|
||||
unchanged since Gate 0. The restore was a pure read. **No prune, no forget, no delete by me**; the
|
||||
only retention that ran was inside the product's own backup call at Gate 0, which reported
|
||||
`18 snapshot(s)` itself.
|
||||
|
||||
## 15. The answer to §2's question
|
||||
|
||||
**Yes — the data comes back, byte for byte. No — not in one sitting, and not without a shell.**
|
||||
|
||||
The walk completed: **P1 ✓ P2 ✓ P3 ✓ P4 ✓ P5 ✓ P6 ✓ P7 ✓**, and the verdict is BYTE-IDENTICAL.
|
||||
But it completed only because two hard stops were cleared by someone who could open a terminal and
|
||||
read source code:
|
||||
|
||||
1. **R-273** — the install died at 5/8 on a git tag that was never pushed. Cleared by a release action.
|
||||
2. **R-280** — the data drive could not be re-attached through any dashboard route, while the page
|
||||
promised „két kattintás". Cleared by POSTing an internal path a customer could not know.
|
||||
|
||||
Neither is a data-integrity problem. Both are **journey** problems, and both stop a household dead.
|
||||
This is the same shape the R-201 walks kept finding: **the data half passes, the journey half fails.**
|
||||
|
||||
**What the product did beautifully, and should not be lost in the finding count:** the box came up on
|
||||
its own at the vouched version; the setup page appeared unprompted, in Hungarian, naming the customer;
|
||||
the recovery screen appeared **without being sought** and stated plainly that nothing would be changed
|
||||
by unlocking; the unlock took **21 s**; the restore took **13.2 s** and said honestly that it had put
|
||||
the files in a verification folder rather than back in place. Sixteen ACL assertions verified
|
||||
themselves. No false alarm fired.
|
||||
|
||||
### Wall clocks
|
||||
|
||||
| segment | |
|
||||
|---|---|
|
||||
| P1 uninstall | **60 s** |
|
||||
| P2 preflight (2 refusals, then pass) | ~6 min |
|
||||
| P3 install — first attempt, FAILED | 44 s |
|
||||
| P3 install — resumed, SUCCESS | **3 m 49 s** |
|
||||
| P4 first contact (box live on its own URL) | within ~4 min of install |
|
||||
| STOP 3 unlock | **21 s** |
|
||||
| app redeploy (calibre-web) | **1 m 36 s** |
|
||||
| restore prepare + execute | **8 s + 13.2 s** |
|
||||
| **bare machine → verified files** | **1 h 49 m 22 s** (08:38:23 → 10:27:45 UTC) |
|
||||
| — of which the product's own work | **≈ 7 m 47 s** |
|
||||
|
||||
**The 1 h 49 m must not be quoted as the customer number** — it is dominated by the R-273 diagnosis and
|
||||
release fix (~38 min) and by two waits on a human. **The ≈ 7 m 47 s must not be quoted either**: it is
|
||||
what the product costs when someone already knows every answer. The honest figure for an unaided
|
||||
household is **undefined, because an unaided household does not finish.**
|
||||
|
||||
Reference in New Issue
Block a user