Confirm the Start Omarchy Now prompt after provisioning setup - #100
Merged
Conversation
First-boot account setup now ends on a celebration screen whose Start Omarchy Now button gates the SDDM handoff, so the provisioning test must press it — same as the installer's Reboot Now prompt — once the pending flag clears. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Open the ISO configurator with the same greeter the deferred-provisioning first boot uses — vertically centered logo, the Omarchy tagline, and a single button — so install and first boot bookend setup identically. The installer's button reads "Start install"; first boot's reads "Start setup". Co-Authored-By: Claude <noreply@anthropic.com>
Match the first-boot greeter: a looping tte ColorShift over the centered logo with a "Press Return to Start Install" hint instead of a button. Return begins the install at any time. Co-Authored-By: Claude <noreply@anthropic.com>
Match the first-boot greeter: sweep the logo ColorShift through the Tokyo Night accent colors instead of tte's default rainbow. Co-Authored-By: Claude <noreply@anthropic.com>
Mirror the first-boot greeter fixes: indexed ANSI colors (green base with a cyan accent) because the framebuffer console can't render tte truecolor; one long tte invocation so the loop never flashes; stty sane + clear after Return so the keyboard step starts clean. Co-Authored-By: Claude <noreply@anthropic.com>
The installer and first-boot flows now open with a greeter (animated logo + tagline). Wait for the tagline and press Return before the keyboard step, in both drive paths, so the harness gets past the greeter. Co-Authored-By: Claude <noreply@anthropic.com>
Run tte directly instead of inside a backgrounded `while` subshell, so killing the tracked PID actually stops the effect. Killing the subshell orphaned tte, which kept painting the logo over the keyboard step. Co-Authored-By: Claude <noreply@anthropic.com>
Harmless today (no set -e), but keeps the greeter's animation teardown robust if that changes. Co-Authored-By: Claude <noreply@anthropic.com>
wait_for_stable_terminal skipped terminal emulators on the assumption they're already at final size, but a fresh terminal (or sudo's pty) reports a stale 24x80 for a moment at startup too. Drop the VT-only gate so the greeter centers there as well. Co-Authored-By: Claude <noreply@anthropic.com>
Match the deferred-provisioning first-boot flow changes: the owner now picks a timezone after the email step, and setup hands straight off to SDDM instead of pausing on a celebration screen with a Start Omarchy Now button. Drive the new Timezone screen (accept the geo-guessed default) and drop the button confirmation. Co-Authored-By: Claude <noreply@anthropic.com>
…t boot Deferred provisioning defers the user step to first boot, so the machine's owner should name the machine and pick the timezone there — not inherit values chosen at install time. Stop setting hostname/timezone in the configurator's deferred branch: the orchestrator already skips an empty timezone (the system stays UTC until first boot), and it now falls back to a neutral "archlinux" hostname for the install so archinstall still succeeds. The first-boot omarchy-provision-owner form collects and applies both. Harness: drive the new Hostname screen and assert both hostname and timezone actually landed on the running system after first boot. Co-Authored-By: Claude <noreply@anthropic.com>
Same fix as the first-boot greeter — tte's ColorShift judders on the 16-color framebuffer console (truecolor crush). Show the logo in solid green and drop the animation so both greeters look identical and flash-free. Co-Authored-By: Claude <noreply@anthropic.com>
…me assert - The pending-flag wait treated an SSH connection failure (rc 255) the same as "flag absent" (rc 1), so a transient blip during finalization would exit early and snapshot the base mid-finalization. Only break on a clean rc 1; keep waiting on 0 or 255. - Bump the first-boot Timezone screen wait 60s -> 180s (tzupdate geo-guess over first-boot networking can lag; matches the installer's headroom). - Make the applied-hostname check a hard failure (it's deterministic — we typed it), so a first-boot apply regression can't pass green; timezone stays a report since it's geo-guessed. Co-Authored-By: Claude <noreply@anthropic.com>
…ties Write neutral valid defaults in the configurator's deferred branch rather than empty strings, and drop the orchestrator's `config.hostname or "archlinux"` fallback (hostname is always non-empty now). The first-boot wizard overwrites both. This keeps the "owner sets them at first boot" behavior without depending on archinstall tolerating empty hostname/timezone at config-load time. Co-Authored-By: Claude <noreply@anthropic.com>
The previous hardening moved `ssh_guest "test -f pending"` out of the `while` condition into a standalone command, but the harness runs `set -euo pipefail` — so the moment the flag cleared (ssh returns 1, the intended "done" signal) it tripped errexit and aborted the whole run right after provisioning, before the session/acceptance phase. Capture the result with `|| rc=$?` so the non-zero is the signal, not a fatal error. Also guard the follow-on hostname/timezone substitutions with `|| got=""` so a transient SSH failure there can't abort either (an empty value then correctly fails the hostname assertion). Co-Authored-By: Claude <noreply@anthropic.com>
Match the first-boot greeter: restore the static green logo + looping tte ColorShift overlay. The framebuffer truecolor crush gives it a quick flash, which is acceptable — both greeters keep the animation. Co-Authored-By: Claude <noreply@anthropic.com>
A deferred-provisioning install has nothing to celebrate yet — the owner finishes setup (and gets the send-off) at first boot. So the installer's "Installed Omarchy in ..." screen and the Reboot Now prompt now belong to a direct install only: for a deferred install the dashboard clears and reboots on its own. .automated_script.sh detects deferred mode (the config's defer_provisioning flag, or the cidata defer-provisioning marker) and passes OMARCHY_UI_DEFER_PROVISIONING to the dashboard. Harness: a deferred install no longer shows Reboot Now, so wait_for_install recognizes the auto-reboot by the first-boot greeter tagline appearing. Co-Authored-By: Claude <noreply@anthropic.com>
The dashboard's deferred detection grepped user_configuration.json for the defer_provisioning boolean on one line; a reformatted config would read as a direct install and wrongly show the celebration. Parse it with jq using the same path the orchestrator reads (.omarchy_install.defer_provisioning). Co-Authored-By: Claude <noreply@anthropic.com>
Match the first-boot picker: neither has a console keymap, so both silently fell back to US. Remove them rather than offer a layout that can't apply. Co-Authored-By: Claude <noreply@anthropic.com>
dhh
added a commit
that referenced
this pull request
Aug 9, 2026
* Add OEM install mode and factory snapshots 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 OEM mode only when the bundled runtime supports it 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> * Isolate the test harness SSH identity from the local ssh-agent 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> * Make OEM state world-readable for user-context finalization 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> * Keep provisioning credentials out of OEM installs and factory snapshots 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> * Second review pass: strip account fields, clear stale cidata inputs, await OEM finalization 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> * Reorder configurator: disk before keyboard, skip keyboard for OEM 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> * Harness: prove the OEM keyboard step applies a non-default layout 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> * Update OEM comments to the renamed factory-reset command Reference omarchy-system-factory-reset (was omarchy-reset-computer) in the orchestrator comments and the plan. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Drop the configurator's runtime-support gate for OEM mode Remove oem_supported() and its branches: the configurator always offers OEM install now, rather than scanning the offline mirror's runtime package to decide. Building an ISO against a runtime that ships OEM support is the build's responsibility; the orchestrator still fails an OEM install with a clear error if the staged target somehow lacks omarchy-oem-setup. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * OEM mode via Ctrl+C on the first screen, not a mode-picker entry Restore the original screen order (keyboard first, then disk) and make Ctrl+C on the keyboard screen the entry into OEM mode — the same hidden-Ctrl+C idiom the disk-overwrite screen already uses for unencrypted installs. A confirm guards against an accidental Ctrl+C; once confirmed, OEM jumps straight to disk selection and the overwrite confirmation (no keyboard, no user), since OEM is always a full-disk install. The 'OEM install' entry leaves the mode picker. The harness drives the new path. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Restore keyboard→user→disk order; drop OEM wording from the configurator UI The normal install flow returns to its original order: keyboard, then the user step, then disk selection and mode. The Ctrl+C shortcut on the first screen and its confirmation now speak only of preparing the machine for another owner — no 'OEM' in any user-facing string (the omarchy_install.oem data contract is unchanged). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Only show the mode picker when free space is also an option Restore the pre-OEM behavior: a disk with no unallocated free space has just one viable mode, so the wizard skips the mode picker and goes straight to the overwrite confirmation. The picker appears only when a free-space install is also on offer. Also give the harness's first-boot SSH bootstrap more headroom (360s): an encrypted OEM first boot re-keys LUKS and rebuilds the UKI before sshd settles, which can exceed 180s under parallel VM load. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Tighten the prepare-for-another-owner confirm wording Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Keyboard screen: Ctrl+C hint directly under the header, no blank line Match the disk-overwrite screen, where the unencrypted-install hint sits on the line right below its message. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Rename OEM vocabulary to provisioning (ISO) Matches the runtime rename. The deferred-provisioning install mode replaces 'OEM' everywhere: omarchy_install.oem → omarchy_install.defer_provisioning --oem / --oem-file → --defer-provisioning / --defer-provisioning-file OMARCHY_INSTALL_OEM_FILE → OMARCHY_INSTALL_DEFER_PROVISIONING_FILE cidata 'oem' marker → 'defer-provisioning' /var/lib/omarchy/oem/ → /var/lib/omarchy/provisioning/ /etc/omarchy/oem.key → /etc/omarchy/provisioning.key install/oem/omarchy-oem-setup.service → install/provisioning/omarchy-provision-owner.service stage_oem_state phase → stage_provisioning_state ('Staging provisioning') Orchestrator internals (OEM_STATE_DIR, _validate_oem_state, ctx.oem, …), the configurator, cidata-load, the dashboard phase band, the harness (--oem → --provision), and the tests all move together. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Fix orchestrator caller of the renamed user-provisioning command run_chroot_finalizer still invoked /usr/bin/omarchy-finalize-user, which the rename moved to omarchy-provision-user — so a normal install died with 'No such file'. (Deferred-provisioning installs skip this phase, so only normal installs were affected.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Wait for the live VT to settle before drawing the first screen tty1 boots as an 80-column console and only widens once the kernel framebuffer/KMS takes over, which lands late — especially in VMs. The configurator's logo is wider than 80 columns, so the very first draw measured against that transient narrow console: the logo wrapped ("smushed") and, with left padding clamped to zero, hugged the left edge. Every later screen re-measures once the console has grown, which is why only the opening keyboard screen looked wrong. Hold the first draw until the width settles at or above the logo width, capped so a console that never widens still proceeds. Terminal emulators (dry runs) are already at final size and are skipped. Co-Authored-By: Claude <noreply@anthropic.com> * Confirm the Start Omarchy Now prompt after provisioning setup (#100) * Confirm the Start Omarchy Now prompt after provisioning setup First-boot account setup now ends on a celebration screen whose Start Omarchy Now button gates the SDDM handoff, so the provisioning test must press it — same as the installer's Reboot Now prompt — once the pending flag clears. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Add a centered greeter before the installer keyboard step Open the ISO configurator with the same greeter the deferred-provisioning first boot uses — vertically centered logo, the Omarchy tagline, and a single button — so install and first boot bookend setup identically. The installer's button reads "Start install"; first boot's reads "Start setup". Co-Authored-By: Claude <noreply@anthropic.com> * Animate the installer greeter logo with a skippable ColorShift Match the first-boot greeter: a looping tte ColorShift over the centered logo with a "Press Return to Start Install" hint instead of a button. Return begins the install at any time. Co-Authored-By: Claude <noreply@anthropic.com> * Theme the installer greeter ColorShift to the Omarchy palette Match the first-boot greeter: sweep the logo ColorShift through the Tokyo Night accent colors instead of tte's default rainbow. Co-Authored-By: Claude <noreply@anthropic.com> * Fix installer greeter ColorShift: green base, no flash, clean handoff Mirror the first-boot greeter fixes: indexed ANSI colors (green base with a cyan accent) because the framebuffer console can't render tte truecolor; one long tte invocation so the loop never flashes; stty sane + clear after Return so the keyboard step starts clean. Co-Authored-By: Claude <noreply@anthropic.com> * Dismiss the greeter in the QEMU test drivers The installer and first-boot flows now open with a greeter (animated logo + tagline). Wait for the tagline and press Return before the keyboard step, in both drive paths, so the harness gets past the greeter. Co-Authored-By: Claude <noreply@anthropic.com> * Kill the installer greeter animation cleanly Run tte directly instead of inside a backgrounded `while` subshell, so killing the tracked PID actually stops the effect. Killing the subshell orphaned tte, which kept painting the logo over the keyboard step. Co-Authored-By: Claude <noreply@anthropic.com> * Guard the greeter wait against set -e in the configurator too Harmless today (no set -e), but keeps the greeter's animation teardown robust if that changes. Co-Authored-By: Claude <noreply@anthropic.com> * Also settle the terminal in emulators, not just real VTs wait_for_stable_terminal skipped terminal emulators on the assumption they're already at final size, but a fresh terminal (or sudo's pty) reports a stale 24x80 for a moment at startup too. Drop the VT-only gate so the greeter centers there as well. Co-Authored-By: Claude <noreply@anthropic.com> * Test harness: drive the first-boot timezone step and direct SDDM handoff Match the deferred-provisioning first-boot flow changes: the owner now picks a timezone after the email step, and setup hands straight off to SDDM instead of pausing on a celebration screen with a Start Omarchy Now button. Drive the new Timezone screen (accept the geo-guessed default) and drop the button confirmation. Co-Authored-By: Claude <noreply@anthropic.com> * Don't bake hostname/timezone into deferred installs; set them at first boot Deferred provisioning defers the user step to first boot, so the machine's owner should name the machine and pick the timezone there — not inherit values chosen at install time. Stop setting hostname/timezone in the configurator's deferred branch: the orchestrator already skips an empty timezone (the system stays UTC until first boot), and it now falls back to a neutral "archlinux" hostname for the install so archinstall still succeeds. The first-boot omarchy-provision-owner form collects and applies both. Harness: drive the new Hostname screen and assert both hostname and timezone actually landed on the running system after first boot. Co-Authored-By: Claude <noreply@anthropic.com> * Match the installer greeter: solid green logo, no color animation Same fix as the first-boot greeter — tte's ColorShift judders on the 16-color framebuffer console (truecolor crush). Show the logo in solid green and drop the animation so both greeters look identical and flash-free. Co-Authored-By: Claude <noreply@anthropic.com> * Harden the provision harness: SSH-blip wait, timezone timeout, hostname assert - The pending-flag wait treated an SSH connection failure (rc 255) the same as "flag absent" (rc 1), so a transient blip during finalization would exit early and snapshot the base mid-finalization. Only break on a clean rc 1; keep waiting on 0 or 255. - Bump the first-boot Timezone screen wait 60s -> 180s (tzupdate geo-guess over first-boot networking can lag; matches the installer's headroom). - Make the applied-hostname check a hard failure (it's deterministic — we typed it), so a first-boot apply regression can't pass green; timezone stays a report since it's geo-guessed. Co-Authored-By: Claude <noreply@anthropic.com> * Seed hostname=omarchy/timezone=UTC in deferred install instead of empties Write neutral valid defaults in the configurator's deferred branch rather than empty strings, and drop the orchestrator's `config.hostname or "archlinux"` fallback (hostname is always non-empty now). The first-boot wizard overwrites both. This keeps the "owner sets them at first boot" behavior without depending on archinstall tolerating empty hostname/timezone at config-load time. Co-Authored-By: Claude <noreply@anthropic.com> * Fix set -e regression in the provision pending-wait loop The previous hardening moved `ssh_guest "test -f pending"` out of the `while` condition into a standalone command, but the harness runs `set -euo pipefail` — so the moment the flag cleared (ssh returns 1, the intended "done" signal) it tripped errexit and aborted the whole run right after provisioning, before the session/acceptance phase. Capture the result with `|| rc=$?` so the non-zero is the signal, not a fatal error. Also guard the follow-on hostname/timezone substitutions with `|| got=""` so a transient SSH failure there can't abort either (an empty value then correctly fails the hostname assertion). Co-Authored-By: Claude <noreply@anthropic.com> * Bring back the installer greeter ColorShift animation Match the first-boot greeter: restore the static green logo + looping tte ColorShift overlay. The framebuffer truecolor crush gives it a quick flash, which is acceptable — both greeters keep the animation. Co-Authored-By: Claude <noreply@anthropic.com> * Skip the install celebration on deferred installs; reboot directly A deferred-provisioning install has nothing to celebrate yet — the owner finishes setup (and gets the send-off) at first boot. So the installer's "Installed Omarchy in ..." screen and the Reboot Now prompt now belong to a direct install only: for a deferred install the dashboard clears and reboots on its own. .automated_script.sh detects deferred mode (the config's defer_provisioning flag, or the cidata defer-provisioning marker) and passes OMARCHY_UI_DEFER_PROVISIONING to the dashboard. Harness: a deferred install no longer shows Reboot Now, so wait_for_install recognizes the auto-reboot by the first-boot greeter tagline appearing. Co-Authored-By: Claude <noreply@anthropic.com> * Detect deferred mode with jq, not a line regex The dashboard's deferred detection grepped user_configuration.json for the defer_provisioning boolean on one line; a reformatted config would read as a direct install and wrongly show the celebration. Parse it with jq using the same path the orchestrator reads (.omarchy_install.defer_provisioning). Co-Authored-By: Claude <noreply@anthropic.com> * Drop Bosnian and Khmer from the installer keyboard picker Match the first-boot picker: neither has a console keymap, so both silently fell back to US. Remove them rather than offer a layout that can't apply. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to basecamp/omarchy#6631: first-boot account setup now ends on the install-style celebration screen with a Start Omarchy Now button gating the SDDM handoff. The provisioning test must confirm that prompt once the pending flag clears — the same way it already confirms the installer's Reboot Now prompt — or the run would hang waiting for the session.
— 🤖 Claude, posting on behalf of @dhh