ZacharyZhang-NY/omarchycn
2
2
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases 3 Wiki Activity
6,295 Commits 3 Branches 6 Tags
quattro
Commit Graph
6 Commits
Author SHA1 Message Date
David Heinemeier HanssonandGitHub 9502b81f3b Reshape the agent launcher into omarchy agent (#6757) 
* Reshape the agent launcher into omarchy agent

omarchy-launch-agent becomes omarchy-agent, with prompts on omarchy-agent-prompt
rather than the bare route: `omarchy agent` is both a command and a group, so a
positional prompt there would shadow any subcommand under it. The launcher takes
flags only and points at `omarchy agent prompt` when handed one.

Every agent window now launches under a fixed org.omarchy.agent app-id instead of
omarchy-launch-tui's default of org.omarchy.<binary>, so one rule floats them all
whichever agent is default.

Omarchy also stops picking an agent for you. omarchy-default-agent prints nothing
until one is chosen, leaving every entry under Setup > Defaults > Agent unchecked,
and a first-run invitation offers to take you there.

* Wordsmith

* Cover the agent routes and the invitation

The route split is the point of the change, so exercise `omarchy agent`,
`omarchy agent prompt`, and a rejected positional prompt through the router
rather than only the binaries behind them.

The invitation gets the same treatment as the Voxtype and fingerprint ones: it
notifies once, opens the agent defaults menu, and leaves both the notification
and the marker alone for anyone who already chose an agent.

* Offer the agent choice from the keybinding

Super + Shift + Ctrl + A now runs `omarchy-agent --pick`, which opens Setup >
Defaults > Agent when nothing is chosen yet. A keypress that writes to stderr
and opens nothing just looks broken.

* Reach existing installs with the agent invitation

first-run installs the invitation hook, and existing accounts marked it complete
long ago, so they would never see it -- while being the accounts most likely to
need it, since the old getter returned opencode implicitly and most have no
agent recorded at all. Post-update hooks run later in the same update, so the
invitation arrives without waiting for another one.

* Say what the Defaults submenus set

Setup > Defaults lists Agent, Browser, Terminal, Editor, but the header inside
each repeated the same bare word, which reads as a category rather than a
setting -- and says nothing at all when the menu is summoned straight into it.
The list keeps its short labels; the headers now name the setting.
 2026-08-12 17:56:19 +02:00
David Heinemeier HanssonandClaude Opus 5 1c9dfc55f4 Greet the first login with a keybindings toast again 
Opening the cheatsheet outright put a menu in front of someone who had not
asked for one, and it blocked first run until they dismissed it. Go back to a
toast that opens the same menu when clicked.

The body carries real newlines now. It was written with a literal \n, which the
card renders as the two characters rather than a line break.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-11 05:32:47 -07:00
David Heinemeier HanssonandClaude Opus 5 f97ba7375e Wait for a connection before prompting to update 
A ping at hyprland.start answers for a machine that has not finished coming up.
Ethernet is still negotiating DHCP, so a working desktop was told to set up
Wi-Fi and offered an update it could already have run. Ask NetworkManager
instead: -s returns once it has tried every connection it could auto-activate,
which is the first moment the answer means anything, and -x then takes that
answer as it stands rather than waiting out a timeout that a laptop with
nothing to connect to would spend in silence.

The update prompt now waits for a connection rather than being phrased around
not having one. There is nothing to update against until a link lands, and one
usually does land later on the machines that started without it, so the prompt
follows the connection whenever it arrives.

That wait runs detached. It outlasts first run by design, and the keybindings
menu is on screen behind it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-11 11:56:30 +02:00
David Heinemeier HanssonandClaude Opus 5 23d85a992b Open the keybindings menu on first login 
The welcome toast spent three lines telling you about a cheatsheet that takes
one keystroke to read, and the only way to act on it was to click the toast,
which opened that cheatsheet. Open it directly instead.

Dismissing the menu exits non-zero, since no selection was made, so the step
tolerates that rather than failing first run and retrying the whole sequence
next login.

It also goes last now. The menu blocks until it is answered, and the Wi-Fi and
update toasts are the only other things left to show, so sending those first
leaves them waiting underneath rather than behind an open menu.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-11 11:56:03 +02:00
David Heinemeier HanssonGitHubClaude
 		0a8359072c Show install-style progress through first-boot account setup (#6631) 
* Add OEM first-boot setup and factory reset

An OEM-mode ISO install (or omarchy-reset-computer) leaves the machine in OEM
state: fully installed, no user, /var/lib/omarchy/oem/pending armed. On the
next boot omarchy-oem-setup.service runs the configurator's user form on tty1,
creates the user with the groups system setup recorded, finalizes it offline
from the stashed Node tarball, re-keys LUKS from the throwaway install
passphrase to the user's password, and hands off to SDDM.

omarchy-reset-computer returns a machine to that state: it swaps the running
root for a fresh clone of the @factory snapshot the ISO takes at install time,
scrubs machine identity and prior users, and stages omarchy-factory-wipe to
drop the old root and recreate @home/@log on the next boot. Machines installed
before @factory existed get a degraded reset (current system kept, users and
state wiped) with that caveat surfaced in the confirmation.

omarchy-setup-system/-hardware gain --oem to run without an install user; the
group-granting install scripts now record their groups in
/var/lib/omarchy/oem/groups and only call usermod when the user exists.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Harden OEM setup: correct cryptsetup key-file usage, retry on failure

cryptsetup reads --test-passphrase/--key-file inputs byte-for-byte, so feed
passphrases through process substitution consistently instead of positional
args or stdin (which has different newline semantics). Run each first-boot
setup attempt as its own process so a failure offers a retry instead of
stranding the machine at a user-less login screen — bash ignores errexit
inside `while !` conditions, a child process does not.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Always grant wheel sudo in OEM first-boot setup

Detecting an existing %wheel grant by grepping sudoers is error-prone:
omarchy ships narrow '%wheel ALL=(ALL) NOPASSWD: <command>' rules (e.g.
asdcontrol) that match the naive pattern, which left the OEM-created user
matching sudoers entries but unable to run anything. Write the drop-in
unconditionally — a duplicate of an existing full grant is harmless.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Fix LUKS re-key device resolution and OEM state readability

archinstall's encrypted installs put cryptdevice=PARTUUID=... on the kernel
cmdline, not UUID=, so the first-boot re-key never found its device and
silently skipped — leaving the throwaway auto-unlock keyfile in place, i.e.
the disk effectively unencrypted. Parse every cryptdevice= source spec form
and make any re-key failure abort the attempt loudly: a retry prompt beats a
machine that quietly boots without a passphrase forever.

The OEM state directory also has to be world-readable (its one secret,
luks-key, stays 0600): user finalization reads the stashed Node tarball as
the new user, and the 0700 directory forced it onto the network fallback.

Step markers now land in /var/log/omarchy-oem-setup.log for debuggability.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Purge stale machine-id boot entries when resetting or re-keying

limine-entry-tool keys its limine.conf OS entries by machine-id. A factory
reset gives the machine a fresh identity, so the previous system's entry
survived every rebuild, sorted first, and made Limine stop at a Blake2b
hash-mismatch warning once the UKI was rebuilt. Start limine.conf over from
the shipped template (and drop foreign machine-id history directories on the
ESP) before any post-reset rebuild: in the staged chroot rebuild, in the
first-boot LUKS re-key, and — for unencrypted resets, where nothing else
rebuilds — in a dedicated first-boot refresh when foreign entries are found.

The staged rebuild also verifies every UKI hash referenced by limine.conf
against the file on the ESP before the subvolume swap, and the running
system's limine-snapper-sync is runtime-masked during staging so it cannot
rewrite the config behind the rebuild.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Harden reset and first-boot setup failure paths

Review findings from codex and Copilot:

- Generate throwaway passphrases without a trailing head stage: under
  pipefail, SIGPIPE from the infinite tr failed the substitution and errexit
  aborted every encrypted reset before it could stage anything.
- Stage the fallible parts of a degraded reset (LUKS re-key, boot rebuild)
  before arming the wipe, so a staging failure leaves the machine untouched
  instead of scheduling a wipe for a reset that never finished.
- Gate first-boot setup on the factory wipe having succeeded
  (ConditionPathExists=!wipe-pending plus an in-script guard): creating the
  new user on a half-wiped system would hand their data to the wipe retry.
- Abort the wipe (keeping its retry marker) when deleting the old root or
  recreating @home/@log fails, and abort resets that cannot remove a prior
  account — a surviving account keeps its password and wheel membership.
- Resume a partially-created account on setup retry instead of rejecting the
  username the failed attempt just created.
- Only purge machine-id directories the old limine.conf actually referenced;
  a shared ESP may hold other installations' boot artifacts.
- Recreate the hibernation swapfile (nested subvolume, so never captured by
  the factory snapshot) inside the factory root before its UKI rebuild, so a
  reset machine keeps disk-backed swap and a valid resume offset.
- Source base-test.sh in the OEM groups test per test conventions.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Recreate the hibernation swapfile even when resume drop-ins survive

omarchy-hibernation-setup short-circuits as 'already set up' when the resume
mkinitcpio drop-in exists — which it always does in a factory root, while the
swapfile itself never survives the snapshot (nested subvolume). Drop the
marker when the swapfile is gone so setup reconfigures from scratch, and
verify the swapfile actually exists before proceeding with the reset.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Second review pass: encrypted-config coverage, factory-baseline sanitization, recoverable rekey

Codex xhigh round 2:

- Detect the LUKS backing device by walking the root's device tree, not only
  the cmdline cryptdevice=; reset/first-boot now re-key roots reached via
  rd.luks/crypttab too, instead of silently leaving the seller's slots valid.
- Sanitize the retained @factory baseline (accounts, /etc/shadow, machine
  identity) during a full reset: the new wheel user could otherwise mount it
  to recover the seller's data, and a second reset would restore the account.
- Re-key the disk recoverably: rebuild the no-auto-unlock UKI before killing
  the throwaway slot or destroying the staged key, and restore the keyfile if
  that rebuild fails, so a retry with a different password can never leave the
  disk locked to the first attempt's password.
- Roll back a degraded reset's live-root auto-unlock material if its boot
  rebuild fails, instead of leaving it for a later rebuild to embed.
- Treat a missing current-machine limine entry as stale so a retry after a
  failed rebuild repairs the config instead of clearing OEM state over it.
- Erase fingerprint enrollments (/var/lib/fprint) in degraded wipes.
- Remove the resume-offset drop-in too when recreating the factory swapfile,
  so the rebuilt UKI gets a correct offset.
- Pin first-boot retries to the account the first attempt created.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Expose factory reset in the Setup menu

Add a 'Reset Computer' entry under Setup (Omarchy's Settings menu, where OS
factory resets conventionally live), guarded to btrfs roots and launched in a
floating terminal. omarchy-reset-computer now self-elevates via sudo so the
menu entry needs no sudo prefix, forwarding the caller's gum theme env as
env arguments so styling survives an env_reset sudoers. The typed 'reset'
confirmation and the sudo password prompt remain as the guards against
accidental triggering.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Defer keyboard selection to first boot for OEM installs

The OEM first-boot setup now runs a keyboard step before the user form,
mirroring the ISO configurator: it loads the chosen layout on the live VT so
the password (and the LUKS re-key that follows) are typed under it, and
persists it with systemd-firstboot so the installed system gets both the
console KEYMAP and the XKB layout Hyprland reads — exactly what a normal
install writes. Layouts localectl doesn't know keep the default, same as the
installer.

This lets the OEM operator set nothing user-specific: the machine's owner
picks their keyboard alongside their account at first boot.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Rename factory-reset commands to omarchy-system-factory-reset[-finish]

omarchy-reset-computer      -> omarchy-system-factory-reset
omarchy-factory-wipe        -> omarchy-system-factory-reset-finish
(and its systemd unit, log path, and temp mount to match)

Pure rename: every reference — the Setup menu action, the first-boot finish
service the reset stages and enables, the oem-setup ordering/gating, comments,
and the menu test — moves together, with no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Rename OEM vocabulary to provisioning (runtime)

Commands unify under the provisioning family:
  omarchy-oem-setup      → omarchy-provision-owner
  omarchy-finalize-user  → omarchy-provision-user
  omarchy-first-run      → omarchy-provision-first-run

And the deferred-provisioning state/vocabulary replaces 'OEM':
  /var/lib/omarchy/oem/          → /var/lib/omarchy/provisioning/
  /etc/omarchy/oem.key           → /etc/omarchy/provisioning.key
  install/oem/                   → install/provisioning/
  OMARCHY_SETUP_CONTEXT=oem-firstboot → provision-owner
  omarchy-setup-system/-hardware --oem → --defer-provisioning

All callers (provision-first-run→provision-user, autostart, factory-reset
staging the provisioning units, the group-recording scripts) and comments
move together.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Drop remaining OEM mentions from the provisioning groups test

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Show install-style progress through first-boot account setup

The owner provisioning flow dropped to plain status lines after the
confirm form, went dark for the minutes finalize-user takes, and ended
with a two-second spinner. Give it the same treatment as the ISO
install dashboard: the logo header with a live progress bar and
rotating tips while the account is created, finalized, re-keyed, and
the boot entries refreshed, then the same tte celebration — ending in
a Start Omarchy Now button that hands off to SDDM, since first boot
continues into the session rather than rebooting.

The bar is the dashboard's engine in miniature: monotonic per-mille
position from an asymptotic time floor per phase, with finalize-user's
run_logged scripts in the log as the work signal.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Match the first-boot console font to the ISO installer

The ISO installer runs on a low-resolution pre-KMS console, where the
default 8x16 console font looks large. By the time omarchy-provision-owner
runs, the installed system has reached full KMS resolution, where that
same 8x16 font is physically tiny — so first-boot owner provisioning
looked a lot smaller than the installer it continues.

Scale the console font up on high-resolution framebuffers so the two
read at the same size: latarcyrheb-sun32 (16x32) at >=1600px tall,
sun12x22 at >=1150px, and the default left untouched below that (already
installer-sized). Both fonts ship with kbd, so there's no new dependency,
and it's a no-op off a real VT.

Co-Authored-By: Claude <noreply@anthropic.com>

* Make first-boot font resolution-adaptive; widen the encrypting band

Two fixes to the first-boot provisioning screen surfaced on a real
high-resolution display.

Font: the earlier fixed thresholds could pick a 16px-wide font on a
~1280px-wide console — 80 columns, one short of the 81-column logo — so
the logo wrapped and the layout looked misaligned. Replace the thresholds
with a resolution-adaptive choice: pick the kbd font whose row count is
closest to the ISO installer's ~48-row feel, but never one wide enough to
drop below 90 columns, so the logo can never wrap. Low-resolution
consoles land on the default font (a no-op), matching the installer.

Progress: the LUKS re-key (a full UKI rebuild, the slowest step of an
encrypted first boot) had only an 8%-wide band, so the bar looked stuck
near the top while it worked. Make the bands adaptive — when a re-key is
pending, finalize yields most of its room to a wide, steadily-moving
re-key band; unencrypted installs keep finalize as the dominant step.

Co-Authored-By: Claude <noreply@anthropic.com>

* Add a Welcome greeter before first-boot setup

Deferred-provisioning first boot dropped the new owner straight onto the
keyboard picker. Open with a greeter instead — the same frame the setup
ends on: static logo, a centered "Welcome to Omarchy", and a single
"Start setup" button. No logo animation; it's the starting line, not the
celebration. Shown once in main(), before the keyboard step, so retries
don't repeat it.

Co-Authored-By: Claude <noreply@anthropic.com>

* Center the greeter and show the Omarchy tagline

Vertically center the greeter block (logo, tagline, button) on the
console like the boot logo, and replace "Welcome to Omarchy" with the
tagline "Beautiful, Modern & Opinionated Linux by DHH".

Co-Authored-By: Claude <noreply@anthropic.com>

* Animate the greeter logo with a skippable ColorShift

Run a looping tte ColorShift over the centered logo and replace the
button with a "Press Return to Start Setup" hint. The effect reads from
/dev/null so it never swallows the Return a foreground read waits on, and
--reuse-canvas is anchored one row below the logo so it repaints exactly
the rows drawn above. Return skips ahead into setup at any time.

Co-Authored-By: Claude <noreply@anthropic.com>

* Theme the greeter ColorShift to the Omarchy palette

Sweep the logo ColorShift through the Tokyo Night accent colors
(green, cyan, blue, purple, pink, orange) instead of tte's default
rainbow, settling toward the Omarchy green.

Co-Authored-By: Claude <noreply@anthropic.com>

* Fix greeter ColorShift: green base, no flash, clean handoff

- Use indexed ANSI colors (green 2 + cyan 6 accent), since the framebuffer
  console can't render tte's truecolor and crushed it to a muddy lavender.
  The result is a green-based shift with a cyan accent, settling on green.
- Run one long tte invocation (--cycles 1000) instead of restarting every
  couple cycles, removing the flash at each loop.
- Restore the tty with `stty sane` after killing the effect (tte leaves it
  raw/no-echo, which silently killed the following gum prompts) and clear
  the screen so the leftover frame doesn't linger under the keyboard step.

Co-Authored-By: Claude <noreply@anthropic.com>

* Kill the greeter animation cleanly so the form starts fresh

The ColorShift ran inside a `while` subshell that was backgrounded and
killed by its subshell PID — which orphaned the tte child, leaving it
painting the logo over the keyboard step (the screen never cleared and
the form was garbled). Run tte directly so the tracked PID is tte's own,
and killing it actually stops the animation before the screen is cleared.

Co-Authored-By: Claude <noreply@anthropic.com>

* Don't let the killed animation abort provisioning under set -e

wait on the tte PID reports its kill signal (143). Under set -euo
pipefail that nonzero status aborted greeter_screen — and the whole
service — right after Return, dropping first boot straight to the login
screen instead of the keyboard step. Tolerate it with `|| true`.

Co-Authored-By: Claude <noreply@anthropic.com>

* Wait for the terminal size to settle before drawing the greeter

A terminal emulator — or sudo's pty — reports a stale 24x80 for a few
hundred milliseconds after the process starts, before its real winsize is
set. The greeter measured immediately and fell into the 80x24 fallback,
rendering small in the top-left instead of centered (the real first-boot
console, already settled, was unaffected). Wait for stty to report a
stable size at least as wide as the logo before measuring.

Co-Authored-By: Claude <noreply@anthropic.com>

* Fall back to the default font when the greeter console is too narrow

scale_console_font sizes the console font from /sys/class/graphics/fb0,
but virtio-gpu (notably virtio-vga-gl) can report a resolution that the
console then settles below — leaving a font wide enough that an 81-column
logo no longer fits (e.g. sun32 at a settled 1280px is 80 columns). The
logo wrapped and hugged the top-left, with the animation tiling over it.

After the greeter measures the settled size, if it is still narrower than
the logo, drop to the default (narrowest) console font and re-measure so
the logo always fits and centers. Verified by forcing an 80-column
console: the fallback recovers it to 160 columns, centered, and
provisioning completes.

Co-Authored-By: Claude <noreply@anthropic.com>

* Redraw the greeter on console resize instead of measuring once

The first-boot greeter measured the console once, painted the logo and
launched the tte animation, then blocked on Return. On a fresh
deferred-provisioning boot under virtio-gpu the VT comes up in a
transitional ~80x25 mode and only widens to the real resolution a second
or more later, once KMS takes over (or, on virtio-vga-gl, the SDL window's
size lands). The old settle-wait accepted that transient (two matching
100ms samples was enough), so the greeter committed to an 80-column
geometry. When the VT then resized, Linux scrolled the stranded frame into
the top-left and reset the DEC saved cursor tte paints from with
--reuse-canvas — the small, top-left, tiled/garbled logo. The earlier
"fall back to default8x16 when cols<81" fix couldn't help: if the console
genuinely offers 80 columns, re-applying the narrowest font still leaves
80.

Treat a resize as a redraw trigger instead. greeter_screen now:

- waits for a real quiet period (console signature = VT size + framebuffer
  identity/size held steady ~1.5s) before the first paint;
- sizes the font empirically — apply each candidate, read the columns
  fbcon actually returns, keep the one nearest ~48 rows that still clears
  the 81-column logo — rather than trusting fb0/virtual_size, which under
  virgl can report a size the text console never reaches;
- paints from a nested _greeter_draw and, while waiting for Return, watches
  SIGWINCH and the console signature; on any change it kills tte, settles,
  re-fits the font, and repaints — so a resize arriving five seconds in
  looks the same as one that never happened;
- draws each logo row at an explicit column and falls back to a centered
  text-only greeter (no logo, no animation) when the console is narrower
  than the logo, so a still-transient mode never wraps it into mush;
- runs tte at canvas-width cols-1 to stay off the autowrap column.

Verified the resize path in a tmux pane (a resizable pty): narrow first
paint falls back to centered text, and each later resize repaints a
correctly centered logo, with a clean exit on Return.

Co-Authored-By: Claude <noreply@anthropic.com>

* Ask the owner's timezone at first boot and hand off straight to Omarchy

Three changes to the deferred first-boot setup:

- Timezone: deferred provisioning skips the installer's user step entirely
  (it defers user creation to first boot), but the first-boot form only
  re-asked username/password/name/email — the timezone picker was never
  carried over, so every deferred machine silently kept archinstall's UTC
  default and the owner was never asked. Add the timezone step to the
  first-boot user form (geo-guessed default via tzupdate, same as the ISO
  installer's user step), show it on the confirmation screen, and apply it
  during provisioning with timedatectl.

- Rename the progress-screen title from "Setting up your account" to
  "Setting up your machine": first boot provisions the whole machine, not
  just an account.

- Drop the timed "Installed Omarchy in Xm Ys" celebration screen and the
  "Start Omarchy Now" button from first boot. That send-off belongs to a
  direct install; here the oneshot service just hands straight off to SDDM
  (Before=display-manager.service), which autologins on encrypted installs.
  A brief "Starting Omarchy..." covers the handoff.

Co-Authored-By: Claude <noreply@anthropic.com>

* Autologin only the first deferred boot on unencrypted installs

The owner authenticates in the first-boot form, so setup hands straight into
the desktop instead of asking again at SDDM. Encrypted installs keep autologin
permanently (the LUKS prompt is the auth boundary); unencrypted installs
autologin just this once and a self-removing service deletes the drop-in after
the desktop is up, so later boots use the normal SDDM login and the disk isn't
left permanently open.

Co-Authored-By: Claude <noreply@anthropic.com>

* Ask the owner's hostname at first boot too

Deferred provisioning no longer bakes a hostname into the install, so add the
hostname to the first-boot user form (same letters/digits/dashes validation as
the ISO installer's user step, defaulting to "omarchy" on empty), show it on
the confirmation screen, and apply it with hostnamectl during provisioning —
alongside the timezone step.

Co-Authored-By: Claude <noreply@anthropic.com>

* Let the greeter logo appear from the animation, not a static pre-render

The greeter drew the logo statically in green and then started the tte
ColorShift over the same rows, so the logo visibly flashed as tte's first
frame repainted it. ColorShift shows the full logo on frame one (it's a color
effect, not a type-in), so let tte paint the logo itself: skip the static
render when tte is available (keep it only as the no-tte fallback). The logo
now simply appears, already animating, with no flash.

Co-Authored-By: Claude <noreply@anthropic.com>

* Drop the greeter color animation; show the logo in solid green

The greeter "flash" was tte's ColorShift crushing on the framebuffer console:
tte emits 24-bit truecolor, the console only has 16 flat colors, and
consecutive frames' greens snap to different buckets (green/bright-green/cyan/
gray) — a frame-to-frame judder. A smooth color fade is impossible on the
console (no blending), so the animation can't be made clean there. Show the
logo in solid green (indexed color 2, which renders stably) with no animation.
The resize-redraw resilience stays; there's just no tte to tear down now.

Co-Authored-By: Claude <noreply@anthropic.com>

* Fix first-boot review findings: autologin-once ordering, offline timezone

Review of the deferred first-boot flow surfaced two real, user-facing bugs:

- Autologin fired twice on unencrypted installs. The one-shot cleanup unit was
  ordered After=display-manager and enabled via a graphical.target.wants symlink
  + daemon-reload during the first boot — but graphical.target's job for that
  boot is already computed, so systemd never pulled the new unit in. It only ran
  on the *second* boot (which also autologged in) and removed the drop-in there.
  Order it Before=display-manager instead (and drop the sleep fudge): this boot
  autologins, the next boot's fresh transaction runs the cleanup before SDDM
  reads its config, so that boot shows the normal login. Exactly one autologin,
  deterministic, no race.

- Offline first boot aborted setup. `geo_guessed_timezone=$(tzupdate -p)` is a
  plain assignment under `set -e`, and tzupdate exits non-zero with no network —
  the common case for a fresh machine — killing the attempt before the offline
  gum-filter fallback. Guard it with `|| geo_guessed_timezone=""`.

Also: configure_timezone no longer symlinks /etc/localtime to a nonexistent
zone file on a bad zone (guards on the zoneinfo file existing); scale_console_font's
stty-size fallback emits a trailing newline so `read` can't trip `set -e`; and
drop two stty-sane calls that only existed to recover from tte's raw mode (tte
is gone).

Co-Authored-By: Claude <noreply@anthropic.com>

* Seed placeholder hostname/timezone in deferred install, overwrite at first boot

Simpler than the empty-string approach: instead of writing hostname=""/timezone=""
and having the orchestrator fall back, the deferred install now seeds neutral
valid defaults (hostname=omarchy, timezone=UTC) and the first-boot wizard
overwrites both. Identical end state, one decision in one place, and no reliance
on archinstall accepting empty config values. Runtime comments updated; the
configure_* functions are unchanged (they still overwrite whatever was seeded).

Co-Authored-By: Claude <noreply@anthropic.com>

* Bring back the greeter ColorShift animation

Reverts the "drop the color animation" change — the framebuffer's truecolor
crush gives the ColorShift a quick flash, but that's acceptable; removing the
effect entirely was overreach. Restores the static green logo + looping tte
ColorShift overlay (green base, cyan accent, settling on green), keeping the
resize-redraw resilience and every other fix intact.

Co-Authored-By: Claude <noreply@anthropic.com>

* Hide the omarchy-provision-* commands from the listing

These run from services and install hooks (first-boot provisioning, per-user
finalize, first-login) — never something a user invokes directly. Mark them
omarchy:hidden=true and drop the group/examples that implied a user-facing
route. The binaries still work when called directly by their callers.

Co-Authored-By: Claude <noreply@anthropic.com>

* Hide the factory-reset first-boot worker from the listing

omarchy-system-factory-reset-finish runs from a first-boot service after a
reset — never invoked by hand — so hide it like the provision workers.
omarchy-system-factory-reset itself stays visible (Setup > Reset Computer).

Co-Authored-By: Claude <noreply@anthropic.com>

* Address final-review findings: LUKS fail-open, set -e aborts, drop-to-console

Codex xhigh final pass surfaced several real issues; the contained ones:

- LUKS re-key could fail open (security). If the user's slot couldn't be
  identified, or luksDump/luksKillSlot failed, the code shredded the staged key
  anyway while the throwaway/seller slots stayed valid — leaving the disk
  unlockable by the install passphrase forever. Now it's all-or-nothing: require
  the user's slot, enumerate and kill every other slot, and only retire the
  staged key once all kills succeed; otherwise fail loudly and keep it for retry.

- Greeter animation cleanup: `kill "$anim"` was unguarded, so if tte had already
  exited (crash or resize race) it returned non-zero and `set -e` aborted setup,
  dropping to SDDM with no user. Guard it with `|| true`.

- reset_limine_config: `old_ids=$(grep ... | ...)` on an entry-less limine.conf
  (left by a failed rebuild) exits 1 under pipefail and aborted the retry. Guard
  with `|| true` so a rebuild failure stays recoverable.

- "Drop to console" on a failed setup exited to nothing usable (no user, root
  locked, tty1 getty conflicted). Exec a root shell on tty1 instead; SDDM starts
  when it exits.

Co-Authored-By: Claude <noreply@anthropic.com>

* Drop Bosnian and Khmer from the keyboard picker

Neither has a console keymap (loadkeys ba / loadkeys khmer both fail), so
picking them showed the choice as confirmed but silently left the system on the
default US layout. Remove them from the first-boot picker rather than offer a
layout that can't apply. The orchestrator keeps its defensive unsupported-keymap
handling for install-time robustness.

Co-Authored-By: Claude <noreply@anthropic.com>

* Finish the omarchy-first-run rename in the docs

Two doc references to omarchy-first-run were missed when the script was renamed
to omarchy-provision-first-run; update them to match.

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
 2026-08-09 22:01:35 +02:00
David Heinemeier HanssonGitHubClaude
 		6fa4f78ee1 Add deferred first-boot provisioning and factory reset (#6621) 
* Add OEM first-boot setup and factory reset

An OEM-mode ISO install (or omarchy-reset-computer) leaves the machine in OEM
state: fully installed, no user, /var/lib/omarchy/oem/pending armed. On the
next boot omarchy-oem-setup.service runs the configurator's user form on tty1,
creates the user with the groups system setup recorded, finalizes it offline
from the stashed Node tarball, re-keys LUKS from the throwaway install
passphrase to the user's password, and hands off to SDDM.

omarchy-reset-computer returns a machine to that state: it swaps the running
root for a fresh clone of the @factory snapshot the ISO takes at install time,
scrubs machine identity and prior users, and stages omarchy-factory-wipe to
drop the old root and recreate @home/@log on the next boot. Machines installed
before @factory existed get a degraded reset (current system kept, users and
state wiped) with that caveat surfaced in the confirmation.

omarchy-setup-system/-hardware gain --oem to run without an install user; the
group-granting install scripts now record their groups in
/var/lib/omarchy/oem/groups and only call usermod when the user exists.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Harden OEM setup: correct cryptsetup key-file usage, retry on failure

cryptsetup reads --test-passphrase/--key-file inputs byte-for-byte, so feed
passphrases through process substitution consistently instead of positional
args or stdin (which has different newline semantics). Run each first-boot
setup attempt as its own process so a failure offers a retry instead of
stranding the machine at a user-less login screen — bash ignores errexit
inside `while !` conditions, a child process does not.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Always grant wheel sudo in OEM first-boot setup

Detecting an existing %wheel grant by grepping sudoers is error-prone:
omarchy ships narrow '%wheel ALL=(ALL) NOPASSWD: <command>' rules (e.g.
asdcontrol) that match the naive pattern, which left the OEM-created user
matching sudoers entries but unable to run anything. Write the drop-in
unconditionally — a duplicate of an existing full grant is harmless.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Fix LUKS re-key device resolution and OEM state readability

archinstall's encrypted installs put cryptdevice=PARTUUID=... on the kernel
cmdline, not UUID=, so the first-boot re-key never found its device and
silently skipped — leaving the throwaway auto-unlock keyfile in place, i.e.
the disk effectively unencrypted. Parse every cryptdevice= source spec form
and make any re-key failure abort the attempt loudly: a retry prompt beats a
machine that quietly boots without a passphrase forever.

The OEM state directory also has to be world-readable (its one secret,
luks-key, stays 0600): user finalization reads the stashed Node tarball as
the new user, and the 0700 directory forced it onto the network fallback.

Step markers now land in /var/log/omarchy-oem-setup.log for debuggability.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Purge stale machine-id boot entries when resetting or re-keying

limine-entry-tool keys its limine.conf OS entries by machine-id. A factory
reset gives the machine a fresh identity, so the previous system's entry
survived every rebuild, sorted first, and made Limine stop at a Blake2b
hash-mismatch warning once the UKI was rebuilt. Start limine.conf over from
the shipped template (and drop foreign machine-id history directories on the
ESP) before any post-reset rebuild: in the staged chroot rebuild, in the
first-boot LUKS re-key, and — for unencrypted resets, where nothing else
rebuilds — in a dedicated first-boot refresh when foreign entries are found.

The staged rebuild also verifies every UKI hash referenced by limine.conf
against the file on the ESP before the subvolume swap, and the running
system's limine-snapper-sync is runtime-masked during staging so it cannot
rewrite the config behind the rebuild.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Harden reset and first-boot setup failure paths

Review findings from codex and Copilot:

- Generate throwaway passphrases without a trailing head stage: under
  pipefail, SIGPIPE from the infinite tr failed the substitution and errexit
  aborted every encrypted reset before it could stage anything.
- Stage the fallible parts of a degraded reset (LUKS re-key, boot rebuild)
  before arming the wipe, so a staging failure leaves the machine untouched
  instead of scheduling a wipe for a reset that never finished.
- Gate first-boot setup on the factory wipe having succeeded
  (ConditionPathExists=!wipe-pending plus an in-script guard): creating the
  new user on a half-wiped system would hand their data to the wipe retry.
- Abort the wipe (keeping its retry marker) when deleting the old root or
  recreating @home/@log fails, and abort resets that cannot remove a prior
  account — a surviving account keeps its password and wheel membership.
- Resume a partially-created account on setup retry instead of rejecting the
  username the failed attempt just created.
- Only purge machine-id directories the old limine.conf actually referenced;
  a shared ESP may hold other installations' boot artifacts.
- Recreate the hibernation swapfile (nested subvolume, so never captured by
  the factory snapshot) inside the factory root before its UKI rebuild, so a
  reset machine keeps disk-backed swap and a valid resume offset.
- Source base-test.sh in the OEM groups test per test conventions.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Recreate the hibernation swapfile even when resume drop-ins survive

omarchy-hibernation-setup short-circuits as 'already set up' when the resume
mkinitcpio drop-in exists — which it always does in a factory root, while the
swapfile itself never survives the snapshot (nested subvolume). Drop the
marker when the swapfile is gone so setup reconfigures from scratch, and
verify the swapfile actually exists before proceeding with the reset.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Second review pass: encrypted-config coverage, factory-baseline sanitization, recoverable rekey

Codex xhigh round 2:

- Detect the LUKS backing device by walking the root's device tree, not only
  the cmdline cryptdevice=; reset/first-boot now re-key roots reached via
  rd.luks/crypttab too, instead of silently leaving the seller's slots valid.
- Sanitize the retained @factory baseline (accounts, /etc/shadow, machine
  identity) during a full reset: the new wheel user could otherwise mount it
  to recover the seller's data, and a second reset would restore the account.
- Re-key the disk recoverably: rebuild the no-auto-unlock UKI before killing
  the throwaway slot or destroying the staged key, and restore the keyfile if
  that rebuild fails, so a retry with a different password can never leave the
  disk locked to the first attempt's password.
- Roll back a degraded reset's live-root auto-unlock material if its boot
  rebuild fails, instead of leaving it for a later rebuild to embed.
- Treat a missing current-machine limine entry as stale so a retry after a
  failed rebuild repairs the config instead of clearing OEM state over it.
- Erase fingerprint enrollments (/var/lib/fprint) in degraded wipes.
- Remove the resume-offset drop-in too when recreating the factory swapfile,
  so the rebuilt UKI gets a correct offset.
- Pin first-boot retries to the account the first attempt created.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Expose factory reset in the Setup menu

Add a 'Reset Computer' entry under Setup (Omarchy's Settings menu, where OS
factory resets conventionally live), guarded to btrfs roots and launched in a
floating terminal. omarchy-reset-computer now self-elevates via sudo so the
menu entry needs no sudo prefix, forwarding the caller's gum theme env as
env arguments so styling survives an env_reset sudoers. The typed 'reset'
confirmation and the sudo password prompt remain as the guards against
accidental triggering.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Defer keyboard selection to first boot for OEM installs

The OEM first-boot setup now runs a keyboard step before the user form,
mirroring the ISO configurator: it loads the chosen layout on the live VT so
the password (and the LUKS re-key that follows) are typed under it, and
persists it with systemd-firstboot so the installed system gets both the
console KEYMAP and the XKB layout Hyprland reads — exactly what a normal
install writes. Layouts localectl doesn't know keep the default, same as the
installer.

This lets the OEM operator set nothing user-specific: the machine's owner
picks their keyboard alongside their account at first boot.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Rename factory-reset commands to omarchy-system-factory-reset[-finish]

omarchy-reset-computer      -> omarchy-system-factory-reset
omarchy-factory-wipe        -> omarchy-system-factory-reset-finish
(and its systemd unit, log path, and temp mount to match)

Pure rename: every reference — the Setup menu action, the first-boot finish
service the reset stages and enables, the oem-setup ordering/gating, comments,
and the menu test — moves together, with no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Rename OEM vocabulary to provisioning (runtime)

Commands unify under the provisioning family:
  omarchy-oem-setup      → omarchy-provision-owner
  omarchy-finalize-user  → omarchy-provision-user
  omarchy-first-run      → omarchy-provision-first-run

And the deferred-provisioning state/vocabulary replaces 'OEM':
  /var/lib/omarchy/oem/          → /var/lib/omarchy/provisioning/
  /etc/omarchy/oem.key           → /etc/omarchy/provisioning.key
  install/oem/                   → install/provisioning/
  OMARCHY_SETUP_CONTEXT=oem-firstboot → provision-owner
  omarchy-setup-system/-hardware --oem → --defer-provisioning

All callers (provision-first-run→provision-user, autostart, factory-reset
staging the provisioning units, the group-recording scripts) and comments
move together.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Drop remaining OEM mentions from the provisioning groups test

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Finish the omarchy-first-run rename in the docs

Two doc references to omarchy-first-run were missed when the script was renamed
to omarchy-provision-first-run; update them to match.

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
 2026-08-09 21:54:21 +02:00