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.
Plymouth LUKS unlock prompt uses QWERTY despite French keymap present in UKI
Reported by lionel-arnaud · filed Jun 11, 2026Closed upstream on 2026-07-12 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
System details
Omarchy 3.8.2 on ThinkPad T14 Gen 3, Linux 7.0.11-arch1-1, Hyprland 0.55.3, Limine + UKI + mkinitcpio + Plymouth LUKS prompt, French/AZERTY keymap configured.
What's wrong?
Hi Omarchy maintainers,
I ran into what looks like a boot-time keyboard layout bug on an encrypted Omarchy install.
My system is configured to use a French keyboard layout, and everything works correctly once Omarchy starts. In Hyprland, my keyboard is French as expected.
The problem happens before that, at the disk decryption prompt. Every time I reboot, the keyboard layout at the LUKS unlock screen behaves like English/QWERTY instead of French/AZERTY. That means I can’t reliably type my disk password unless I mentally translate the keys. Once the system finishes booting, the layout switches back to French.
I asked Codex to investigate, and here is its diagnosis.
Codex found that the installed system does seem to be configured correctly:
/etc/vconsole.confcontainsKEYMAP=fr.localectl statusreportsVC Keymap: fr./etc/mkinitcpio.confcontainskeyboard keymap consolefontbeforeencrypt.- The active UKI at
/boot/EFI/Linux/omarchy_linux.eficontainskeymap.binandkeymap.utf8. - The embedded
keymap.binwas compared againstloadkeys fr -b, and the SHA256 hashes matched exactly.
So the French console keymap appears to be present in the UKI.
However, Codex found that the effective mkinitcpio config is overridden by:
/etc/mkinitcpio.conf.d/omarchy_hooks.confThat file contains:
HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs)
The important detail is that plymouth comes before keymap.
Codex’s understanding is that the graphical LUKS prompt is handled by Plymouth, and Plymouth is being started before the French console keymap is loaded. Rebuilding the UKI does not help because it rebuilds the same hook order.
A possible safer hook order might be:
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont plymouth block encrypt filesystems fsck btrfs-overlayfs)
Or, more generally, ensuring that keyboard/keymap setup happens before Plymouth handles the password prompt.
Could you confirm whether Omarchy’s default mkinitcpio hook order should place plymouth before keymap? If this ordering is intentional, what is the supported way to make non-US keyboard layouts work reliably at the Plymouth LUKS prompt?
View raw text
### System details Omarchy 3.8.2 on ThinkPad T14 Gen 3, Linux 7.0.11-arch1-1, Hyprland 0.55.3, Limine + UKI + mkinitcpio + Plymouth LUKS prompt, French/AZERTY keymap configured. ### What's wrong? Hi Omarchy maintainers, I ran into what looks like a boot-time keyboard layout bug on an encrypted Omarchy install. My system is configured to use a French keyboard layout, and everything works correctly once Omarchy starts. In Hyprland, my keyboard is French as expected. The problem happens before that, at the disk decryption prompt. Every time I reboot, the keyboard layout at the LUKS unlock screen behaves like English/QWERTY instead of French/AZERTY. That means I can’t reliably type my disk password unless I mentally translate the keys. Once the system finishes booting, the layout switches back to French. I asked Codex to investigate, and here is its diagnosis. Codex found that the installed system does seem to be configured correctly: - `/etc/vconsole.conf` contains `KEYMAP=fr`. - `localectl status` reports `VC Keymap: fr`. - `/etc/mkinitcpio.conf` contains `keyboard keymap consolefont` before `encrypt`. - The active UKI at `/boot/EFI/Linux/omarchy_linux.efi` contains `keymap.bin` and `keymap.utf8`. - The embedded `keymap.bin` was compared against `loadkeys fr -b`, and the SHA256 hashes matched exactly. So the French console keymap appears to be present in the UKI. However, Codex found that the effective mkinitcpio config is overridden by: ```bash /etc/mkinitcpio.conf.d/omarchy_hooks.conf ``` That file contains: HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs) The important detail is that plymouth comes before keymap. Codex’s understanding is that the graphical LUKS prompt is handled by Plymouth, and Plymouth is being started before the French console keymap is loaded. Rebuilding the UKI does not help because it rebuilds the same hook order. A possible safer hook order might be: HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont plymouth block encrypt filesystems fsck btrfs-overlayfs) Or, more generally, ensuring that keyboard/keymap setup happens before Plymouth handles the password prompt. Could you confirm whether Omarchy’s default mkinitcpio hook order should place plymouth before keymap? If this ordering is intentional, what is the supported way to make non-US keyboard layouts work reliably at the Plymouth LUKS prompt?
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.