makearmy/le-app
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

refresh Phase 2A transaction and readiness gates

Browse source
This commit is contained in:
makearmy 2026-07-12 17:36:55 -04:00
parent 2cf249d6f2
commit da03be61a9
23 changed files with 2409 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

46
docs/le-app-database-migration/phase2a-host-maintenance/README.md
View file

@ -88,21 +88,49 @@ The maintenance script refreshes an isolated sync database, normalizes package n
The final live `pacman -Syu` must refresh the live sync databases as part of the complete transaction. Pacman cannot expose that post-refresh final interactive transaction for wrapper comparison without either staging a live `pacman -Sy`-only state or replacing the transaction with an unsafe custom workflow. The script therefore requires two exact operator phrases before launch and then requires the operator to review Pacman's final package table at its native interactive `Y/n` prompt. Answer `n` on any difference. This limitation is explicit and is not represented as machine-enforced equality.
## Package-preview evidence
## Approved package-preview evidence
The retained preview is:
The refreshed post-NoMachine preview is:
```text
/tmp/le-phase2-package-decision-post-nomachine-20260712.1vyjKk
```
Its durable normalized baseline and inventories are stored in
`approved-transaction/`. The authoritative transaction is 220 packages: 215
upgrades, 5 new packages, 1,985.98 MiB download, and +760.30 MiB installed-size
delta. The prior 221-package transaction is superseded.
Exactly 234 failed `drkonqi-coredump-processor@…` units are reviewed as
nonproduction desktop crash-processing failures. Their checksummed complete
state and invocation-ID fingerprint is under `failed-unit-disposition/`. Any
addition, removal, state or invocation change, checksum failure, or other failed
unit is a hard stop. The scripts do not reset them. `nxserver.service` is not an
expected critical unit; its unused `nomachine` package was removed normally.
## Snapper readiness history and maintenance gate
On 2026-07-12 the ordinary empty `/.snapshots` directory was replaced by Btrfs
subvolume ID 300, owned `root:root` mode `0750`. Manual snapshot 1 succeeded and
exact snap-pac testing created and verified snapshots 2 and 3. Btrfs quotas were
intentionally left disabled.
Preflight verifies that `/.snapshots` remains a Btrfs subvolume. After both
operator approvals and immediately before Pacman, maintenance creates a uniquely
described explicit Snapper snapshot, captures and validates its numeric ID,
verifies its numbered directory and Btrfs snapshot subvolume, and records the ID
in the result. It verifies the snapshot again after Pacman, independently of
snap-pac's return code. Unavailable quota accounting is a warning, not evidence
of snapshot failure. No script enables quotas or runs `snapper setup-quota`.
The older preview remains at:
```text
/tmp/le-phase2-package-decision-20260712.Mn7mIx
```
Expected report checksum:
```text
195d74afe121556294318d0ed49e3fb5504088dbb31a4c0786b8adea44f1369d phase2-package-decision-report.md
```
The directory occupies approximately 2.4 GiB. Do not delete it yet. It becomes cleanup-eligible only after the operator accepts the maintenance record, the upgrade/reboot succeeds, and retained evidence has been copied to durable approved storage if required. Cleanup is a later explicit command and is not included in any script.
It occupies approximately 2.4 GiB and must not be deleted yet. It is historical,
not the approved baseline. Cleanup remains a later explicit action.
## Hard stop conditions