* 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>
The loader now settles udev before probing, so a fast boot cannot miss
the drive and silently drop a headless install into the wizard. All the
files come over in a single cp, and a failed copy removes anything it
already copied and falls back to the wizard: the wizard cleans up only
what it writes itself, so a half-copied ssh.json would otherwise leak
into the interactive install that follows. The command takes an optional
path prefix so tests can run it against a sandbox instead of the live
system.
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 install reads ~3GB out of the offline mirror, and pacman consumes it at
only ~33MB/s (3.14GB of packages across the 95s the package phase is calibrated
at), so on any medium slower than that the install is read-bound. The ISO medium
is idle for the minutes the wizard takes, and the target disk written to later
is a different device, so reading ahead costs nothing that is otherwise in use.
Warms largest-first under a MemAvailable/2 budget. Deliberately no dependency
resolution: asking pacman exactly which files the install will read would copy
the package-set knowledge in phases_impl.py — the early list, the runtime
target, the kernel from the wizard's JSON — into a shell script that would drift
silently. The install reads roughly 69% of the mirror, so warming blindly is
close enough for a cache hint.
The page cache this fills is clean and reclaimable, so the failure mode under
memory pressure is wasted bandwidth rather than OOM. The budget stops small
machines evicting what was just warmed. The job ends when that budget is spent
rather than when the wizard exits, because the partitioning and format window
afterwards is also free medium time.
OMARCHY_NO_PREFETCH=1 turns it off so a single ISO can measure both arms against
the Installing Arch + Omarchy entry in /var/log/omarchy-install-timing.json.
Not yet measured on real USB media, and expected to be worth nothing in the VM
harness, where the ISO is backed by the host's page cache.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Restore the env + redirect setup that the previously-working ISO
installer used (matching /home/ryan/Downloads/ISO scripts/.automated_script.sh):
export COLUMNS=$(tput cols)
export LINES=$(tput lines)
exec > >(tee >(sed CSI-strip >> log) 2>/dev/null) 2>/dev/tty
export CLICOLOR_FORCE=1
export FORCE_COLOR=1
The cutover commit (064b5e2) silently dropped these. Subsequent
attempts to fix the TTY/gum rendering by reshaping the redirect were
all symptom-chasing — the proven shape was correct. The key insight:
- gum draws its TUI on stderr, not stdout. 2>/dev/tty keeps that
rendering on the real terminal.
- stdout-as-pipe (via tee) is *desired*: it lets gum detect a
non-TTY stdout and skip cursor-position probes (CSI 6n). Without
that detection, the DSR replies leak as visible ^[[13;1R bytes.
- CLICOLOR_FORCE/FORCE_COLOR force gum to still emit colour despite
stdout being a pipe.
Also drops the configurator's _drain_tty workaround — unnecessary
once gum stops sending DSR queries in the first place.
bash's `read -t 0` only TESTS whether input is available; it does not
consume the bytes. So the drain loop `while read -t 0 ...; do :; done`
spun forever the moment any bytes were pending (e.g., the DSR reply
sitting in the tty input buffer after gum style sent CSI 6n).
That hung the configurator at the first step() title screen — blank
prompt, blinking cursor, no keyboard form.
Use `read -t 0.05 -N 9999` once, which consumes up to 9999 bytes with
a 50ms timeout. Always returns after 50ms whether there's data or not.
Single call replaces the while loop.
Fix the ^[[13;1R cursor-position-report artifacts visible next to the
first configurator step. archiso's boot init leaves DSR responses in the
kernel tty input buffer; the first gum invocation reads them as stray
input and echoes them as visible escape sequences.
- Drain stdin (with a short timeout) from /dev/tty before configurator
runs so any pending replies are consumed.
- Drop the explicit </dev/tty stdin redirect — the parent script's
stdin is already tty1 (inherited from archiso autostart), and the
explicit redirect opened a new fd with subtly different termios.
All install-phase logic now lives in the Python orchestrator and the
omarchy-iso-* bash helpers. .automated_script.sh becomes a thin shim that:
- sources install helpers (env for configurator)
- sets the Tokyo Night palette on the live VT
- tees stripped stdout/stderr to /var/log/omarchy-install.log
- runs the configurator wizard
- exec's omarchy-iso-install with absolute config paths
Absolute paths are required because the wrapper cd's into
/usr/share/omarchy-iso before invoking the orchestrator.
Removed install_base_system, install_omarchy, install_arch, install_disk,
cleanup_install_disk, configure_login_for_unencrypted_install, and
chroot_run_as_user — all replaced by Python phases or bash helpers.
The live ISO runs as root with XDG_RUNTIME_DIR=/run/user/0; arch-chroot
-u ryan switches the UID but doesn't reset the env, so tools running as
ryan tried to write to root's runtime dir (dconf failed to commit,
omarchy-theme-set's flock target hit Permission denied). Drop the var
so tools fall back to no-runtime-dir behaviour, which works inside the
chroot.
Two motivations:
1. Plymouth: the omarchy plymouth theme + /etc/plymouth/plymouthd.conf
ship from omarchy-settings (theme at /usr/share/plymouth/themes/omarchy,
plymouthd.conf via the package's post_install etc-overrides hook).
Without omarchy-settings on the live ISO, mkarchiso builds the initrd
with plymouth pointing at the default theme instead of Omarchy's. Now
it picks up the Omarchy theme on boot like the installed system does.
2. Drops the .pkg.tar.zst extraction hack in .automated_script.sh:
OMARCHY_PATH=/usr/share/omarchy is the real package install path, so
use_omarchy_helpers no longer needs to bsdtar pieces out of the
offline mirror into /tmp/omarchy-iso.
archinstall creates the user from user_credentials.json BEFORE installing
the 'additional packages' list, so when omarchy-settings populates
/etc/skel/.config/... later in the pacstrap, the user's home has already
been created from an empty skel and missed the seed (user boots into a
terminal with no Hyprland configs).
Copy /etc/skel into /home/$OMARCHY_USER after archinstall finishes (by
which point omarchy-settings has populated skel) and chown to the user.
cp -rT keeps it idempotent: existing files get overwritten, dirs merge.
omarchy's hard depends are now just the bricking set, not the full default
install. After archinstall pacstraps the meta packages (which populates
/etc/skel before user creation), install the rest of omarchy-base.packages
in the chroot before running omarchy-install.
archinstall creates the user AFTER pacstrap. If omarchy-settings (which
ships /etc/skel/.config/**) isn't pacstrap'd, the user is created with
an empty skel and never gets the Omarchy default configs in their HOME.
Add omarchy-installer to the configurator's archinstall package list
(its depends pull omarchy + omarchy-settings + omarchy-limine), so all
the package files are in place before the user is created.
install_omarchy no longer needs the explicit 'pacman -S omarchy-installer'
step; it just runs 'omarchy-install' which is already at /usr/bin/.
presentation.sh reads $OMARCHY_PATH/logo.txt to compute LOGO_WIDTH and
LOGO_HEIGHT, which then drive max_line_width in logging.sh / errors.sh.
We were only extracting omarchy-installer into /tmp/, so logo.txt was
missing, LOGO_WIDTH=0, max_line_width=-4, and bash's substring expression
errored with 'substring expression < 0'.
Extract from omarchy-settings into the same /tmp tree so all the
presentation/logging helpers find what they expect. Renamed the dir
from omarchy-installer-iso to plain omarchy-iso since it now blends
content from two packages.
The ISO no longer carries a cp -r'd copy of the omarchy git checkout
into /root/omarchy and the target /home/$user/.local/share/omarchy.
Instead it builds omarchy-installer + omarchy-settings + omarchy +
omarchy-limine from mounted source trees (${OMARCHY_INSTALLER_PATH:-
../omarchy-installer} and ${OMARCHY_PKGS_PATH:-../omarchy-pkgs}),
drops them in the offline mirror, and pacstraps omarchy-installer
during the target install — which deps-in the other three.
- builder/build-omarchy-packages.sh: new. Builds the four packages
inside the ISO build container using each PKGBUILD's OMARCHY_SRC
override (introduced in Chunk 2). Creates a 'builder' user because
makepkg refuses to run as root. Drops the resulting .pkg.tar.zst
files into the offline-mirror directory.
- builder/build-iso.sh: drop the git clone / -v omarchy mount path;
call build-omarchy-packages.sh first; filter out the locally-built
package names from the rest-of-mirror download so we don't try to
fetch them from the network mirror.
- configs/airootfs/root/.automated_script.sh: replace the install_omarchy
cp-and-source dance with 'arch-chroot pacman -S omarchy-installer'
followed by 'OMARCHY_INSTALL_MODE=offline omarchy-install'. Drop the
big chown/chmod block that was setting up the cloned tree.
use_omarchy_helpers extracts the installer's helpers/ tree directly
from the offline-mirror's omarchy-installer-*.pkg.tar.zst so the live
ISO has access to gum-styled logging before pacstrap.
- bin/omarchy-iso-make: always mount omarchy-installer and omarchy-pkgs
(paths configurable via OMARCHY_INSTALLER_PATH / OMARCHY_PKGS_PATH;
default to ../omarchy-installer and ../omarchy-pkgs). --local-source
is now a back-compat no-op.
* Configurator tester
* Make it a dry run
* Offer a no-encryption install mode
* Fix SDDM login
* Simplify the flow by using ctrl-c to toggle into unencrypted mode
