The wait loop printed "installing (Ns)" until SSH answered on the
installed system. A nightly run sat on that line for twelve minutes
while the install had finished after two: the first boot was what hung.
The firmware names what it starts on the serial port, so the loop now
notices the installed disk's Limine starting, logs how long the install
took, and counts the first boot from there.
Next to edge, the nightly now makes a VM image of the last release. The
latest release of omacom/omarchy names the version, iso.omarchy.org has
the ISO, and it is used only if its signature is the release key's, the
one in builder/omarchy.gpg. It gets the same install test, seal and
checks, and is published under stable/ with its own latest.json, whose
url is the ISO's existing place: the ISO is not uploaded again.
A release is done once. A plan job decides what a run makes: edge
always, stable unless a scheduled run finds that version already in
stable/latest.json. Build and publish run once per channel, and one
channel failing does not hold back the other.
The install test's key sits in the user's home, which is its own
subvolume and not part of the factory snapshot, and the seal removes it
there. The check says so of every image, instead of leaving it to the
layout staying as it is.
The seal read /boot/EFI/Linux/omarchy_linux-omarchy.efi. An edge install
has linux-omarchy-bore, so the first nightly run stopped there. It now
asks the running system which kernel package it booted and takes that
UKI, and takes the command line from /proc/cmdline, since the boot
entry, not the UKI, may be what holds it. The nightly's package report
names the kernel the same way.
linux-t2, the kernel every x86 live ISO boots, comes from arch-mact2,
which has two servers in these configs: the maintainer's host in Seoul
and their GitHub release. Both carry the same database. An ISO build on a
runner in Virginia waited on the Seoul host at 0.45 MB/s for a 92 MB
package; the same file from GitHub came at 58 MB/s.
GitHub goes first, which is also the order of arch-mact2's own mirror
list. The Seoul host stays as the fallback.
A nightly downloads the packages of the ISO's offline mirror, a few
gigabytes, and the test container's own, and would download most of them
again the next night. On Namespace both directories live on the runner
profile's cache volume. The build already prunes from its cache what an
ISO no longer needs. The step is skipped, not failed, on a runner
without a cache volume.
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.
GitHub's hosted runner has 4 cores. The build job moves to
namespace-profile-linux-amd64-16x32; the publish job, which only copies
files and holds the bucket's key, stays where it is.
Those runners' kernel has no Landlock, so pacman 7 fails its first sync
in a container there. The ISO build already steps around that; the
install test's container does the same now. The job also prints what it
is running on: CPU, memory, LSMs and /dev/kvm.
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.
The nightly built the stable ISO and kept it as an artifact for a day.
It now builds the edge ISO, runs the install test on it, seals the
installed disk that test leaves behind into a VM image, checks the
image, and publishes ISO and image under a version that is never reused:
nightly.omarchy.org/edge/latest.json
nightly.omarchy.org/edge/<version>/omarchy-edge-<version>.iso
nightly.omarchy.org/edge/<version>/vm/
latest.json gives the version, the ISO's URL and checksum, the
omarchy-iso commit, the Omarchy version and commit inside, and where the
image is. It is written last, after every file has been fetched back
through the CDN and compared.
Publishing is a second job, the only one with the bucket's key, and only
on quattro. There is no pull_request trigger. A manual run on a branch
builds and checks everything and publishes nothing.
test/integration already installs the ISO unattended and saves the
installed disk as test-runs/<iso>-integration/base.qcow2, with its
firmware variables and the key that logs in to it. That folder is what
vm-seal takes, so the separate install script goes.
The sealed image now also carries the firmware variables, which hold the
boot entry the installer registered: a consumer that boots the disk
through UEFI needs them, a direct kernel boot does not.
builder/build-iso.sh puts omarchy-dev and omarchy-settings-dev on an edge
ISO, as it does on a dev or local one. The harness picked its package
names from the ISO's file name and knew dev, local and pr, so for an edge
ISO it asked the installer for the release packages.
As they were tested by hand on the 4.0.4 ISO, before any of it is wired
into a workflow:
vm-install unattended install of an ISO into a qcow2, through cidata
vm-seal makes the disk publishable: SSH takes keys only, no machine
ID, host keys, build key or build logs left, compressed
with zstd, with checksums and the kernel pulled out for
direct boot
vm-verify boots the sealed image once and checks all of that
vm-boot boots a throwaway copy with a key made for that boot and
runs a command in it
On this machine: install 114 s, seal 27 s, a 4.2 GB image, SSH about 5 s
after power-on, 17 of 17 verify checks, and 7 of them failing on an
image sealed without these fixes.
* Carry the installer input-method choice into the target
* Support Archinstall 4.5 sanity checks
* Constrain VM keyboard choices to supported credential layouts
* Cover VM keyboard offsets and reject absent choices
./test/all runs the cidata and orchestrator tests under test/unit/ in a couple of seconds, with no ISO. It runs in an Arch container, where the code it covers runs: the container boots systemd for the tests that ask localectl for its keymaps, and the tests run as an ordinary user. The install test keeps covering everything that needs a VM.
The harness runs as root in its container, so test-runs and the serial
logs QEMU writes there belong to root. The runner's user could then
neither record the pull request number beside them nor read
install-serial.log into the artifact (EACCES at zip time), which failed
the job after a passing install and boot. A chown -R step after the
container step, run even on failure, fixes both. The install loop now
prints a line every 30 s and still screenshots every 2 min.
Review fixes for the comment workflow. Artifacts are downloaded by name
for the exact attempt that finished, and for the baseline run's latest
attempt, since a rerun keeps earlier attempts' artifacts under the same
run. Every lookup prints nothing instead of failing, so no quattro
baseline yet, an expired one, or a missing boot file shows as "–"
rather than ending the script under set -e before any comment. The
install test's own marker step takes ownership of test-runs first,
which the harness created as root inside its container.
The harness now runs in archlinux:latest with /dev/kvm passed through,
so CI uses Arch's current QEMU and OVMF (QEMU 11.1, edk2 202608) at the
paths the harness expects, the same as an Omarchy workstation, instead
of Ubuntu 24.04's QEMU 8.2 with symlinks and shims. Arch splits QEMU's
devices into modules: virtio-vga needs both qemu-hw-display-virtio-gpu
and qemu-hw-display-virtio-vga, and QEMU 11.1 segfaults on
-device virtio-vga when only the latter is installed.
wait_for_ssh counted only its sleeps toward the timeout. Under QEMU user
networking each attempt can also spend its whole ConnectTimeout waiting
for a banner, so a "300 s" wait ran for ten minutes or more without a
line of output. It now uses a wall-clock deadline, polls every 2 s, and
prints a progress line with a console screenshot every 30 s. When the
boot scenario times out it prints the serial console's last lines too.
Review fixes. The first-boot systemd-analyze now waits (bounded) for
startup to finish, since SSH can answer first and systemd-analyze
refuses until it has. In the boot scenario, a non-zero exit from
is-system-running (as for "degraded") no longer ends the script under
set -e before the diagnostics are saved, and a failed query for failed
units writes a marker instead of an empty file that read as "none".
A second workflow, triggered when the install test completes, posts one
comment on the pull request and updates it on every run: install, first
boot and everyday boot next to quattro's latest numbers, with the change,
and the install phases in a collapsed table. Pushes to quattro now run
the install test too, so there is always a baseline.
It runs from quattro's copy with write access, which works for pull
requests from forks, so it never checks out or runs pull request code.
It reads only the finished run's artifact, trusts the pull request
number in it only when that pull request's head is the commit the run
tested, and keeps phase names to plain text.
Builds the ISO a pull request produces, installs it unattended in a KVM
guest on a GitHub-hosted runner, boots the installed system again, and
writes the install time per phase plus first-boot and everyday-boot
systemd-analyze to the job summary. Every later installer change is
measured against these numbers in its own PR.
Locally against the 2026-10-04 quattro ISO: install 51.3 s (42.9 s of
it pacstrap), first boot 12.1 s, everyday boot 11.7 s with ~6 s in the
loader, systemd running, no failed units.
A disk check replaces a cleanup step: the runner has ~86 GB free, so
the 2-minute "Free Disk Space" action the nightly uses is not needed.
Boots the installed system a second time, records the time to SSH and
systemd-analyze, and asserts systemd reaches running with no failed
units. It gives CI a scenario that passes on today's installer and a
number for every change that touches boot.
After an unattended install the harness now copies the installer's
timing file and log off the installed system, with systemd-analyze from
its first boot, next to the base image, so CI can report them without
attaching the disk. OMARCHY_INTEGRATION_DISK_CACHE sets the target
disk's QEMU cache mode; cache=none keeps the host page cache out of the
guest's writes, so install times measure the installer rather than the
host.
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 acceptance harness waits for the installer greeter by looking for
"Opinionated", which the tagline no longer contains: it now reads "Beautiful,
Fun & Agentic Linux by DHH". Every scenario the harness drives fails at the
first screen with
Timed out after 300s waiting for screen: Opinionated
five minutes into a run that never gets further.
Matching "Linux by DHH" instead. That is the half of the tagline naming the
product rather than describing it, it is common to the old wording and the new,
and OCR reads it cleanly off the greeter. A tagline is marketing copy and will
be rewritten again; the product name is what the test actually means.
Graceful guest poweroff over SSH first, escalating to TERM then KILL;
--kill skips straight to force. Finds the newest live run by its pidfile
and confirms before acting when run from a terminal, since a harness
still driving the VM dies with it.
A VNC viewer that resizes the guest framebuffer makes the console font
unreadable to OCR, which stranded the bootstrap at its login-prompt gate.
Getty is reliably on the spare TTY and SSH coming up is the real success
signal, so type the login blind and retry the whole sequence up to three
times; a failed pass just leaves getty re-prompting.
Also print the resize-safe viewer invocation whenever a VM starts: a
resize during early boot can wedge virtio-gpu before the system is up.
--rc appended a bare -rc suffix regardless of the version passed, so
every candidate of a train uploaded over the same omarchy-X.Y.Z-rc.iso
and nobody could tell rc1 from rc2 by name or URL. A version that
already numbers its candidate (4.0.2rc2) is the complete artifact name;
the suffix remains for unnumbered candidate builds.
--sync-omarchy now pushes all of test/ (the security coverage lives in
shell.d as well as acceptance.d), and the acceptance run gets
OMARCHY_ACCEPTANCE_SUDO_PASSWORD so the suite's opt-in sshd hardening
exercise can run against the throwaway VM.
--sync-all additionally runs the CLI and shell suites inside the guest
from the synced tree. The acceptance suite always runs against
/usr/share/omarchy either way: VM runs verify the finished product, and
qs matches shell instances by config path, so pointing the suite at the
synced tree just reads the session shell as "not running".
Omarchy now binds Super+Space to the Omarchy menu and Super+Alt+Space to
the apps menu, and the omarchy.launcher plugin is gone (the apps menu
replaced it). The smoke table still expected the old launcher binding, so
both chords failed against current builds. Both surfaces open under the
omarchy-menu layer namespace.
Tesseract cannot read the highlighted "Yes, install without encryption"
button under any preprocessing, so waiting for that text always timed out
and killed unencrypted installs at the disk warning. Capture the screen and
continue instead; a Ctrl+C toggle that failed to apply still surfaces when
the unexpectedly encrypted install stalls at the LUKS prompt on first boot.
The artifacts a release exists to hand out — the download URL and the
checksum to verify it with — were buried in rclone transfer noise or
absent entirely. Print them together as the final output, after the
upload has actually succeeded (set -e means reaching this line is the
success path).
Emir Beganovic