Skip to content

Finn BIOS Trip + Power-Loss Drill, Handoff for Vector

URL: https://mkdocs.justinsforge.com/memory/handoffs/finn-bios-trip-2026-04-30/

Audience: Justin running this from Vector (Windows PC) with a Claude Code session in remote-control. The forge resilience stack is fully shipped on Console — every reboot test passed in the dress rehearsal. This trip closes the loop with the BIOS settings that make the auto-recovery actually fire on real power loss.

What you're doing

Two physical BIOS changes on Finn (the MS-01) that can't be done from software because the BMC LAN isn't configured yet:

  1. Set "State After G3" to S0 (auto-power-on after AC loss). This is the whole reason for the trip.
  2. Configure BMC LAN so future BIOS changes can be done remotely.

Then run stage 6: pull the Tapo plug to validate the BIOS policy actually fires.

Pre-flight (do this on Console BEFORE you walk to Finn)

  1. Save active sessions so they auto-resume after the reboot: 

    bash /home/justinwieb/forge/scripts/forge_pre_reboot_save.sh
    Should print Saved N session(s).

  2. Confirm fleet probe is 18/18 green as a clean baseline: 

    /home/justinwieb/forge/scripts/forge_fleet_probe.sh

  3. Tell whichever Claude session you're in that you're going dark so it doesn't try to start anything mid-flight.

At the box: Enter BIOS

  1. Plug a USB keyboard + monitor into Finn (or use the IPMI/BMC port if you have a way to access it pre-config).
  2. Power cycle: tap Delete (or F2) repeatedly during POST until InsydeH2O BIOS comes up.
  3. The screens below are based on MS-01 firmware 1.27. Layout may shift slightly between firmware revs — search by setting name if a path is off.

BIOS settings to change

1. State After G3 (the critical one)

Path Setting Change to
Advanced → Power & Performance (or Chipset → PCH-IO Configuration on some firmwares) State After G3 (sometimes "AC Power Loss" or "Restore AC Power Loss") S0 (always power on)

Don't pick "Last State" — if Finn was powered off when AC dies, it stays off. S0 means "always come back on, regardless of prior state."

2. Quality-of-life settings, while you're here

Path Setting Change to Why
Boot menu Quiet Boot Disabled If POST hangs in the future, you see the error instead of a black screen.
Advanced → POST behavior Halt on Errors / "Wait for F1" Disabled / "no halt" Some firmwares stop boot for a missing keyboard or fan-speed warning. Brutal failure mode for a headless box.
Boot menu → Boot order NVMe first, PXE/Network boot disabled (already likely set) Saves 5-30s of boot delay; PXE timeout is a common silent boot delay culprit.
Wake Wake on LAN Enabled Belt + suspenders once BMC LAN is up.
DO NOT CHANGE SecureBoot leave as-is Flipping mid-reboot can soft-brick PVE boot.

3. BMC LAN configure

Path Setting Set to
Server Mgmt → BMC Network Configuration IP Source Static
IP Address 192.168.86.68
Subnet Mask 255.255.255.0
Gateway 192.168.86.1
Configure Mode (or "BMC LAN Selection") Dedicated (use the dedicated BMC NIC, not the OS-shared one)
Server Mgmt → BMC User Settings Set admin password (default is often admin/admin) use NordPass-generated password, save it under "Finn BMC" entry

Plug an Ethernet cable into the dedicated BMC NIC (separate physical port from the regular NICs).

4. Save and exit

F10 → Save Changes and Reset.

Finn boots up. Forge resilience stack handles the rest: - All 6 prod CTs auto-start in tier order (adguard → plex/media → immich/frigate → n8n + Console) - Console boots, fires forge-boot-notify → you get a Telegram ping with kernel + uptime + fleet probe - forge-post-boot-sessions spawns recap + blank Opus sessions on the homebase tmux socket, with up to 2 additional sessions resumed from ~/.forge-last-session

Verify before walking back to your desk

  1. Check Telegram for the boot-notify message from @forge_notify_outbound_bot. Should show "Fleet probe: 18/18 green" within ~6 minutes of the BIOS save.
  2. Test BMC LAN from Console via Tailscale: 
    ssh finn 'ipmitool -H 192.168.86.68 -U admin -P <password> chassis status'
    Should report "System Power: on" without errors.

Stage 6: The real test, pull the Tapo plug

  1. Open the Tapo app. Find the Finn smart plug.
  2. Pull the Tapo plug, OR toggle "Off" in the app, OR just unplug Finn from the wall.
  3. Wait 30 seconds.
  4. Power back on (re-toggle Tapo or replug).
  5. Watch:
  6. Telegram boot-notify should fire within ~6-7 min.
  7. Run forge_fleet_probe.sh from any Claude session, expect 18/18.
  8. Verify recap session in claude.ai/code shows the conversation history.

If boot-notify never fires after 10 min, the BIOS setting didn't take. Try option 5 fallback below.

If something goes wrong

Symptom Likely cause Fix
Finn doesn't boot after BIOS save "State After G3" still set wrong, OR the BMC LAN config conflicted Press power button manually. Re-enter BIOS, double-check S0.
Boot notify never arrives Console not booting, OR network issue SSH to finn from Console, check pct status 103 (Console VM). If running, SSH to Console (Tailscale 100.97.43.104).
Fleet probe shows reds after stage 6 One CT slow to start, OR one service genuinely broken Wait 5 min, retry. If still red, pct status <id> on the failing CT.
Resume session is wrong/missing ~/.forge-last-session was stale (>6h old) Use /resume skill to find specific session by UUID/URL/fuzzy.

How Vector should reach Claude Code for this trip

If you're using Vector during the trip, you have two ways to keep a Claude session live:

  1. claude.ai/code from Vector's browser — find session finn-reboot-resume_Opus47 (or whatever the active drill session is named) and resume. Full conversation history present.
  2. Spawn a fresh Vector-side Opus session — via remote-control tab in claude.ai/code, then point it at this handoff: tell it "read forge/memory/handoffs/finn-bios-trip-2026-04-30.md and walk me through it."

The post-boot recap session will already have a full state report waiting after the BIOS reboot — useful as a sanity check before stage 6.

What's still pending (not blocking this trip)

  • UPS + NUT integration: real fix for actual wall power loss + forensic clarity next time. Different day.
  • forge_fleet_update.sh orchestrator for apt + docker compose updates across the fleet, with kernel-bump triggering the same drill flow. Build after stage 6 passes.
  • forge-tmux-anchor Type=forking + tmux-resurrect (B7 from the recovery handoff).

References

[Claude Code]