* 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>
install_progress() mapped each phase to a start%, an end% and a hard-coded
"expected seconds", then interpolated on elapsed time. Those seconds were
calibrated on one machine, so the bar was only ever honest on that machine.
Measured against a real 69s install on an XPS 13, the table expected 145s: 95s
for a phase that took 58.6s, 10s for one that took 2.6s. On slow media it is
wrong the other way — the bar reaches each phase's ceiling in a fraction of the
real time and then sits there. Today's clamp turns that into a 386-second freeze
at 85% on a USB2 install.
Phases do not even scale together: package installation is bound by media read
and disk write, the UKI rebuild is CPU and compression bound. No single seconds
table can be right for both.
So stop predicting durations. Position is now max(floor, work), both
non-decreasing:
floor an asymptote over the phase's band, on time since this process first
saw the phase. tau is a shape constant, not a prediction — wrong by 3x
it changes the pace of a crawl, never the correctness.
work only for "Installing Arch + Omarchy", which is ~85% of the install.
libalpm creates one directory per package under
<target>/var/lib/pacman/local, so counting them counts finished work.
The denominator is resolved at ISO build time by pacman's own resolver
against the offline mirror, so there is no second package list to
drift. phases.py records expected and actual in the timing JSON on
every install, so drift shows up in acceptance runs.
There is deliberately no give-up predicate: two discontinuous curves selected by
a toggle, behind a monotonic clamp, is a freeze generator. If the signal never
appears — no denominator, wrong target, implausible count — the floor alone
still walks the band to its end.
Position moves to per-mille. That is load-bearing, not precision theatre: these
are asymptotes, and in whole percent an asymptote over a 2-point band has two
reachable values and stops moving within seconds.
Time now comes from /proc/uptime. The live ISO runs tzupdate and
systemd-timesyncd, and the old code read EPOCHSECONDS, so a clock step
mid-install jumped every band straight to its ceiling.
Also fixes drift the old table had accumulated: it still weighted five phases
that no longer exist and had no entry at all for "Preparing install target",
which fell through to a 1->99 sweep. Unknown names now derive an even band from
the index the orchestrator already publishes.
bin/omarchy-iso-installer fakes a pacman database so the preview exercises the
package path instead of the fallback; PREVIEW_PACKAGES tunes the count.
Verified by simulation against the real logic: a 69s NVMe install, a 6-minute
USB2 install with a 70s pre-extraction stall, an implausible denominator, an
unknown phase name, and a target that already holds packages. All monotonic, all
reach 100%. Not yet run on real hardware.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The live ISO boots one kernel for every machine, and after the preceding commit
that kernel is linux-t2. Stock linux is then a second kernel nobody boots, plus
its own archiso initramfs, copied into both the ISO tree and the
size-constrained FAT EFI image — about 147MB.
It could not simply be deleted: releng's broadcom-wl hard-depends on linux and
is the only releng package that does, so pacman would pull the kernel back in.
broadcom-wl is a prebuilt module for stock linux and cannot load on linux-t2.
It has kept working until now only because of the bug the preceding commit
fixes — the ISO has been booting stock all along — so it is booting T2 that
takes it away, not this commit. Dropping the package only stops shipping
something that can no longer load. Nothing in the offline install needs Wi-Fi
in the live environment.
Both packages stay in the offline mirror and this changes nothing about
installed systems: linux comes from builder/archinstall.packages and remains
what configurator's detect_kernel picks for every machine that is not a T2 Mac,
and broadcom-wl comes from omarchy-other.packages, so install/hardware/
fix-bcm43xx.sh can still install it offline on BCM4360/BCM4331 MacBooks.
The removal is anchored so linux-t2, linux-firmware, linux-firmware-marvell and
linux-atm are untouched; verified against releng's real list.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pairs with omarchy-pkgs' fold of omarchy-limine into omarchy-settings.
Changes:
- EARLY_BOOTSTRAP_PACKAGES in phases_impl.py drops omarchy-limine.
The limine configs it shipped (mkinitcpio hooks, entry-tool drop-ins,
snapper template, default/limine/, default/snapper/) now come with
omarchy-settings, which is already in the early bootstrap.
- builder/build-iso.sh's offline-mirror seed list and post-mirror filter
no longer reference omarchy-limine.
- builder/build-omarchy-packages.sh's build queue drops omarchy-limine.
- Test manifests (fresh-4.json, fresh-4-semantic.json) no longer expect
omarchy-limine in the installed-packages list. The /etc/pacman.d/hooks/
99-omarchy-limine.hook entry stays — that hook file is generated by the
orchestrator regardless, and the filename is descriptive, not tied to
the package name.
repo-add --new skips updating entries that are already in the db, so when
the omarchy-* packages are rebuilt in place (new content, same filename,
because pkgver is constant) the persistent cache's offline.db.tar.gz
kept the OLD size/checksum entries. Pacman then read the stale db size
and rejected the new file with 'Exceeded the maximum allowed file size'.
Delete the db files and let repo-add regenerate them fresh — slower but
deterministic, and 'offline.db.tar.gz' is small to rebuild even for the
full ~600 package set.
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.
We're not installing the deps in the build container — just producing
.pkg.tar.zst files that pacman will resolve against the offline mirror
on the target. Installing limine-mkinitcpio-hook into the build
container also fires its pacman hook that errors about a missing ESP.
makepkg in build-omarchy-packages.sh installs runtime build deps via
pacman, which uses the container's /etc/pacman.conf. That config only
had core/extra/multilib by default, so deps that live in the omarchy
repo (limine-snapper-sync, limine-mkinitcpio-hook) failed to resolve.
Append the [omarchy] block from the channel-specific online config to
/etc/pacman.conf right after omarchy-keyring is installed.
makepkg runs as the builder user and needs to write PKGDEST. /tmp/omarchy-pkg-build
is created by root, so without an explicit chown the build aborts with
'You do not have write permission for the directory $PKGDEST'.
Also includes the build-iso.sh cleanup that I prepared earlier but
forgot to stage (replacing the inline ugly $(...) conditional pipe
with a normal if/then-fi block).
The previous version made the local build the only path. Convention is
the opposite: omarchy-iso-make pulls released omarchy* packages from
the omacom-pkgs.org mirror by default, and only builds from local
checkouts when explicitly asked via --local-source.
- bin/omarchy-iso-make: only mount /omarchy-installer + /omarchy-pkgs
when --local-source is set. Default has neither mount.
- builder/build-iso.sh: skip build-omarchy-packages.sh when no local
source. Don't filter the omarchy* names out of the pacman -Syw list
in network mode (so they get downloaded from the mirror). With
--local-source, the four package names are stripped after assembly
so we don't re-fetch what we just built.
- For the package-list source: with /omarchy-installer mounted, read
omarchy-base.packages from the checkout. Without it, briefly pull
the published omarchy package, extract the .packages files from it
to /tmp, and use those.
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.
