### System details

- Omarchy 4.0.4, Arch rolling, LUKS full-disk encryption, Limine + UKI + Plymouth prompt
- Kernel: `7.2.8-arch1-2` and `linux-omarchy 7.2.5-3-omarchy`
- `/etc/vconsole.conf`: `KEYMAP=ru`, `XKBLAYOUT=ru,us`, `XKBMODEL=pc105`
- Upgrade that broke it (2026-10-03): `mkinitcpio 42-1 -> 42.2-1`, `plymouth 26.134.222-2 -> -3`, `linux 7.2.7.arch1-1 -> 7.2.8.arch1-2`, `limine 12.9.0 -> 12.9.1`
- A Snapper snapshot taken 3 minutes before the upgrade still boots fine; the rebuilt initramfs does not accept the passphrase

### What's wrong?

After `mkinitcpio 42-1 -> 42.2-1` the LUKS prompt silently switched to the Russian XKB layout. The passphrase is Latin, so every attempt is rejected — the user is locked out of an otherwise healthy install with no error pointing at the cause.

`mkinitcpio 42.2-1` added an unconditional copy of `/etc/vconsole.conf` to `install/plymouth`:

```sh
# copy vconsole settings for keyboard mapping
if [[ -s /etc/vconsole.conf ]]; then
  add_file /etc/vconsole.conf
fi
```

That block does not exist in 42-1. Plymouth (`libply-splash-core.so.5`, `parse_vconsole_conf`) reads the bundled file and applies `XKBLAYOUT` to its own LUKS input, so `ru,us` is now active at the prompt.

### Evidence

Both UKIs were rebuilt from the same configs; `cmdline`, hook list and module set are identical (`encrypt`, `plymouth`, `keymap` hooks unchanged between mkinitcpio 42-1 and 42.2-1).

| initramfs | `mkinitcpio` | `etc/vconsole.conf` inside | boots |
| --- | --- | --- | --- |
| 7.2.7 (snapshot, built 42-1) | 42-1 | **absent** | passphrase accepted |
| 7.2.5-omarchy + 7.2.8 (rebuilt 42.2-1) | 42.2-1 | **present** | passphrase rejected |

`sha256sum` of `keymap.bin` is `a6a871ff04f875ff` in *both* images (3335 bytes, built from `KEYMAP=ru` at image build time by `install/keymap`), so the kernel console keymap did not change — the regression is solely the bundled `vconsole.conf` reaching Plymouth's XKB path.

### The existing guard does not cover this

`/etc/mkinitcpio.conf.d/omarchy_hooks.conf` already refuses to bundle a non-Latin layout:

```sh
# Bundle vconsole.conf so Plymouth uses the configured keyboard layout at the
# LUKS prompt, but only when that layout types Latin letters. Passphrases are
# Latin characters, so bundling a Hebrew/Greek/Cyrillic/Arabic layout would
# make the correct passphrase untypeable and lock the user out.
if [[ -f /etc/vconsole.conf ]]; then
  case $(. /etc/vconsole.conf && echo "${XKBLAYOUT%%,*}") in
    af | am | ... | ru | ... | ua) ;;
    *) FILES+=(/etc/vconsole.conf) ;;
  esac
fi
```

It works by *adding* to `FILES`. mkinitcpio 42.2's plymouth hook calls `add_file /etc/vconsole.conf` directly, which ignores `FILES`, so the guard is bypassed and the file lands in the image anyway.

### Suggested fix

Any of:

1. Mirror the guard inside the plymouth hook path Omarchy controls (skip `add_file` when `${XKBLAYOUT%%,*}` is in the non-Latin list), or ship a drop-in that overrides `install/plymouth`.
2. Report upstream to mkinitcpio — `add_file` of `/etc/vconsole.conf` should at least be consistent with a documented guard, and bundling `ru`/`he`/`el`/`ar` makes the correct passphrase untypeable.
3. Note that #12896 and #8196 move the opposite direction (ensure `XKBLAYOUT` *is* present so Plymouth honours a Latin layout). This report is the flip side of the same knob: when the layout is non-Latin, presence of the file is what locks the user out.

### Workaround applied locally

Patched `/usr/lib/initcpio/install/plymouth` to copy `/etc/vconsole.conf` only when the first `XKBLAYOUT` is Latin (same list as `omarchy_hooks.conf`), then rebuilt the UKIs. `etc/vconsole.conf` is gone from both images and the hashes in `limine.conf` were regenerated.

The patch is a local file edit and is reverted by the next `mkinitcpio` package update.

### Related

- #8196 — same knob, other direction (layout not reaching initramfs)
- #6072 — Plymouth 24->26 making the prompt fall back to QWERTY, closed in 3.8.3
- #9828 — rollbacks re-exposing a QWERTY prompt
- #12896 — PR that persists `XKBLAYOUT`