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.
[Quattro] Encrypted hibernate asks for both LUKS and session passwords
Reported by ClGratton · filed Aug 29, 2026 · open at source
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?
- 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. So far: in the audited area (lock) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
System details
Omarchy 4.0.1 Quattro, Linux 7.1.9, encrypted Btrfs root using Omarchy's stock cryptdevice= initramfs flow, with hibernate enabled through Omarchy Setup.
Problem
Hibernate resume can require two authentication prompts on a stock encrypted installation. The initramfs LUKS prompt decrypts the root device and restores the hibernation image, then the restored native Omarchy session lock asks for the account password again.
This happens because omarchy-system-sleep-monitor receives logind's generic PrepareForSleep(true) signal for both suspend and hibernate and normally invokes omarchy-system-sleep-lock. Normal reboot has only the LUKS prompt because there is no saved desktop session or session lock to restore.
Expected behavior
For Omarchy's stock interactive LUKS hibernate path, boot decryption should be the one authentication step. Unencrypted roots, keyfile or automatic unlock, unknown or custom encryption paths, suspend, and direct or unmarked sleep requests must retain the native session lock.
Current finding
The latest double-authentication trace proves that the sleep monitor saw no live hibernate marker and therefore locked before S4. The old wrapper did not log whether it was bypassed or fell back, so the missing marker's historical cause cannot be reconstructed. Current encrypted-root detection and advisory marker locking pass, and PR #8910 now logs every marker decision and fallback without recording authentication data. A marker-aware hardware retest through the Omarchy menu remains pending.
Related history appears in #3185, #6850, and #141.
View raw text
### System details Omarchy 4.0.1 Quattro, Linux 7.1.9, encrypted Btrfs root using Omarchy's stock `cryptdevice=` initramfs flow, with hibernate enabled through Omarchy Setup. ### Problem Hibernate resume can require two authentication prompts on a stock encrypted installation. The initramfs LUKS prompt decrypts the root device and restores the hibernation image, then the restored native Omarchy session lock asks for the account password again. This happens because `omarchy-system-sleep-monitor` receives logind's generic `PrepareForSleep(true)` signal for both suspend and hibernate and normally invokes `omarchy-system-sleep-lock`. Normal reboot has only the LUKS prompt because there is no saved desktop session or session lock to restore. ### Expected behavior For Omarchy's stock interactive LUKS hibernate path, boot decryption should be the one authentication step. Unencrypted roots, keyfile or automatic unlock, unknown or custom encryption paths, suspend, and direct or unmarked sleep requests must retain the native session lock. ### Current finding The latest double-authentication trace proves that the sleep monitor saw no live hibernate marker and therefore locked before S4. The old wrapper did not log whether it was bypassed or fell back, so the missing marker's historical cause cannot be reconstructed. Current encrypted-root detection and advisory marker locking pass, and PR #8910 now logs every marker decision and fallback without recording authentication data. A marker-aware hardware retest through the Omarchy menu remains pending. Related history appears in #3185, #6850, and #141.
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
- Fixed bypr/8910· confirmed
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.
- Decided by agents · verified: in the audited area (lock)
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.