Install with archinstall-bash: moving towards systemd as the orchestrator

[hegjon]

This PR is here for early feedback, not for merging yet: it waits on the conclusion of #113 (whose content it carries),

(hegjon:archinstall-bash 1→ quattro, ~95 commits, 107 files, +10,249/−3,893)

This branch replaces Python archinstall with archinstall-bash, a bash port of the archinstall surface the Omarchy installer actually uses, and ports the orchestrator itself to bash. The live ISO ships no Python at all — python, kbd, clonezilla, cloud-init and reflector are gone from the airootfs. The library started as its own repo and is now vendored into this tree with its history (subtree merge): one repo, one reviewable diff, no submodule pointing at a personal remote.

The installer's source code shrinks about fivefold, from 25,564 lines of Python to 4,957 lines of bash. The archinstall 4.4 package alone is 22,827 lines, plus an orchestrator on top; this branch ships the vendored library at 2,291 lines and the orchestrator with its context files at 2,666. Raw line counts, comments included, split out in the table below. Not the same functionality in a fifth of the code: the port covers the surface Omarchy actually calls, instead of carrying every archinstall feature onto every install medium.

It carries #113. The root-image install (btrfs send/receive of a prebuilt system, verified before the disk is formatted) was ported function-for-function into the bash orchestrator and has tracked every #113 review round since, including round 7's test fixes. If #113 merges first, this branch's shared content resolves at merge; the choice between the two is the same #108-vs-#113-vs-this discussion.

What changes beyond #113

• Bash orchestrator (configs/airootfs/usr/share/omarchy-iso/orchestrator/*.sh) driving the vendored library one step at a time; the Python orchestrator and its tests are gone. Port fidelity was validated by comparing an installed system against a Python-archinstall install: limine.conf byte-identical modulo machine-id/hashes/PARTUUIDs, same package set.
• Offline mirror as plain files on the ISO9660 tree (arch/x86_64/mirror/), outside the squashfs, bind-mounted read-only onto the unchanged /var/cache/omarchy/mirror/offline. The mirror is now verified before the installer touches the disk (omarchy-verify-mirror checks every package the medium carries against the repo database's %SHA256SUM% — the same number pacman validates on install — restricted by the build's shipped-package list, since the database deliberately describes packages the root image already provides), which it never was inside the squashfs. ISO size unchanged by the move, byte for byte. The move itself shaved install time — pacstrap reads packages straight off the ISO9660 tree instead of through squashfs decompression — and the whole-mirror verification spent that saving again: net install time is a wash, with the difference converted from speed into a guarantee, the medium proven good before anything is formatted.
• Keyring init as a shipped unit (omarchy-target-keyring.service, RemainAfterExit=yes so unit state alone answers the orchestrator's join; the last systemd-run left the tree) fed by a shared context.env that both systemd units and bash source.
• Pre-flight gate hardening: boot medium checked with mountpoint plus stream existence before formatting, with the actionable copytoram message; RequiresMountsFor= ordering on the verify units.
• Library/orchestrator seams dissolved: ui-helper precedence is a define-if-missing contract instead of source-order luck; installer_setup_swap no longer writes a conf the vendor drop-in outranks; strapping only what the target lacks is the only mode.

This failure class is not hypothetical. omacom/omarchy#7704 (open) is a 4.0.0 install that consistently dies mid-pacstrap on an offline-mirror problem with the disk already formatted, and omacom/omarchy#6985 was a Quattro free-space install — alongside Windows — halting twice in "Configuring system" on missing mirror files, leaving the user to hand-patch scripts inside a chroot. Those two are missing-package bugs (a build-side gap the verification here narrows but cannot fully close); the corrupt-medium half of the class — the bad flash, the dying stick — is exactly what the pre-format verify gates turn from a half-wiped machine into a "re-flash it" message while the old system is still intact.

Where this is heading: systemd as the orchestrator

The endpoint this branch is walking toward is an omarchy-install.target where the install's phases are oneshot units and the ordering lives in After=/Requires= edges instead of a bash loop — the phase runner dissolves into a dependency graph, the pre-format gates become plain unit dependencies, cleanup becomes lifecycle (PartOf=, BindsTo=, ExecStopPost=) rather than trap code, and every phase gets journal logging, timing and a Result for free. A failed phase could even be fixed and resumed, which neither archinstall ever offered.

The first step is in the branch already: omarchy-install.target exists as the umbrella — phase units and the keyring init declare PartOf= it, so stopping the target is a cgroup-complete group abort — and the root-image unpack is the first migrated phase: omarchy-install-image.service hosts the existing phase function in its own process via a small run-phase entrypoint, receives its context through layered EnvironmentFile= (defaults, this run's resolved values, and the raw configurator inputs the context code now persists), and is bounded by a build-time timeout drop-in sized to the stream, like the verify units. The orchestrator's loop starts the unit where it used to call the function; a oneshot's blocking start is the join. Phases migrate one at a time behind that pattern, each dragging its ordering into the target as it moves.

Measured (KVM rig, identical VM shape, all KVM cells re-measured 2026-08-29 in one sitting; X200 = real-hardware A/B from #113)

	quattro (pacstrap)	#113 (Python + image)	this branch
ISO size	5.74 GiB	6.76 GiB	6.30 GiB²
Install, KVM (full VM lifetime)	86 s	66 s	77 s³
Install phase, X200 USB	496 s	159 s (warm)¹	241 s (cold)¹
Installed boot (systemd-analyze)	10.61 s	10.98 s	10.99 s
Packages installed	940	940	942
Installer source aboard	25,564 lines Python	26,066 lines Python	4,957 lines bash

² The root image stream now ships behind an outer whole-stream zstd pass (level 15, 128 MiB long-range window): the per-extent compression inside the send stream cannot reach its framing or cross-extent redundancy, and the one pass reclaims 11% of the stream — 398 MiB of ISO. The layer landed on #113's branch after its column was measured; the same delta applies there.

³ Two opposing moves inside this number, both measured on the same rig the same day. The zstd layer made the medium read smaller: the installer VM's kernel clock at power-down went from 21.0 s to 18.4 s when the layer landed. The phases moving into their own systemd units (13 oneshot units, each a fresh process that reloads the library and rebuilds context) added ~5 s over the in-process loop — visible only on KVM, where the whole install is seconds; on the X200 the same overhead vanishes inside a read-bound install a hundred times longer. A shared context daemon or thinner per-phase reload could claw it back if it ever matters.

¹ The two image legs differ in cache state, not in orchestrator: the #113 run pressed install while the boot-time hash was still reading the stream, so the receive ran page-cache-warm; this branch's run began 46 minutes after boot with a cold cache, reading at the stick's raw ~16 MB/s — still 2.1× over pacstrap. Total wall for the run: 538 s / 323 s / 289 s. The pre-format verify gates cost 0.17 s on this run — the hashing hid entirely inside the time the user spent in the wizard.

The +0.56 GiB over quattro is the root-image stream's intrinsic cost (zstd:15 extents pass through btrfs receive untouched — no decompress/recompress, which is what buys the 3× install phase on slow hardware), already shaved by the outer stream pass; ~71 MB comes back from dropping Python. Installed-system boot is unchanged across all three; more than half of it is the loader delay common to every variant.

Verification

• ./test/all: 16 shell suites + the vendored library's own config tests, green.
• Integration (QEMU, per scenario run): unattended base install, corrupt-image, slow-medium, firmware-boot, pxe (netboot → NBD → install) — green on built ISOs at multiple points along the branch; the mirror-file layout was additionally proven with the payload manifest verified off the medium.
• Interactive installs driven by hand at several heads, including the medium-eject flow at the finish screen.

🤖 Generated with Claude Code

[hegjon]

The install graph now fans out. After the provisioning phase, two branches run concurrently — the Limine phase (the UKI build, the longest tail phase) beside a user branch (user → login → ssh → tailscale → dns) — joining at validate-boot. ssh and tailscale stay ordered within their branch because both drive ufw; hibernation, system and provisioning keep their edges into Limine because they feed the initramfs.

Measured on the X200: the two branches open in the same second, the full user branch (~16 s) completes inside Limine's ~23 s window, and the join fires the moment Limine latches — the tail now costs what Limine alone costs, where the serial graph spent ~39 s.

The groundwork that made the flip itself a four-line unit edit:

• Every chroot in a private mount namespace. arch-chroot mounts /proc, /dev and /sys under the target and tears them down on exit, so two concurrent chroots would unmount each other's API filesystems. A function shadowing the command name runs every invocation under unshare --mount --propagation private.
• No parallel state document. The phase units latch (RemainAfterExit=yes), so systemd's own records are the install's state: the dashboard builds its roster by topologically sorting the Requires= edges in the unit files and polls one systemctl show per frame. state.json and the phase-error files are gone entirely.
• Failure stories keyed per unit, race-free. A failing phase hands its own words to the journal under a dedicated identifier, each line prefixed with the unit name. Two measured journalctl lessons along the way: -u and -t don't compose (the -u expansion is a +-joined disjunction), and cgroup-based _SYSTEMD_UNIT attribution loses the race against the failing unit's teardown — hence identifier plus in-message prefix.
• Progress by weights, not bands. Each phase owns a share of the bar; latched units contribute their full weight, running units their credit (time asymptote or work signal). On the linear graph this reproduces the old band walk position for position (pinned in a playback test); on the fan, concurrent phases push the bar together.
• The installed-in time is the installer's own span: -----BEGIN/END OMARCHY INSTALL----- journal sentinels from the configurator handover to after the timing record, not the UI's lifetime.

Validated: the unit suite (23 tests), the QEMU scenario set (install, corrupt-image, slow-medium, stalled-medium, firmware-boot), repeated unattended X200 hardware installs driven by the new omarchy-iso-remote autoinstall, and interactive installs both on hardware (encrypted) and in QEMU. Boot-to-verdict on the X200 is ~4½ minutes.

I will continue cleaning this up and making it more systemd idiomatic, and I want to explore whether more of the units can run in parallel.

[hegjon]

The install graph as it stands, generated from the unit files by the new bin/omarchy-systemd-graph (so the picture cannot drift from what systemd walks — one command refreshes it after any edge change):

%% omarchy install graph at 3ac59e9 -- generated by bin/omarchy-systemd-graph
flowchart LR
  classDef phase fill:#e3eee6,stroke:#2f7d4f,color:#20242a,font-family:monospace;
  classDef aux fill:#eceff3,stroke:#8b94a1,color:#20242a,font-family:monospace,stroke-dasharray:4 3;
  classDef boot fill:#fdf3e3,stroke:#a8722c,color:#20242a,font-family:monospace;

  subgraph boot["boot-started (WantedBy=multi-user.target)"]
    cpu_boost["omarchy-install-<br/>cpu-boost<br/>.service"]:::boot
    omarchy_mirror_verify["omarchy-<br/>mirror-verify<br/>.service"]:::boot
    omarchy_pacman_sync["omarchy-<br/>pacman-sync<br/>.service"]:::boot
    omarchy_prefetch["omarchy-<br/>prefetch<br/>.service"]:::boot
    omarchy_root_image_verify["omarchy-<br/>root-image-verify<br/>.service"]:::boot
  end
  omarchy_mirror_verify -. After= .-> omarchy_pacman_sync
  omarchy_mirror_verify -. After= .-> omarchy_prefetch
  omarchy_pacman_sync -. After= .-> omarchy_prefetch
  omarchy_root_image_verify -. After= .-> omarchy_prefetch
  omarchy_mirror_verify -. After= .-> omarchy_root_image_verify
  omarchy_pacman_sync -. After= .-> omarchy_root_image_verify

  prepare_live["omarchy-install-<br/>prepare-live<br/>.service"]:::phase
  prepare_target["omarchy-install-<br/>prepare-target<br/>.service"]:::phase
  disk["omarchy-install-<br/>disk<br/>.service"]:::phase
  image["omarchy-install-<br/>image<br/>.service"]:::phase
  strap["omarchy-install-<br/>strap<br/>.service"]:::phase
  base["omarchy-install-<br/>base<br/>.service"]:::phase
  hibernation["omarchy-install-<br/>hibernation<br/>.service"]:::phase
  system["omarchy-install-<br/>system<br/>.service"]:::phase
  provisioning["omarchy-install-<br/>provisioning<br/>.service"]:::phase
  user["omarchy-install-<br/>user<br/>.service"]:::phase
  limine["omarchy-install-<br/>limine<br/>.service"]:::phase
  login["omarchy-install-<br/>login<br/>.service"]:::phase
  ssh["omarchy-install-<br/>ssh<br/>.service"]:::phase
  tailscale["omarchy-install-<br/>tailscale<br/>.service"]:::phase
  dns["omarchy-install-<br/>dns<br/>.service"]:::phase
  validate_boot["omarchy-install-<br/>validate-boot<br/>.service"]:::phase
  factory_snapshot["omarchy-install-<br/>factory-snapshot<br/>.service"]:::phase

  omarchy_mirror_verify -. "latched verdict read in-process" .-> prepare_target
  omarchy_root_image_verify -. "latched verdict read in-process" .-> prepare_target

  prepare_live --> prepare_target
  prepare_target --> disk
  disk --> image
  image --> strap
  mnt_mnt_var_cache_pacman_pkg["/mnt/var/cache/pacman/pkg"]:::aux
  mnt_mnt_var_cache_pacman_pkg -. RequiresMountsFor .-> strap
  strap --> base
  base --> hibernation
  hibernation --> system
  system --> provisioning
  provisioning --> user
  provisioning --> limine
  user --> login
  login --> ssh
  ssh --> tailscale
  tailscale --> dns
  dns --> validate_boot
  limine --> validate_boot
  validate_boot --> factory_snapshot
  omarchy_target_keyring["omarchy-<br/>target-keyring<br/>.service"]:::aux
  omarchy_target_keyring -. "After= only" .-> factory_snapshot

Loading

Reading it: solid arrows are Requires=+After= pairs — a failure cancels everything downstream. The amber cluster is boot-started; the three verifies hash the medium one reader at a time and the pre-flight gate reads their latched verdicts in-process (no unit edge, hence the labeled arrows). Dashed arrows are ordering-only — the keyring can still be initializing when the snapshot phase starts, but never fails the install. Dotted RequiresMountsFor= is the strap's package-cache mount, released with plain umount(8) in the base phase because a systemctl stop inside the running transaction would cancel the chain.

[hegjon]

Fixed #147 in commit aaf64ec