* Configure target keyboard without temporary boot
* Slim the offline keyboard configuration to what Omarchy consumes
Drop the Xorg 00-keyboard.conf writer: the installed system only reads
the XKB* settings in vconsole.conf (via detect-keyboard-layout.sh, which
copies XKBLAYOUT/XKBVARIANT into Hyprland's kb_layout), and nothing on
an Omarchy system reads xorg.conf.d. systemd-firstboot already writes
those vconsole settings.
Drop the set_keyboard_language monkey-patch: passing an empty kb_layout
to minimal_installation takes archinstall's documented skip path (no
nspawn boot), and the keymap is configured offline right after instead.
Append the preserved FONT= line instead of reproducing localectl's exact
file layout, and slim the tests to the behavior that matters: XKB
settings present, font preserved, every configurator keymap valid, and
archinstall-compatible invalid/empty handling.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The Limine registration helper rebuilds the UEFI BootOrder from the
pre-state read, but passes every entry through verbatim. Some firmware
(listed in the BootOrder but with no matching BootXXXX variable) causes
efibootmgr --bootorder to fail with exit status 8, aborting the whole
install at the bootloader step.
Only carry forward entries that still exist as boot variables.
archiso boots on whatever governor the kernel defaults to, which on most
laptops ramps conservatively. Package extraction and the UKI build are both
CPU-bound, so pin performance for the whole install and put it back afterwards.
Reduced from #87 by @davydotcom, which also disabled every non-POLL cpuidle
state. That half is left out deliberately: C1 wake latency is 1us on current
hardware, and disabling it leaves POLL as the only idle state, so idle cores
busy-spin instead of halting. Package extraction is single-threaded, so on an
8-core laptop that is 7 cores burning power for no work — on a thermally
limited machine that costs the working core its turbo headroom, which is a
plausible way to make the install slower. #87 measured the two tweaks together
with a page-cache prefetch and an updatedb deferral, so the C-state
contribution was never isolated.
Scoped to the whole install rather than just the pacstrap window, which #87
used: finalize_limine_boot runs mkinitcpio and compresses a UKI, and is the
most purely CPU-bound phase there is.
Restoring only matters when an install fails and the user keeps using the live
environment; a successful one reboots out of it.
Co-authored-by: David Estes <davydotcom@gmail.com>
Co-authored-by: Claude Opus 5 (1M context) <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 dashboard owns the visible UI: it captures the orchestrator's stdout into
the support log and strips CSI sequences on the way in, so the colouring was
never seen by anyone. gum charged a Go process start per line for it, on every
phase and every package group. Plain writes keep the same indented shape.
Flushing stays: pacstrap and arch-chroot inherit this fd, so buffering would
reorder our lines against theirs in the log.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The existing hook mask only covers pacstrap. pacman.conf(5) HookDir is
absolute, so it never applied to the pacman runs inside arch-chroot, and during
omarchy-setup-system the target's own hooks are live. limine-entry-tool's
90-mkinitcpio-install.hook triggers on usr/lib/firmware/*, usr/src/*/dkms.conf
and usr/lib/modules/*/pkgbase, and collect_pkgbase_files sets rebuild_all for
any trigger outside usr/lib/modules — so it rebuilds the initramfs and UKI for
every installed kernel. The hardware scripts hit that routinely: sof-firmware
on Intel audio, nvidia-open-dkms, linux-ptl on Panther Lake, linux-t2 on Macs.
Every one of those builds is discarded. finalize_limine_boot runs limine-update
immediately after, which pipes "rebuild" into the same script and rebuilds
unconditionally. They are stale as well as redundant: hardware/nvidia.sh writes
its mkinitcpio drop-in after installing the driver.
Mask that one hook inside the target for the duration of the phase. The
kernel-removal hooks stay live — they only prune Limine entries, which is what
ptl-kernel.sh's "pacman -Rdd linux" needs.
A mask that survived would be invisible until a later kernel update shipped a
UKI-less boot, so it is restored in a finally, again in main()'s finally, and
validate_boot repairs and then insists the real hook is back before reboot.
limine-mkinitcpio-hook is a hard dependency of the Omarchy runtime package, so
that file is always on disk before the mask goes up.
Worth several seconds per avoided build on real hardware. It is invisible in
the VM harness, which installs no hardware packages, so measure it on an Intel
laptop rather than in CI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
omarchy-settings now ships the tuning as a vendor drop-in that outranks the
main config file, so setup_swap's /etc copy decides nothing and is removed only
to keep /etc free for the local admin.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LjeyQZsNBxqyYy9z8KaKm7
Hardware packages like omarchy-hw-intel-ptl swap the kernel mid-install,
so the UKI lands under a name the configurator never asked for and boot
validation halted a perfectly good install. Read the kernels back off
/usr/lib/modules/*/pkgbase instead of trusting the requested name.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
archinstall's FilesystemHandler.perform_filesystem_operations defaults to
show_countdown=True, which runs a ~4.5s "5...4...3...2...1" warning
(_final_warning) before wiping the disk. That prompt is meant for
archinstall's interactive TUI; in our orchestrated/dashboard install it
renders nowhere and just sleeps silently on every full-disk install.
Pass show_countdown=False, guarded by an introspection check so it stays
safe on newer archinstall releases that dropped both the countdown and the
parameter. Generalize _method_accepts_users into _method_accepts for the
check.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
archinstall's setup_swap writes /etc/systemd/zram-generator.conf directly
into the target, but omarchy-settings now ships that file as a packaged
config. pacstrap then aborts the transaction on a file conflict
("zram-generator.conf exists in filesystem"), failing the install.
Delete archinstall's copy after setup_swap so omarchy-settings' packaged
config lands cleanly. We still keep the zram-generator package and service
that setup_swap installs.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fresh installs on real hardware failed pacstrap with "keyring is not
writable" and "required key missing from keyring". The offline repo's
SigLevel = Optional TrustAll was not the bypass it appeared to be:
Optional verifies whenever a .sig file exists — and every package in the
offline mirror ships one — while pacstrap's pacman -r relocates the
install root but not GpgDir, so verification runs against the LIVE
keyring. That silently made every install depend on archiso's boot-time
pacman-init.service having finished: fast in QEMU, minutes-or-never on
real hardware, where pacstrap then raced it and lost.
The mirror ships inside the ISO, whose integrity is already covered by
the airootfs sha512 and the ISO signature, so pacman-level signature
verification adds nothing. Set SigLevel = Never so installs never touch
the live keyring. The target still gets its own keyring via pacstrap -K
plus the archlinux-keyring/omarchy-keyring package hooks.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
prepare_live waited on archiso's pacman-init.service, stalling real-hardware
installs at 5% for minutes: the boot-time keyring init (gpg key generation
plus populating every keyring) is slow when reading from USB, and as a
Type=oneshot unit with no start timeout it can block systemctl start
indefinitely.
Nothing in the install consults the live keyring. The offline repo is
SigLevel = Optional TrustAll and archinstall bootstraps with pacstrap -K,
which gives the target its own independently initialized keyring. Drop the
wait and let pacman-init finish in the background for anyone using the live
environment interactively.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Full-disk installs flaked with "Partition(s) 1, 2 on /dev/vda have been
written, but we have been unable to inform the kernel of the change":
archinstall's disk wipe and parted's own partition registrations fire
udev probes, and when one is still holding the disk mid-commit, the
BLKPG sync fails and the install halts. The table is written correctly
when this happens — only the kernel's view is stale — so settle udev
before partitioning and redo the filesystem operations (wipe, partition,
format) when parted throws exactly this error. Recoveries are logged so
they show up in the support log.
Reproduced headlessly by booting the ISO on a serial console and driving
the real installer: stock failed 1 in 5 full-disk cycles at this exact
phase, with an audit watch confirming nothing else writes the disk. With
the fix, 13 of 13 cycles got cleanly through partitioning.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The install dashboard shelled out to a full Python interpreter to read
four keys from the installer state JSON — including inside the render
loop, twice a second. jq is already on the ISO and does the same job
with plain bash arithmetic for the phase-weight interpolation.
Co-Authored-By: Claude Fable 5 <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.
Pairs with omarchy-installer's rename of bin/omarchy-setup-user to
bin/omarchy-finalize-user. The orchestrator now invokes
omarchy-finalize-user --force --first-install in the run_chroot_finalizer
phase, and the phase-ordering docstring is updated to match.
