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.
LUKS password rejected multiple times on boot (ThinkPad T14s Gen 1), works after several attempts
Reported by AllergicCypress · filed Aug 27, 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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Lenovo ThinkPad T14s Gen 1, Omarchy Quattro (omarchy 4.0.0-1)
What's wrong?
Similar to #651 and #4343.
Origin: QuickShell crashed (bar/menu stopped responding, workspace switching broken), but the rest of the desktop remained usable. I shut down cleanly via omarchy shutdown after finishing my work, expecting a normal restart to fix it.
Problem: On next boot, disk decryption password (LUKS) was rejected at the Limine/initramfs prompt, even though the password had not changed and worked normally before.
Diagnosis performed:
- Booted from Omarchy Quattro live USB
- Confirmed LUKS keyslot is healthy via cryptsetup luksDump (single keyslot, no corruption)
- Confirmed the exact same passphrase unlocks successfully via cryptsetup open from the live USB
- Verified /etc/mkinitcpio.conf HOOKS are correct and in proper order (keyboard, keymap before encrypt)
- Verified /boot/limine.conf cmdline and cryptdevice PARTUUID match lsblk/blkid output, no inconsistency
- Regenerated UKI with limine-mkinitcpio (properly, with /boot mounted) — did not fix the issue
- Removed quiet splash from cmdline to rule out Plymouth — password was still rejected multiple times (with explicit "no key available with this passphrase" shown each time) before finally being accepted, with no changes made in between attempts
Hardware checked: Internal PS/2 keyboard (i8042, AT Translated Set 2), detected early and cleanly in kernel log, no timeout/reset errors in journalctl.
This strongly suggests the issue is not password/header corruption (confirmed healthy), not Plymouth, and not USB/keyboard driver timing — but something intermittent in how the initramfs captures/validates passphrase input on repeated early boot attempts.
Has anyone found a root cause or workaround beyond "keep retrying"?
View raw text
### System details Lenovo ThinkPad T14s Gen 1, Omarchy Quattro (omarchy 4.0.0-1) ### What's wrong? Similar to #651 and #4343. **Origin**: QuickShell crashed (bar/menu stopped responding, workspace switching broken), but the rest of the desktop remained usable. I shut down cleanly via `omarchy shutdown` after finishing my work, expecting a normal restart to fix it. **Problem**: On next boot, disk decryption password (LUKS) was rejected at the Limine/initramfs prompt, even though the password had not changed and worked normally before. **Diagnosis performed**: - Booted from Omarchy Quattro live USB - Confirmed LUKS keyslot is healthy via `cryptsetup luksDump` (single keyslot, no corruption) - Confirmed the exact same passphrase unlocks successfully via `cryptsetup open` from the live USB - Verified `/etc/mkinitcpio.conf` HOOKS are correct and in proper order (keyboard, keymap before encrypt) - Verified `/boot/limine.conf` cmdline and cryptdevice PARTUUID match `lsblk`/`blkid` output, no inconsistency - Regenerated UKI with `limine-mkinitcpio` (properly, with /boot mounted) — did not fix the issue - Removed `quiet splash` from cmdline to rule out Plymouth — password was still rejected multiple times (with explicit "no key available with this passphrase" shown each time) before finally being accepted, with no changes made in between attempts **Hardware checked**: Internal PS/2 keyboard (i8042, AT Translated Set 2), detected early and cleanly in kernel log, no timeout/reset errors in journalctl. This strongly suggests the issue is not password/header corruption (confirmed healthy), not Plymouth, and not USB/keyboard driver timing — but something intermittent in how the initramfs captures/validates passphrase input on repeated early boot attempts. Has anyone found a root cause or workaround beyond "keep retrying"?
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.
- Out of scopeDecided by agents · verified · 2026-10-09 09:34 UTC