repo-add takes one package at a time: it hashes the archive and lists its
files, which means decompressing all of it, for about a thousand
packages one after another.
A database is a tar of one directory per package. The packages are dealt
out to one repo-add per CPU, each writing its own database, and the
pieces are joined. On 160 packages on a 16-core machine the result is
identical to one repo-add's, db and files, in 1.0 s against 6.3 s. Two
versions of one package name are an error: one repo-add would keep the
last, the pieces apart would keep both.
pacman 7 sandboxes its downloads with Landlock and fails every database
sync on a kernel without it, which Namespace's AmpereOne arm64 machines
run: "restricting filesystem access failed because Landlock is not
supported by the kernel!". An ISO build there stops at its first
pacman -Sy.
Where /sys/kernel/security/lsm lists no landlock, or cannot be read, a
wrapper in /usr/local/bin runs every pacman in the build container,
pacstrap's included, with --disable-sandbox, the flag pacman provides for
such kernels. Not DisableSandbox in a config: pacman-offline.conf ships
on the ISO.
arch-mact2 dropped apple-bcm-firmware on 2026-09-16 and published
apple-bcm-firmware-fetcher in its place. The new package only conflicts
with the old name instead of replacing it, so pacman cannot follow the
rename and every nightly build has aborted with "target not found"
since 2026-09-17.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CRnZrQDE6jowz4KxmzusL8
Arch dropped the prebuilt broadcom-wl on 2026-09-02 and rebuilt broadcom-wl-dkms with replaces=(broadcom-wl). That only helps upgrades of an installed package; as an explicit pacman -Syw target the old name fails with "target not found", which broke the offline mirror download. Published runtime packages that predate the rename still list it in omarchy-other.packages, so rewrite it at build time until every channel ships a runtime naming broadcom-wl-dkms itself.
The quattro ref is what a bare omarchy-iso-make builds, so pinning it to
omarchy-dev meant every default ISO shipped the dev runtime. Only the edge,
dev, and local-source refs need those recipes now.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The progress screen and the finish screen now center vertically the way the
greeter does, instead of stacking from row one. Both derive their block height
from the logo, so the frame the installer sits on for several minutes is
composed rather than top-aligned. The progress screen redraws itself if the
console resizes, which the framebuffer still does late in VMs.
Centering the finish screen turned up a spacing bug: gum confirm paints
prompt/blank/button from the cursor and clears all three rows, so anchoring one
row below the title left three blank rows under it, not one. Anchoring a row
higher closes that to the two rows gum allows, one more than the greeter's frame.
Swap python-terminaltexteffects for ttfx. The flags carry over, but two things
do not. ttfx resolves even indexed stops to truecolor, so the greeter needs
--xterm-colors to keep its palette indexed: the console reduces 256-colour codes
well and 24-bit ones badly, and the settle colour has to match the logo drawn
underneath with gum style --foreground 2. And ttfx centres its text two columns
right of plain centering, so both screens hand it a canvas two columns narrower
than the console or the logo jumps sideways when the effect starts.
The finish screen uses smoke rather than laseretch, at 60fps rather than 260 —
smoke finishes in under a second at the rate laseretch was tuned for, which
reads as a flicker instead of a send-off. Smoke also survives the console's
16-colour collapse better, carrying its motion in glyphs rather than gradients.
ttfx is in the ISO's package list and timeout is coreutils, so neither needs an
availability check.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The build's missing-form error only ever described the published-package
case, so a --local-source build against a checkout without the form told
you to publish a runtime or pass --local-source — advice you had already
taken. Branch on /omarchy-source and name the checkout instead.
The password comment has claimed yescrypt since 880d8c5 swapped the
command to `openssl passwd -6`, which is SHA-512 crypt. openssl passwd
cannot produce yescrypt at all, so the comment, not the command, is what
was wrong.
Both spotted by Copilot's review on #104.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The keyboard layout list, the account and hostname validation rules, and the
gum prompts that ask for them existed here and again in the runtime's
first-boot owner setup, with nothing keeping the copies honest. They had
already drifted: dropping two layouts from this list moved English (US) from
the top of one gum choose page to the bottom of the previous one, leaving the
preselected default pinned under a screenful of layouts.
The form now lives in the runtime at install/provisioning/setup-form.sh, and
build-iso.sh vendors it out of the very runtime package this ISO bundles —
the same two-branch machinery already used for omarchy-base.packages, so a
--local-source build takes it from the mounted checkout and everything else
extracts it from the downloaded package. An ISO therefore ships the form
belonging to the runtime it installs.
That file is extracted on its own rather than alongside the package lists:
bsdtar exits non-zero for a member it cannot find, so bundling the request
would abort the build under set -e with a bare "Not found in archive" instead
of the actionable error about publishing a runtime that carries the form.
Cancel handling is unified with first-boot setup, which is what made the
prompts shareable. Every prompt reports 0 (answered), 1 (Esc), or 130
(Ctrl+C). Esc now unwinds to the start of the form instead of ending the
install — it previously hit the same `|| abort` as Ctrl+C. Ctrl+C keeps both
of its hidden affordances: arming deferred provisioning on the first keyboard
screen, and toggling unencrypted on the disk screens.
test_keyboard.py reads the layout list from a runtime checkout now, and skips
its localectl coverage rather than failing when there is none to read.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* 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.
Emir Beganovic