Drive the OEM first-boot keyboard picker to English (UK) and assert the
installed system ends up with KEYMAP=uk and XKBLAYOUT=gb — proving the
deferred keyboard step actually applied a layout, not just rendered. UK keeps
every letter identical to US so the raw-keycode password still matches, and
the email's '@' (Shift+' under UK, not Shift+2) is typed with the UK keycode.
The console bootstrap now fetches-then-runs instead of piping, so it survives
the non-US layout the keyboard step installs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The wizard now opens on disk selection; keyboard moves to after the install
mode is chosen and stays before the user step (so the LUKS passphrase is
still typed under the chosen layout). OEM installs skip keyboard and user
entirely — the machine's owner picks both at first boot — so the emitted
config just carries a default 'us' keymap as a placeholder.
The QEMU harness drives the new order and the OEM first-boot keyboard step.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codex xhigh round 2:
- Strip account authentication fields (!users, !root-password,
root_enc_password, auth_config account entries) from the archinstall config
in OEM mode, not just user_credentials — a combined/legacy config could
otherwise have archinstall create a provisioning account before OOBE.
- Clear stale OEM inputs (oem marker, credentials, optional files) from /root
before copying a cidata drive, so a retried install in the same live session
can't force a fresh drive back into OEM mode or reuse an old LUKS passphrase.
- The test harness waits for the OEM pending flag to clear before saving the
base image, so it never snapshots a half-finalized first boot; it also
handles the deliberately skipped mode picker on blank disks built against a
pre-OEM runtime.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Review findings from codex and Copilot:
- A rig-supplied credentials file in OEM mode now contributes only its LUKS
passphrase: preserved users/root_enc_password fields would have created a
hidden provisioning account despite OEM promising no user until first boot.
- The factory snapshot is taken writable, scrubbed of deployment credentials
(staged authorized_keys, tailscale auth key and join unit, the dead OEM
LUKS key and its initramfs drop-ins), then set read-only — a reset years
later must not authorize the original deployment key or rejoin its tailnet.
- The missing-Node-tarball case is a hard install error on every install,
not just OEM: the stash is what lets a factory reset finalize offline.
- The configurator's OEM gate checks the runtime package for the service
unit as well as the setup binary.
- The test harness handles the deliberately skipped mode picker on blank
disks when the bundled runtime lacks OEM support.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Node tarball in /var/lib/omarchy/oem/packages is read by
omarchy-finalize-user running as the freshly created user; a 0700 directory
forced the offline install onto its network fallback. The only secret inside
(luks-key) is itself 0600 root.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A loaded agent offers its keys before the harness identity and can exhaust
the server's MaxAuthTries before the right key is ever tried; IdentitiesOnly
pins authentication to the per-run key.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The configurator now peeks into the offline mirror's runtime package for
omarchy-oem-setup before offering the OEM install mode, so an ISO built
against a pre-OEM runtime can't start an install doomed to fail at the
staging phase (which still hard-checks as the backstop). Blank disks with no
OEM choice to offer skip the mode picker entirely, like the pre-OEM flow.
Also keep the test harness QMP socket in /tmp — unix socket paths cap at
~108 bytes, which nested test-run directories can exceed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
OEM mode installs the entire system but defers user creation to first boot,
where the runtime's omarchy-oem-setup asks for the owner and lands them in the
already-installed system — and the same machinery arms omarchy-reset-computer.
The configurator's install-mode step gains an OEM choice, which required
moving the user step after mode selection (OEM skips it entirely). Autoinstall
rigs select OEM with an `oem` marker file on the cidata drive, which also
replaces the user_credentials.json requirement.
In the orchestrator, OEM swaps the user phases for a stage_oem_state phase:
it stashes the bundled Node tarball (every install, for offline factory
resets), arms omarchy-oem-setup.service in the target, and on encrypted
installs stages the throwaway LUKS passphrase — generated by InstallContext
when the input carries none — with a keyfile embedded in the UKI so boot
auto-unlocks until first-boot setup re-keys to the owner's password. The
install fails with a clear error if the bundled runtime lacks OEM support.
Every install now also ends with a read-only @factory snapshot of @ at the
btrfs top level — outside snapper's reach — which is what makes
omarchy-reset-computer a true factory reset.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Offer the same gum chooser over release/*.iso when no ISO is passed,
and fail plainly when there is no existing ISO to test.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Installs an ISO into a headless QEMU VM by driving the real interactive
install flow: each screen is read via QMP screendumps + OCR and answered
with virtual keystrokes, so the configurator wizard, install dashboard,
reboot prompt, and SDDM login are exercised exactly as a user would.
SSH access is bootstrapped by logging into a console TTY, the installed
disk is snapshotted for fast reruns, and a throwaway overlay then runs
the omarchy repo's in-guest acceptance suite over SSH.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
