* Join the tailnet from a cidata tailscale_authkey
A tailscale_authkey file on the autoinstall drive gets the installed
machine onto the tailnet on its own: the tailscale package is bundled in
the offline mirror and installed only when the key is present, the key is
staged root-only at /etc/tailscale/authkey, and a oneshot first-boot unit
runs tailscale up once the network is really there. On success the key is
deleted and the unit disables itself; on failure both survive to retry on
the next boot, so an offline install joins whenever it first gets
connectivity. ufw allows traffic in on tailscale0 via the same
write-the-rule-then-ignore-the-chroot-exit-code dance as the SSH phase.
Bundling rather than fetching at first boot is deliberate: pacman -Sy
tailscale on a fresh machine is a partial upgrade, and pacman -Syu means
an unattended full system upgrade racing the user's first login. The
offline mirror is a coherent snapshot; installing from it keeps the
target consistent and the install offline-capable. See plans/tailscale.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xc74h4WSYpuYPGuYbFAR1q
* Do not hold boot hostage for the tailnet join
Review caught that the join unit was Type=oneshot wanted by
multi-user.target: target units implicitly gain After= for their Wants=,
so an offline machine's boot -- SDDM included -- stalled for the full
10-minute timeout, and once timed out the join never retried within that
boot. Type=simple counts as started the moment it forks, so boot proceeds
while the join retries in the background for as long as the boot lasts.
Cleanup moves inside the script, sequenced after tailscale up succeeds,
which preserves the retry-across-boots behavior: key and unit survive a
boot with no connectivity, and the key never outlives a successful join.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xc74h4WSYpuYPGuYbFAR1q
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The JSON wrapper was the one piece of autoinstall input that wasn't an
existing format: the other files are the configurator's own output, and
the keys end up in sshd's authorized_keys anyway. So take that file
directly -- one key per line, comments and key options work as they do
everywhere else -- and drop the parsing in between. The only thing JSON
bought was parse-error detection, and the phase still fails loudly when
the file carries no usable keys.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Look for a drive labeled cidata at startup. If it carries the
configurator's own output files, copy them into /root and skip the
wizard -- everything downstream then runs the ordinary path against
ordinary inputs. No drive, no change.
The required pair matches what the orchestrator treats as mandatory, so
a drive with less than that falls back to the wizard rather than failing
the boot.
Claude-Session: https://claude.ai/code/session_01Sy3HeoBqb13ahLuaiP2UkM
The orchestrator drives an offline install on the live ISO using
archinstall as a library subsystem. Lands under configs/airootfs/ so
mkarchiso bakes it into the live squashfs directly:
/usr/share/omarchy-iso/orchestrator/ (the Python package)
/usr/local/bin/omarchy-iso-install (thin shell wrapper that
execs python -m orchestrator.main)
Two corrections vs the previous omarchy-installer location:
1. omarchy-installer dropped from EARLY_PACKAGES \u2014 it's live-ISO-only
install tooling, must never land on the target. /etc/skel is still
populated pre-useradd via omarchy-settings.
2. run_chroot_finalizer now copies /usr/share/omarchy from the live
ISO into /mnt/tmp/omarchy-install/ before arch-chroot. finalize.sh
+ install/ scripts run from /tmp inside the chroot; /tmp is wiped
on first reboot, so the target boots with zero install detritus.
