Alpha.8 firstboot/config path can disappear when state readiness fails

[Deadbytes101]

Physical symptom

The current rigos-usb-amd64-0.0.4-alpha.8.img can boot without presenting a configuration flow. Mining remains stopped because no persistent configuration is committed or activated.

Root cause found in source

rigos-firstboot.service contains:

Requires=rigos-state-ready.service

The firstboot program itself contains a state_not_ready UI path, but systemd prevents the program from running when rigos-state-ready.service fails. This creates a silent dead end:

state readiness fails
-> firstboot never owns tty1
-> no diagnostic or manual configuration screen
-> miner gate remains closed

The unit also waits for network-online.target, although firstboot configuration and diagnostics must be available offline.

Exact-image verification gap

The image verifier checks that the firstboot service and script exist and contain selected strings, but it does not currently assert:

• the service is enabled in multi-user.target.wants
• firstboot does not hard-require successful state readiness
• firstboot does not depend on network-online
• tty1 is forcefully acquired for the setup flow
• a failed state-ready path still reaches the firstboot diagnostic UI

Required fix

• change state-ready from a hard requirement to ordering/wanted dependency
• remove network-online from the firstboot launch path
• ensure firstboot owns tty1 before getty
• retain fail-closed mining when persistent state is unavailable
• add source and exact-image contracts for the boot path
• rebuild as a new image; do not overwrite or relabel alpha.8

Acceptance

• blank/unprovisioned USB state shows manual configuration selection
• unavailable/failed state shows an explicit blocked diagnostic instead of silently skipping firstboot
• miner stays stopped until a committed configuration activates successfully
• exact image verifier proves the service is enabled and the dependency contract is correct
• physical boot test confirms the setup screen appears on tty1

[Deadbytes101]

Fix implementation opened as stacked draft PR #21

Branch:

fix/alpha9-firstboot-config

Exact current head:

ea6463349e6685834a5c981ef63a56b2c47f534a

Implemented:

• removed Requires=rigos-state-ready.service from firstboot
• added Wants=rigos-state-ready.service
• retained ordering after state, state-ready, and profile-apply attempts
• removed network-online.target from the local setup path
• changed firstboot input to StandardInput=tty-force on /dev/tty1
• retained fail-closed miner/config behavior when state is unavailable
• extended Rust source tests for the failed-state console path
• updated systemd ordering verification so the old hard dependency is rejected
• added scripts/verify-firstboot-image.sh
• exact-image gate verifies service enablement, tty ownership, offline availability, state-failure reachability, manual configuration path, whiptail runtime, theme wrapper, and theme drop-in
• image build entrypoint now runs the firstboot source test and exact-image verifier
• advanced artifact version to 0.0.4-alpha.9, build ordinal 9

No PASS is claimed yet. Required next gates:

1. exact-head WSL source verification
2. exact alpha.9 image build
3. exact-image verification
4. physical clean first boot showing manual configuration on tty1
5. physical failed-state boot showing an explicit diagnostic rather than silently skipping firstboot
6. configuration commit and miner activation test

[Deadbytes101]

Alpha.9 exact-head source gate closed

The fix branch passed the full WSL source authority at:

79e769b4b9fe367e918611dd9096a5396d4c42d4

Final markers:

RIGOS verification passed
RIGOS firstboot theme wrapper verification passed
RIGOS_WSL_SOURCE_GATE=PASS

The failed-state firstboot reachability contract, tty1 ownership contract, offline setup contract, image-gate source contract, runtime publication authority, systemd ordering, miner observer/stability, MSR authority, recovery, and release build all passed.

The previous source-gate failure was caused by a fresh WSL environment missing jq, not by the alpha.9 firstboot implementation. The preflight now checks jq explicitly and fails early with a missing-tool diagnostic.

Remaining issue acceptance work:

1. build rigos-usb-amd64-0.0.4-alpha.9.img
2. pass all exact-image verifiers, including verify-firstboot-image.sh
3. physical clean boot must show the setup UI on tty1
4. failed-state physical boot must show an explicit diagnostic
5. commit a new configuration and verify automatic miner activation
6. reboot and verify configuration persistence and miner recovery

Issue remains open until those image and physical gates pass.

[Deadbytes101]

Alpha.9 exact image authority is now complete for the firstboot recovery fix.

HEAD=79e769b4b9fe367e918611dd9096a5396d4c42d4
IMAGE=rigos-usb-amd64-0.0.4-alpha.9.img
SHA256=be5926ea427691ffe7113632ffaed64530876d5e0a0cfaa46387e3a820a56f7f
SOURCE_GATE=PASS
USB_APPLIANCE_IMAGE_GATE=PASS
RANDOMX_IMAGE_GATE=PASS
AUTHENTICATED_OBSERVER_IMAGE_GATE=PASS
FIRSTBOOT_EXACT_IMAGE_GATE=PASS
FLASH_AUTHORITY=PASS
PHYSICAL_FIRSTBOOT=PENDING

The issue remains open until a clean physical boot proves that tty1 presents setup, manual configuration commits successfully, the miner starts, and configuration/miner state survive reboot.