THE DATA: PASS. All three sentinels byte-identical out of snapshot f5c53b03, including the 12 MB binary and the accented Hungarian filename whose NAME BYTES are identical too. Disk -> restic -> SFTP -> Storage Box -> rebuilt machine -> disk, intact. THE JOURNEY: FAIL, and further from the line than the previous walk. The claim worked first try (302 in 0.164s). Then: / lands on the launcher with no recovery pointer, /recovery 302s away, and the remote page offers to CREATE a new recovery code — which would orphan the history the customer's code protects. There is no field anywhere to enter the code they hold. The operator's documented remedy also refuses, correctly and fail-closed. Recovery needed three guest command lines. R-241 — and the cause is a success this same walk proved six hours earlier. OffsiteRecoveryOffer() shows the screen only when (a) there is NO repository password (pristine rebuild) or (b) one exists but the history will not open under it. Overnight the credential self-heal collected the staged credential and applied the tier, writing a FRESH key at 03:18Z — so (a) is false; and (b) is unreachable because orphan detection needs a run, and runs are blocked by escrow_state=pending. The gap is self-locking. Measured keys: on-disk 9b4a9a9d... vs recovered-from-R 30ef574f... This is R-218's shape one level up: succeeding at the self-heal stopped the box OFFERING the recovery it still needed. Registers: R-201 moved to its outcome; R-241 filed; capability map's recovery row stays FAIL with both halves and the cause named; STATUS rewritten for the operator. Highest ID R-238 -> R-241. The venue is left with the recovered key in place and the self-heal key moved aside, never deleted. Teardown still owed.
This commit is contained in:
@@ -295,3 +295,83 @@ with **zero human action, on a box that has not even been claimed yet**:
|
||||
**That is R-218's consume half, R-236's withdrawal, and the previous walk's dead end 1, all settled by
|
||||
one unattended observation.** By the time the operator claims this machine in the morning, its
|
||||
off-site tier is already up — which is exactly the property the recovery journey needed and never had.
|
||||
|
||||
---
|
||||
|
||||
# THE MORNING REMAINDER, AND THE VERDICT
|
||||
|
||||
| # | step | result |
|
||||
|---|---|---|
|
||||
| 1 | claim with the emailed code | **worked FIRST TRY** — 302 in 0.164 s, accents intact (md5 identical source→box) |
|
||||
| 2 | log in | landed on **„Indítópult"** — **the recovery screen did NOT appear**, and `/recovery` **302s away** |
|
||||
| 3 | read the screen as a customer | there is nothing to read: no recovery pointer anywhere on the landing page |
|
||||
| 4 | enter the recovery code | **impossible through the UI — there is no field to enter it in** |
|
||||
| 5 | read the listing | not reachable by a customer |
|
||||
| 6 | restore the sentinels | **byte-identical — but only via an operator command line** |
|
||||
|
||||
## The verdict, both halves separately
|
||||
|
||||
### THE DATA: **PASS**
|
||||
|
||||
All three sentinels came back **byte-identical**, out of snapshot `f5c53b03`, under the key recovered
|
||||
from the sealed package with R:
|
||||
|
||||
```
|
||||
863fa61c091c64488d8224b12f3915bfe264c46f9cad3d3d874b2ce725a1e5ee FINALWALK-SENTINEL-A.txt
|
||||
28630aa93119af0790b749671ef3896dbab88f8d239da8313ef5631fa068efda FINALWALK-SENTINEL-C-12MB.bin
|
||||
b56668663035a332ae9b8a77b5847c8310c7ff48c5c2068114060561389ccf23 FINALWALK-őrszem-ékezetes-árvíztűrő.txt
|
||||
name hex: 46494e414c57414c4b2d c591 72737a656d2d c3a9 6b657a657465732d c3a1 7276 c3ad 7a74 c5b1 72 c591 2e747874
|
||||
```
|
||||
|
||||
The accented filename's **bytes** are identical too. The backup promise holds: disk → restic → SFTP →
|
||||
Storage Box → rebuilt machine → disk, intact.
|
||||
|
||||
### THE JOURNEY: **FAIL — and further from passing than the last walk**
|
||||
|
||||
**The customer has no route to their data at all.** Not a slow one, not a confusing one — none.
|
||||
|
||||
- `/` lands on „Indítópult" with **no recovery pointer**.
|
||||
- `/recovery` **302s away** — the screen has retired itself.
|
||||
- `/backups/remote` says **„Helyreállítási kód szükséges … Helyreállítási kód létrehozása"** — it
|
||||
offers to **create a NEW code**, which would mint a new key and orphan the very backups R protects.
|
||||
- **Even the operator's documented remedy refuses**: `--recover-offsite-install` returned
|
||||
*„[REFUSED] a DIFFERENT repository password is already present… which history to keep is not a
|
||||
decision this command may take. Nothing written."* — correct, fail-closed, and a dead end.
|
||||
|
||||
The only way through was to move the fresh key aside by hand and re-run the install. That is three
|
||||
guest command lines, and it is what the walk exists to measure the absence of.
|
||||
|
||||
## WHY — and it is the success I praised six hours earlier
|
||||
|
||||
`OffsiteRecoveryOffer()` offers the screen on exactly two conditions: **(a)** no repository password at
|
||||
all — the pristine rebuilt box — or **(b)** a password exists but the history will not open under it
|
||||
(`OffboxOrphaned()`).
|
||||
|
||||
Overnight, unaided and exactly as designed, the credential chain **gave this box a fresh repository
|
||||
password** at 03:18Z. That made **(a) false**. And **(b)** is false too, because orphan detection only
|
||||
fires when a run tries the repo — and runs are blocked by `escrow_state: pending`.
|
||||
|
||||
**The box sits in the gap between the two conditions, and the gap is self-locking:** it cannot detect
|
||||
the orphan without running, it cannot run without escrow, and it cannot escrow without minting a new
|
||||
code that destroys what R protects.
|
||||
|
||||
Measured, not deduced — the two keys:
|
||||
|
||||
```
|
||||
on-disk (self-heal, 03:18Z) : 9b4a9a9dcec7898e7544f35b18470aac77c3d9064e5d3a302897617fa62edd65
|
||||
recovered from R : 30ef574fe492a43f89bf1a5071c44e89f51c44c6b08ebcb184b320a2634fad75
|
||||
```
|
||||
|
||||
**This is R-218's shape one level up.** That finding read *"succeeding at recovery stopped the box
|
||||
asking for what it still needed."* Here: **succeeding at the credential self-heal stopped the box
|
||||
offering the recovery it still needed** — and the self-heal is the very mechanism this same walk
|
||||
proved working, six hours earlier, as its best result. Both things are true, and reporting only the
|
||||
first would have been the more flattering half of one night.
|
||||
|
||||
Filed as **R-241**.
|
||||
|
||||
## State the machine is in
|
||||
|
||||
The venue is left with the **recovered** key in place (`30ef574f…`) and the self-heal key **moved
|
||||
aside, not deleted** (`repo_password.selfheal-aside`). The old repository opens; two snapshots; the
|
||||
restored copy sits in the controller container at `/tmp/fwrestore`. Teardown remains owed.
|
||||
|
||||
Reference in New Issue
Block a user