CORRECTION: the edge break was UFS damage from an unclean power cut, not an update ...

My earlier "partially-applied OPNsense update" diagnosis was an inference from the shape
of the symptom and is refuted by the log: ZERO pkg-static / opnsense-update / firmware
lines in the entire 477 KB serial history.

What precedes the first missing-library error is an fsck salvage of a badly damaged UFS
root -- UNREF FILE x2533, UNEXPECTED SOFT UPDATE INCONSISTENCY x785, SALVAGE? yes x257,
then immediately ld-elf.so.1: libcrypto.so.17 not found. The libraries were fsck
casualties.

Causal chain: the 08-01 memory resize was an IN-PLACE tofu update, which this document
already records BOUNCES the guest (confirmed on dc1 as canary that day). A bounce of a
containment VM is a hard power cut to every inner VM. Under D-127 the DC edges are the
only inner VMs with autostart=true, so they were the only ones hard-cut and auto-
restarted onto damaged filesystems.

Confirmed by the dc1 control -- same event, different severity: dc0 2533/785 with ld-elf
errors, dc1 76/181 with zero. dc1's "healthy edge that does not forward", logged earlier
as a separate thread, is NOT separate -- same incident, lesser damage.

Durable finding is a procedure gap: the resize plan was asserted on content and passed a
capacity gate, and none of it covered the inner guests. "In-place" describes the tofu
resource, not the blast radius. Any future in-place change to a containment VM must shut
down its inner guests first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf

dc0 edge root cause: partially-applied OPNsense update, exposed (not caused) by the reboot ...

Console read: the edge sits at a single-user prompt with libcrypto.so.17 and
libpython3.13.so.1.0 missing, 10-configd / 15-templates / 90-carp all failing. The
running system had survived on already-mapped libraries; the 05:49 boot is where it fell
over. Symptom appears nowhere in appendix-A -- a new class.

Scope measured, not assumed: dc0 only. dc1's edge log has zero matches and booted clean
to a login prompt with its WAN addressed. Upstream healthy -- vcloud and voffice1 both
reach the internet, both uplink nets are active NAT, both racks hold default routes.

Recovery material: opnsense-26.7-nano.qcow2 is in the same pool, but the broken disk has
an empty backingStore -- standalone, no CoW base to roll back to.

Logged not conflated: dc1's rack also lacks egress despite a healthy edge; a dc1
forwarding/NAT question, off the deploy path, not diagnosed here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf

Step 3.5 done; BLOCKER: the dc0 edge has been down since the 08-01 05:48 reboot ...

Step 3.5 complete: model vr1-dc0 created (credential vr1-dc0-cred), spaces gate PASS
0 fatal, apt-mirror verified at http://10.12.8.4/ubuntu. Spaces script run from the
07-30 staged copy on the rack, all three files sha256-verified against the repo first.

Blocker found by dc-mirror.sh check dc0 -- the content-assertion fix from 2026-07-27
earning its keep. The rack cannot reach archive.ubuntu.com, streams.canonical.com,
api.snapcraft.io via the snap proxy, 1.1.1.1, or its own default gateway 10.12.4.1.
ip neigh shows 10.12.4.1 FAILED while .5 and .6 on the same segment answer. The edge
VM is running with both NICs attached, qga not connected, qemu log last written at the
reboot. Last successful mirror sync predates it. Step 4 cannot proceed: the deploy
needs the juju agent stream and snap upstream, both dead.

Two gaps exposed: no gate anywhere tests DC egress (dc-rack-net check passes with it
dead), and this session's own post-reboot verification cited five true facts none of
which tested egress -- a listener is not a path, and a 200 from a local service says
nothing about upstream.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf