You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Keep first run pending when user finalization fails #14086
omarchy-provision-first-run runs omarchy-provision-user "${finalize_user_args[@]}" || true before its other steps, so a failed user finalization is dropped. If the later steps succeed, first run is marked done, and the user's finalization is never retried at the next login.
This matters most on image installs (Apple Silicon today), where first boot creates and finalizes the owner's account. It applies to every install that finalizes a user at first run.
#13362 carried a fix: finalization was logged and counted like any other first-run step, so a failure left first run pending and retryable, with a test in test/shell.d/first-run-test.sh. d0b94d9 returned it to quattro's behavior so it can land on its own merits. That commit's diff of bin/omarchy-provision-first-run and test/shell.d/first-run-test.sh holds the change to bring back.
Heads-up: #13938 ("provision-first-run: stop swallowing user-provision failures") is open and makes this change. It runs omarchy-provision-user through run_first_run_step, so a failed finalization leaves first run pending and it gets retried, and it adds a test. #11125 and #12056 cover parts of the same thing. It may be easiest to track this on #13938 rather than bringing back the d0b94d9 diff separately.
Confirmed in source on quattro (0c93f61): bin/omarchy-provision-first-run runs omarchy-provision-user with || true, so its failure never sets first_run_failed. If the later steps succeed, first-run-user is marked and the gate at the top skips every later login. omarchy-provision-user only marks finalize-user at its very end, and nothing else retries it: omarchy-provision-owner also continues past a failed finalization, and the Hyprland autostart only calls the same gated first-run command. Nothing was run on a worker, since the defect is visible in the code.
#11125 already makes this change. It runs finalization through run_first_run_step, so a failure is logged and first run stays pending for the next login, and it adds a test to test/shell.d/first-run-test.sh. That pull request has been verified on its own. #13938, mentioned above, was closed as a duplicate of it. I tried to add Fixes #14086 to #11125 so this issue closes when it merges, but the tool refused because #11125 has had new commits since it was last classified. That link waits on #11125 being reviewed again.
One thing #11125 does not cover: a machine that already hit this, with first-run-user marked and finalize-user not, stays unfinalized, because the early gate still skips it. Whether that needs a migration is the maintainer's call.
Reviewed by Claude Opus 5.5 and, as a second opinion, Codex Medium. Codex agreed with the mechanism and with #11125 being the fix (its agreement is not guaranteed to be independent), and it was the one that raised the point about machines already affected. This issue now waits on the maintainer's decision on #11125.
Activity
jandrusk commentedon Oct 6, 2026
Heads-up: #13938 ("provision-first-run: stop swallowing user-provision failures") is open and makes this change. It runs
omarchy-provision-userthroughrun_first_run_step, so a failed finalization leaves first run pending and it gets retried, and it adds a test. #11125 and #12056 cover parts of the same thing. It may be easiest to track this on #13938 rather than bringing back the d0b94d9 diff separately.omarchybot commentedon Oct 18, 2026
Confirmed in source on
quattro(0c93f61):bin/omarchy-provision-first-runrunsomarchy-provision-userwith|| true, so its failure never setsfirst_run_failed. If the later steps succeed,first-run-useris marked and the gate at the top skips every later login.omarchy-provision-useronly marksfinalize-userat its very end, and nothing else retries it:omarchy-provision-owneralso continues past a failed finalization, and the Hyprland autostart only calls the same gated first-run command. Nothing was run on a worker, since the defect is visible in the code.#11125 already makes this change. It runs finalization through
run_first_run_step, so a failure is logged and first run stays pending for the next login, and it adds a test totest/shell.d/first-run-test.sh. That pull request has been verified on its own. #13938, mentioned above, was closed as a duplicate of it. I tried to addFixes #14086to #11125 so this issue closes when it merges, but the tool refused because #11125 has had new commits since it was last classified. That link waits on #11125 being reviewed again.One thing #11125 does not cover: a machine that already hit this, with
first-run-usermarked andfinalize-usernot, stays unfinalized, because the early gate still skips it. Whether that needs a migration is the maintainer's call.Reviewed by Claude Opus 5.5 and, as a second opinion, Codex Medium. Codex agreed with the mechanism and with #11125 being the fix (its agreement is not guaranteed to be independent), and it was the one that raised the point about machines already affected. This issue now waits on the maintainer's decision on #11125.