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.
Full-disk install: password set under a non-US keyboard layout can be untypeable at the LUKS boot prompt
Reported by notwitcheer · filed Aug 25, 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
Repro (hit on real hardware — Dell Inspiron 14 5435, current ISO, 2026-08-25)
- AZERTY laptop; select the French keyboard layout in the installer
- choose full-disk install; set a password containing digits (on AZERTY, digits are the shifted top row)
- install completes; reboot
- at the LUKS unlock prompt the password is rejected on every attempt
What appears to happen
The installer honors the selected layout while the password is set, but the early-boot LUKS prompt reads US QWERTY (the chosen keymap doesn't reach the initramfs). A digits-only password enrolled under French AZERTY becomes untypeable: shifted-row digits don't exist under the boot prompt's map, and unshifted keys produce different characters than were enrolled. QWERTY-translation attempts at the prompt (unshifted digits, a/q z/w m swaps) also failed, consistent with the enrolled bytes being the layout-correct characters.
Impact
Locked out of a fresh install, no recovery except reinstalling. A first-time user experiences this as “Omarchy won't take my password” with nothing pointing at the cause. AZERTY (France/Belgium), QWERTZ (DACH), and other remapped layouts are all exposed — and it only bites people who did the security-conscious thing and put digits in their passphrase.
Workaround that got us through
Reinstall with a passphrase using only layout-stable keys (lowercase letters, avoiding a/q/z/w/m, no digits or symbols).
Possible directions
- propagate the installer's selected layout into the initramfs so the LUKS prompt matches enrollment
- or warn at password-set time when the passphrase contains characters that move across layouts
- or at minimum a note in the manual for non-US layouts
Happy to retest any fix on the same hardware.
View raw text
### Repro (hit on real hardware — Dell Inspiron 14 5435, current ISO, 2026-08-25) 1. AZERTY laptop; select the French keyboard layout in the installer 2. choose full-disk install; set a password containing digits (on AZERTY, digits are the *shifted* top row) 3. install completes; reboot 4. at the LUKS unlock prompt the password is rejected on every attempt ### What appears to happen The installer honors the selected layout while the password is set, but the early-boot LUKS prompt reads US QWERTY (the chosen keymap doesn't reach the initramfs). A digits-only password enrolled under French AZERTY becomes untypeable: shifted-row digits don't exist under the boot prompt's map, and unshifted keys produce different characters than were enrolled. QWERTY-translation attempts at the prompt (unshifted digits, a/q z/w m swaps) also failed, consistent with the enrolled bytes being the layout-correct characters. ### Impact Locked out of a fresh install, no recovery except reinstalling. A first-time user experiences this as “Omarchy won't take my password” with nothing pointing at the cause. AZERTY (France/Belgium), QWERTZ (DACH), and other remapped layouts are all exposed — and it only bites people who did the security-conscious thing and put digits in their passphrase. ### Workaround that got us through Reinstall with a passphrase using only layout-stable keys (lowercase letters, avoiding a/q/z/w/m, no digits or symbols). ### Possible directions - propagate the installer's selected layout into the initramfs so the LUKS prompt matches enrollment - or warn at password-set time when the passphrase contains characters that move across layouts - or at minimum a note in the manual for non-US layouts Happy to retest any fix on the same hardware.
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 08:44 UTC