← Pharos Data Ark

PHAROS DATA ARK · 2026-10-29-01024f5b59

Handbook contents

Clean-OS software bootstrap acceptance

This test complements paired-media recovery and the empty-media drill. It asks whether the stock coordinator can obtain and configure its declared base software on a clean OS, without borrowing an existing Ark's virtual environment or installed services.

Separate claims

The generic VM test is useful evidence for the first claim. It cannot establish the second by skipping the radio phase.

Test construction

The disposable guest is separate from the read-only development emulator. The verified Debian cloud image remains an unchanged backing image; a new 64 GiB system overlay and a new 16 GiB content disk hold all writes. SSH and web forwarding bind only to desktop loopback (22223, 18090 and 18091). The guest has its own SSH key and newly generated caretaker credential. Production networking, Home Assistant credentials and community data are not imported.

Cloud-init creates the required admin account at UID 1000 and the explicit /etc/dataark-clean-bootstrap-test marker. It does not install Ark packages. The public recovery kit supplies source, readable configuration and the documented PMTiles executable; no Python virtual environment is copied.

The blank guest content disk is explicitly identified before formatting, mounted and owned by admin. The kit is copied onto it. That preparation is a test-fixture step; the recovery installer itself does not format drives.

Phase harness

deploy/emulator/run_clean_bootstrap_test.py refuses an unmarked, unrecognized or non-root execution environment. It loads the actual coordinator from the kit, validates the site, checks preflight and runs the real Installer.phase methods for packages, source, storage, Python, base services, public distribution, content-policy and finish checks.

The test-site copy explicitly sets require_raspberry_pi_os to false for generic Debian. It does not create a fake Pi OS marker or pretend that a virtual Ethernet interface is a Wi-Fi radio. The hardware-specific network phase is omitted and recorded as untested. The harness does not exercise the top-level physical installer's local-console/INSTALL interaction; those protections remain in place.

A guest-only generated password is supplied privately to the existing credential installer. The transient password-input file is removed when the harness exits. No production authorization is reused.

Evidence and checks

Retain the coordinator journal, phase result, package log and source revision. Verify fresh package/venv installation, declared service status, dashboard/API/documentation responses, management authentication and the absence of optional downloads. Reboot the guest and verify service/mount persistence after software phases succeed. Record failures as failures; resuming after a fix does not erase the first-run failure.

Guest evidence locations:

The host-side test files belong to the dedicated clean-bootstrap workspace chosen when preparing the test VM. Physical acceptance remains governed by Recovery validation; this test never makes the recovery branch eligible to merge on its own.

Initial fix-and-retry result — 29 October 2026

Passed after corrections and phase retries, within the generic ARM64 software scope. This was a clean OS at the start, not a copied Ark installation. The first run was not a pass: the test exposed real bootstrap defects. Reviewed fixes were applied to the disposable guest and the affected phases resumed, with the original failed journals/logs retained.

Corrections now included in source:

Verified dashboard, API, locally hosted API documentation, handbook, library-management page, community page and empty reader: HTTP 200. Caretaker authentication accepted the generated credential; unauthenticated unlock returned 401. Data Ark, Apache, Docker, Samba and Avahi were active. Optional map/archive download timers remained disabled.

Public-file checks passed over HTTP, anonymous FTP and actual SMB. FTP and SMB write attempts were denied; the HTTP private path returned 403 and FTP refused the private directory. The content filesystem and base services returned after a guest reboot. A second reboot after public-distribution setup also passed: the ext4 content mount, API, web pages, empty reader, caretaker authentication, HTTP/FTP checks and actual SMB read all returned successfully. The boot ID changed on both reboots.

43 relevant regression tests passed for stock setup, content profiles, queue behavior and public content access. Tests use disk-backed temporary storage so the real 10 GiB reserve is not defeated by a RAM-backed /tmp. New checks cover AP/helper ordering, idempotent read-only fresh-share creation and publicly readable generated files.

Interpretation

This demonstrates the coordinator's real base-software phases installing from package/registry sources on a clean generic ARM64 OS, after correcting the defects found in this run. That initial run was not a zero-intervention replay. A subsequent frozen-kit replay has now passed in one installer invocation on another clean VM, with no manual installer corrections or phase retries. The test harness invoked the real phase methods while explicitly omitting the physical network phase and the top-level local-console interaction. Source overlays and reviewed configuration/journal corrections were part of debugging and remain recorded.

It does not certify stock Raspberry Pi OS, AP/radio/portal behavior, USB power, physical media swaps, the full optional software/tool inventory, complete content restoration or dependable paired-media recovery. Those remain separate acceptance work. No merge or fully verified Pi-appliance claim is authorized by this result.

Uninterrupted replay completed

The corrected frozen kit passed all eight software phases, 43 regressions, public/authenticated service checks and reboot persistence on another clean generic ARM64 VM. See the complete replay report. Physical Pi/network and spare-media acceptance remain pending.