Recover Shipyard after a power interruption

Recorded outcome — 6 October 2026

Shipyard booted automatically after a controlled removal and restoration of AC power. SSH, Tailscale and Docker were active, with no failed system units. This followed a graceful shutdown; recovery from a sudden live outage and access from outside the home network remain untested.

The owner found Restore after AC Power Loss = Power Off in the MSI B650M BOMBER WIFI BIOS, then saved changes following instructions to select Power On and enable System Power Fault Protection. Linux does not expose these firmware settings on this machine, so the settings are owner-reported; automatic boot is supported by the physical test and SSH checks.

The first off/on attempt did not start the machine. A repeat after instructions to leave AC off for 60 seconds passed. The first off interval was uncertain; a short interval is a possible explanation, not a confirmed cause.

Diagnose another abrupt stop

From the Mac, follow connectivity recovery. If neither SSH nor Tailscale responds, arrange local console/power inspection. Once SSH returns, inspect on Shipyard:

uptime
journalctl --list-boots
journalctl -b -1 -e --no-pager
journalctl -b -1 -k --no-pager
systemctl is-active ssh tailscaled docker
systemctl --failed --no-pager

Preserve a sanitized timeline before changing anything. Check for orderly shutdown, suspend, OOM, thermal, storage or kernel errors and compare with other devices. Missing final logs cannot distinguish mains loss, a PSU fault or a hard freeze. An unclean-journal warning alone does not prove a failed disk.

On 6 October, the previous journal stopped at 08:50:11 UTC; Tailscale’s last-seen time was 08:52:31 UTC. No orderly shutdown or explaining kernel error was found. The last resource sample was lightly loaded, and another device’s record reported a house power loss around 08:55 UTC. Power interruption is the leading explanation, not a proven exact cause.

Repeat the controlled AC-return test

Only schedule this when the owner is physically present and active work is paused. The owner performs the power steps; this recipe is not authorization for an agent to shut down a machine.

1. Save work and stop active tasks cleanly. Record anything needed to restart them.
2. From the Mac, use ssh -t shipyard 'sudo shutdown -h now'; the owner enters the sudo password.
3. After shutdown completes, turn off the wall supply for at least 60 seconds, then restore it without pressing the case power button. The tested machine was connected directly to the wall.
4. Allow two minutes, then verify SSH, uptime, Tailscale, Docker and failed units using the checks above.
5. Reconnect the existing Orca host and restore only the tasks and shared browser that are needed. Test their health separately.

If automatic boot fails, check the saved firmware setting and power path locally. Do not disable fault protection or flash firmware as a guess. MSI describes the power options in its AM5 BIOS guide, page 15.

Remaining limits

The successful repeat was checked at 13:10:30 UTC (18:40:30 IST). Orca still reported reconnection-failed despite working SSH; its reconnection after that test was not verified. The browser viewer was absent after reboot. Host recovery is therefore separate from development-session recovery.

Sleep targets were masked. No runtime watchdog was active and no watchdog device was exposed during inspection. Watchdog/crash-capture changes, UPS planning, abrupt-outage tests and off-LAN access are separate follow-up work, not installed by this runbook.