It existed to render two fields that live in master.conf's HOST IDENTITIES group, which the shared renderer now includes — one settings surface for the page rather than two both editing the same file.
master.conf says unRAID-Jayred36 and the tailnet device is unraid-jayred365, so the exact-key lookup found nothing and every remote card rendered with no IP, no online state and no containers.
Windows with runs but no bytes say 'no data moved' rather than 0.00 GB, and rows before the byte-parser fix are excluded rather than summed into a false total.
Step 12 filed all thirteen deployed containers under <Owner>-Fallback, which says whose they are and nothing about what they do — and they are not failover coverage, they run there continuously.
The API answered and simply had no vms node, but that was recorded as an API fallback, and the monitor reads any fallback with a key present as 'Unraid API unreachable — check API key in host conf.'
The wizard had a Skip beside Create API Key and a second link that renamed itself Go to Scheduler/Partnership, so leaving early and finishing looked like the same action.
It was a browser flag set on click, and refreshing is the first thing anyone does when a page looks stuck — which put them back on the phase-1 panel the state exists to replace.
The mirror's own job ends in seconds while Phase 2 runs for minutes on the owner, so the screen sat unchanged on the phase-1 panel — which reads as a hang, and the reasonable response to a hang is to start clicking.
Step 1b ran the owner's SCRIPTS_ROOT path over SSH on the mirror, so it failed on every appdata install; the wizard poll expired at 5 minutes against a Phase 2 that takes over 4.
The lookup grepped for a quoted container name that appears in no Unraid template, so every offboard reported four WebUIs it could not reconfigure. The final sync counted a share synced whenever Tier 1 was on, ignoring rsync.sh's status entirely.
The .plg hardcoded the flash path and runs every boot, so an appdata node served a stale copy that never receives pulls — fixes appeared to do nothing, indefinitely.
With nothing blocking but optional keys unfilled the banner rendered an empty string, so a finished onboard showed a blank panel beside a Join button still greyed at Running.
The phase-2 branch of the mirror panel returned the same Join partnership / Onboard block as the not-started state, so a finished onboard read as one that never ran.
The guard tested Tier 1 only, so onboard Step 1d's posture — Tier 1 open, every Tier 2 closed — made a healthy partner climb toward auto-offboard every 30 minutes. The counter holds intervals, not days, and was rendered raw.
HOST<n>_PHASE*_DONE only ever describe the mirror, so on the mirror the owner's card computed phase 0 and offered to onboard the host that had just onboarded it.
Onboard now ends at Phase 2: connected, running, and saying so. Phase 3 sets the seeding gate posture and dispatches the seed. With MEDIA_SEED_ENABLED false there is no Phase 3 and the model is two phases.
A first seed is ~28 TB behind a 12.5 MB/s bwlimit, and it ran inline as Step 9d, so the
phase-2 flag every status reader depends on was written only after it finished.
Phase 1 exists to hand the partner its identity before the install, but the push refused any
host without varaverk.cfg — so the conf could only ever reach a node that no longer needed it
to be told who it was. It now resolves the remote's conf directory across both install layouts
and creates the internal one when neither exists.
Gmer4Lfe