Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Improving resilience around upgrades and improving recovery mode
Reported by danfascia · filed Aug 12, 2025Closed upstream on 2025-09-16 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
It would be highly desirable to improve the experience around upgrades.
Due to the rolling nature of Arch releases it may not be possible to prevent bricking around upgrades, without losing the Arch benefit of having the latest and greatest. However, we can do better with the experience around when it goes wrong. Right now it is a very bare experience. You're on your own, hit the Discord and beg for help from experts.
Key Issues
- No snapshot and rollback around upgrades
- Non-functional recovery mode (due to lack of vfat driver in default initramfs, inspite of using a vfat boot partition it is impossible to mount /boot )
What the ideal experience looks like
- Omarchy-update creates a snapshot then moves on to the upgrade process
- Omarchy update summarises its changes, confirms and displays snapshot name/timestamp at the end of the upgrade process
- Omarchy-update promotes restart when required (think it already does)
On brick...
- Boot menu contains an item to "Restore from snapshot"
- Displays list of snapshots by timestamp + omarchy version (configurable in omarchy menu how many snapshots are retained)
- Snapshot is restored with good feedback and confirmation during process before prompting reboot
- Log file presented on booting back into Omarchy desktop (neovim) showing logfile for issue debugging
Recovery mode
- Create a recovery mode which contains the tools required to get to command line, mount any partition and work on files (nano?)
- Consider a separate partition which contains the Arch liveusb also accessible from boot menu, which would allow a third party environment to work on the bricked volumes, but crucially containing all core tools needed
I do not have the technical skills to help make this a reality but I am most thankful for all of the great progress and will be glad to help test and document / feedback.
View raw text
**It would be highly desirable to improve the experience around upgrades.** Due to the rolling nature of Arch releases it may not be possible to prevent bricking around upgrades, without losing the Arch benefit of having the latest and greatest. However, we can do better with the experience around when it goes wrong. Right now it is a very bare experience. You're on your own, hit the Discord and beg for help from experts. ## Key Issues 1. No snapshot and rollback around upgrades 2. Non-functional recovery mode (due to lack of vfat driver in default initramfs, inspite of using a vfat boot partition it is impossible to mount /boot ) ## What the ideal experience looks like - Omarchy-update creates a snapshot then moves on to the upgrade process - Omarchy update summarises its changes, confirms and displays snapshot name/timestamp at the end of the upgrade process - Omarchy-update promotes restart when required (think it already does) ### On brick... - Boot menu contains an item to "Restore from snapshot" - Displays list of snapshots by timestamp + omarchy version (configurable in omarchy menu how many snapshots are retained) - Snapshot is restored with good feedback and confirmation during process before prompting reboot - Log file presented on booting back into Omarchy desktop (neovim) showing logfile for issue debugging ### Recovery mode - Create a recovery mode which contains the tools required to get to command line, mount any partition and work on files (nano?) - Consider a separate partition which contains the Arch liveusb also accessible from boot menu, which would allow a third party environment to work on the bricked volumes, but crucially containing all core tools needed I do not have the technical skills to help make this a reality but I am most thankful for all of the great progress and will be glad to help test and document / feedback.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.