LUKS passphrase not accepted at boot

The passphrase is almost never wrong. The keyboard is. The Omarchy unlock prompt runs inside the initramfs, long before Hyprland loads your layout, and once the Plymouth 24 to 26 package update reached 3.8.2 machines in June 2026 it typed US QWERTY no matter what you picked in the installer. If your passphrase contains a character that moves between layouts, the prompt rejects it and tells you nothing useful. Everything below was checked against the 3.8.4 and 4.0.4 source trees.

The fix

1. Get in by typing the passphrase in US QWERTY

Before changing anything, retype the passphrase as if the keycaps were a US keyboard. On AZERTY that means a and q swap, z and w swap, m moves to the right of l, and the digits on the top row are unshifted. On QWERTZ, y and z swap.

In issue #6072, KrissLodBrok reported that typing the passphrase this way unlocked the disk on a French machine whose prompt had reverted to QWERTY. Do this first, because every real repair below needs a booted system.

If you use a Hebrew, Greek, Cyrillic or Arabic layout and the prompt broke after an update, the failure is the mirror image: the prompt started typing your layout, and your passphrase is Latin. Same answer, type it as US QWERTY.

2. Check what the system actually recorded

Once you are in, look at the file the boot image reads:

cat /etc/vconsole.conf

A healthy file has both keys:

KEYMAP=fr
XKBLAYOUT=fr

Issues #7049 and #6878 both report installs where only KEYMAP is present. That is legal, vconsole.conf only guarantees the console keymap, but Omarchy’s Quattro defaults key off XKBLAYOUT, so a missing line silently means us.

3. Set XKBLAYOUT if it is missing

sudo localectl set-x11-keymap fr
cat /etc/vconsole.conf

Substitute your own code (de, no, it, be, se). Confirm the file now carries XKBLAYOUT. If localectl writes it somewhere else on your machine, append the line by hand instead.

4. Rebuild the boot image

On 4.0.x and on 3.8.3 or later:

sudo limine-mkinitcpio

That is the whole fix on a current system. Omarchy ships /etc/mkinitcpio.conf.d/omarchy_hooks.conf, and on 4.0.x that file decides at rebuild time whether to add /etc/vconsole.conf to FILES. It adds it for Latin layouts and skips it for the non-Latin list (ara, bg, gr, il, ru, ua and others), so a Latin passphrase stays typeable.

One catch on machines upgraded from 3.x: if that file was ever edited by hand, pacman leaves the packaged version next to it as omarchy_hooks.conf.pacnew instead of replacing it. Omarchy’s own migration 1786605598.sh notes this, and issue #9828 hit it. Run ls /etc/mkinitcpio.conf.d/ and, if a .pacnew is sitting there, merge it before rebuilding. See pacnew and pacsave files after update.

On 3.8.2 and earlier there is no such logic at all. Either update, or append the line yourself and rebuild. Skip this if your layout is Hebrew, Greek, Cyrillic or Arabic, because bundling one of those is exactly what locked out the reporter of issue #6229:

echo 'FILES+=(/etc/vconsole.conf)' | sudo tee -a /etc/mkinitcpio.conf.d/omarchy_hooks.conf
sudo limine-mkinitcpio

Verify it worked

Check that the rebuilt image carries the file. A commenter on issue #6151 inspected the unified kernel image directly:

sudo lsinitcpio /boot/EFI/Linux/omarchy_linux.efi | grep vconsole

Then reboot and type the passphrase on your own layout. If it unlocks on the first try, you are done. If you want a second check without rebooting, localectl status should report the same VC keymap and X11 layout.

Why it happens

Omarchy boots a unified kernel image through Limine, with Plymouth drawing the unlock prompt. The layout that prompt uses comes from the initramfs, not from your session.

Two separate things broke here. The first was Plymouth. Issues #6072, #6151 and #6165 all land between mid-June and early July 2026, all on Plymouth 26.134.222, and all describe the same regression: the console keymap was present in the boot image, but the graphical prompt ignored it and fell back to QWERTY. Release v3.8.3 on 2026-07-13 fixed it by bundling /etc/vconsole.conf into the initramfs, credited to Zeus-Deus, and v4.0.0 carried the same change forward.

That fix then created its own lockout. elpddev filed issue #6229 three days later: with a Hebrew layout bundled, the prompt mapped letter keys to Hebrew, and a Latin passphrase could no longer be typed at all. Omarchy 4.0.x answers this with the layout filter in omarchy_hooks.conf plus migration 1784476564.sh, which strips the bundling on non-Latin machines and rebuilds the image.

The second problem is the missing XKBLAYOUT, and it is still open. Issue #7049 shows a fresh Quattro install writing only KEYMAP=no-latin1, and #6878 shows a Quattro upgrade in the same state with KEYMAP=fr. It is not every install: a later comment on #7049 shows a 4.0.2 install with Swiss German that did get XKBLAYOUT=ch, so check the file rather than assume. Issue #8196, filed 2026-08-25 and open at the time of writing, is the worst version: a passphrase set under AZERTY during a full-disk install that could not be typed at the boot prompt afterwards, with the reporter saying QWERTY translation did not help either. That one has no confirmed explanation yet, and the reporter reinstalled with a layout-stable passphrase.

If that did not work

You restored a snapshot. Issue #9828 reports that restoring a Snapper snapshot rewinds the root subvolume but not /home, where the migration markers live, so a migration that already fixed your boot image gets undone while still counting as applied. omarchy-migrate will not rerun it. Redo steps 3 and 4 by hand.

The keyboard itself is not alive yet. If you type through a Thunderbolt dock, issue #10453 reports the early thunderbolt module removing the dock’s USB controller before the prompt appears. Bluetooth keyboards are not connected at that point either, per issue #10335. Plug a wired keyboard straight into the machine.

The prompt never appears, or the boot dies right after unlocking. That is a different failure. Issue #6876 reports that omarchy_hooks.conf replaces the whole HOOKS array rather than extending it, so an LVM-on-LUKS root loses the lvm2 hook and never comes up. See kernel panic after update and emergency mode after update.

You cannot get in anywhere. Boot an older entry from the Limine menu, described in the manual chapter on system snapshots. Those entries carry their own older boot image, which is how the reporter of #6229 recovered. Failing that, boot an Arch live USB, unlock with cryptsetup open, mount the @ subvolume, arch-chroot, and repeat steps 3 and 4. Be honest with yourself about the last resort: if the passphrase is rejected from a live USB too, it was never enrolled as the characters you think it was, and a reinstall is the only path left.

Related

• Non-US keyboard layout at LUKS and SDDM
• Layouts and locale
• Login loop or password not accepted at SDDM
• Lock screen will not unlock
• LUKS and UFW defaults
• Rollback with Snapper and Limine