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.
vconsole.conf bundled into initramfs locks out LUKS users with non-Latin keyboard layouts (Hebrew/Greek/Cyrillic)
Reported by elpddev · filed Jul 16, 2026Closed upstream on 2026-07-19 by commit c030337cb66c (closed by dhh). GitHub close reason: completed.
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
What happened
After omarchy update + reboot, the LUKS unlock prompt rejects the correct passphrase with No key available with this passphrase — both at the Plymouth prompt and at the Ctrl+Alt+Esc text view. The system is effectively locked out; only older snapshot boot entries (which carry pre-update initramfs images) still unlock.
Root cause
Migration 1783355853.sh (the fix for #6072 / #6151) adds FILES+=(/etc/vconsole.conf) to /etc/mkinitcpio.conf.d/omarchy_hooks.conf, so Plymouth applies the user's layout at the unlock prompt.
For non-Latin layouts this backfires: my vconsole.conf has KEYMAP=il / XKBLAYOUT=il (Hebrew). With that bundled, plymouth ask-for-password maps letter keys to Hebrew characters — but LUKS passphrases are (necessarily) typed with a Latin mapping, since that's what the prompt used before this change. So the typed passphrase never matches, with no hint of what's wrong.
This affects any layout whose letter keys don't produce Latin characters: Hebrew, Greek, Cyrillic, Arabic, etc. Unlike AZERTY (where the layout is Latin and bundling is correct), these users are locked out of their machines by the migration.
Verified by diffing the pre-/post-migration UKIs: the only behavioral delta is etc/vconsole.conf (added via FILES+= in the embedded buildconfig); cryptsetup/libs identical, and the same passphrase test-unlocks fine from a running system.
Workaround (recovery)
- Boot a snapshot entry from the Limine menu.
- Mount the real root and delete the line:
sudo sed -i '/vconsole.conf/d' /mnt/etc/mkinitcpio.conf.d/omarchy_hooks.conf
3. Rebuild the UKI (mkinitcpio -P → limine-mkinitcpio in chroot), reboot.
Suggested fix
Only bundle /etc/vconsole.conf when the configured layout produces Latin letters — or, for non-Latin layouts, keep the US fallback at the unlock prompt (matching how the passphrase was originally set), e.g. by filtering XKBLAYOUT against a known-Latin list before applying the migration.
Environment
Omarchy 3.8.2 · plymouth 26.134.222-2 · mkinitcpio 41-4 · kernel 7.1.3-arch1-2 · Limine + UKI + LUKS2 · ThinkPad P14s Gen 6 AMD · KEYMAP=il, XKBLAYOUT=il
View raw text
## What happened After `omarchy update` + reboot, the LUKS unlock prompt rejects the correct passphrase with `No key available with this passphrase` — both at the Plymouth prompt and at the Ctrl+Alt+Esc text view. The system is effectively locked out; only older snapshot boot entries (which carry pre-update initramfs images) still unlock. ## Root cause Migration `1783355853.sh` (the fix for #6072 / #6151) adds `FILES+=(/etc/vconsole.conf)` to `/etc/mkinitcpio.conf.d/omarchy_hooks.conf`, so Plymouth applies the user's layout at the unlock prompt. For **non-Latin layouts** this backfires: my `vconsole.conf` has `KEYMAP=il` / `XKBLAYOUT=il` (Hebrew). With that bundled, `plymouth ask-for-password` maps letter keys to Hebrew characters — but LUKS passphrases are (necessarily) typed with a Latin mapping, since that's what the prompt used before this change. So the typed passphrase never matches, with no hint of what's wrong. This affects any layout whose letter keys don't produce Latin characters: Hebrew, Greek, Cyrillic, Arabic, etc. Unlike AZERTY (where the layout *is* Latin and bundling is correct), these users are locked out of their machines by the migration. Verified by diffing the pre-/post-migration UKIs: the only behavioral delta is `etc/vconsole.conf` (added via `FILES+=` in the embedded buildconfig); cryptsetup/libs identical, and the same passphrase test-unlocks fine from a running system. ## Workaround (recovery) 1. Boot a snapshot entry from the Limine menu. 2. Mount the real root and delete the line: `sudo sed -i '/vconsole.conf/d' /mnt/etc/mkinitcpio.conf.d/omarchy_hooks.conf` 3. Rebuild the UKI (`mkinitcpio -P` → `limine-mkinitcpio` in chroot), reboot. ## Suggested fix Only bundle `/etc/vconsole.conf` when the configured layout produces Latin letters — or, for non-Latin layouts, keep the US fallback at the unlock prompt (matching how the passphrase was originally set), e.g. by filtering `XKBLAYOUT` against a known-Latin list before applying the migration. ## Environment Omarchy 3.8.2 · plymouth 26.134.222-2 · mkinitcpio 41-4 · kernel 7.1.3-arch1-2 · Limine + UKI + LUKS2 · ThinkPad P14s Gen 6 AMD · `KEYMAP=il`, `XKBLAYOUT=il`
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.