Boot keymap changed to US (?) → password error, following Stable Update 2026-06-26

Support System Updates
1

boot keyboardmapping changed to US (?) → password error on boot

I get a password error when decrypting my luks encrypted partition.
I have a german keyboard.
I can only start when I type in the ‘&’ from the US keyboard position.

My keyboard configuration is

localectl
System Locale: LANG=de_DE.UTF-8
    VC Keymap: de
   X11 Layout: de
    X11 Model: pc105
  X11 Options: terminate:ctrl_alt_bksp

What changed with the update is /etc/mkinitcpio.conf

# before update - now locks the system, chroot-fun ...
#   HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck)
# after the update
#HOOKS=(base udev autodetect microcode kms modconf block keyboard keymap consolefont plymouth encrypt filesystems)
# my *futile* attempt to get the correct keyboard layout (moved block, left out keymap)
HOOKS=(base udev autodetect microcode kms modconf keyboard consolefont plymouth encrypt block filesystems)

Any ideas to enable my german keyboard layout for disk decryption at boot?
Maybe keymap is important but gets ignored?

[Stable Update] 2026-06-26 - Kernels, Systemd, PipeWire, NVIDIA, KDE, LibreOffice
LUKS unlock uses wrong keyboard layout
2

keymap needs to be in your hooks, before encrypt:

Adds the specified console keymap(s) from /etc/vconsole.conf to the initramfs. If you use system encryption, especially full-disk encryption, make sure you add it before the encrypt hook.

Here’s what mine looks like::

cat /etc/vconsole.conf                                                                                                                                        
KEYMAP=de
FONT=lat2-16
FONT_MAP=8859-2

The update might have added a /etc/mkinitcpio.conf.pacnew file, but it doesn’t modify your running version. At least that’s how it was for me.

EDIT: Don’t forget to sudo mkinitcpio -P !

3

Ok turns out my issue is that as well. Both mkinitcpio.conf and grub are still as I configured them on initial setup, the busybox way.
Tried using US layout, and my pw got accepted. Was just too tired to pick up on the subtle clues (the layout icon looks off because theres no countrycode next to it).

Can confirm that’s not the issue. Here’s my hooks that worked before and don’t after the update:
HOOKS=(base udev autodetect kms modconf block keyboard keymap consolefont plymouth encrypt filesystems)
/etc/vconsole.conf is simply KEYMAP=de
So appreciate any further clues.

[Stable Update] 2026-06-26 - Kernels, Systemd, PipeWire, NVIDIA, KDE, LibreOffice
4

Same here, using HOOKS=(base udev ... keymap ...) but keymap defaults to US when unlocking during early boot.

This seems to be a Plymouth issue though, not an initcpio issue per se. When not using Plymouth (plymouth ask-for-password to be precise, see /usr/lib/initcpio/hooks/encrypt), the keymap configured via /etc/vconsole.conf is applied correctly.

Could be this:

Using unencrypted root - unlocking encrypted /home fails
5

Move the keyboard and keymap hooks closer to the start of the HOOKS array, so that they are located in front of the autodetect hook. Then, rebuild your initramfs.

1 Like
7

Saw an update for manjaro plymouth theme, applied it, still only US layout.

Then moved both before autodetect, ran mkinitcpio -P and update-grub, still only US layout.

Removed plymouth entirely and rebuilt, got greeted with basic text interface, but configured keyboard layout works again!

So yes, definitely plymouth, sadly not fixed by latest plymouth theme update.

Also, unrelated: Getting a very reliable code-oss crash when closing windows with unsaved files. So likely on popup.
And half the time (2 out of 4) it took out kwin with it. Looks like this:

[Jun28 16:39] traps: code-oss[24723] general protection fault ip:5584be65dabb sp:7ffe8ac468f0 error:0 in electron[ba34abb,5584b4620000+a5f6000]
[  +4,218990] kwin_wayland[2020]: segfault at 0 ip 0000000000000000 sp 00007ffecd3aa378 error 14 likely on CPU 2 (core 1, socket 0)
[  +0,000009] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
1 Like
8

Unlikely to make any difference, see the links I posted. Also, as stated, the keymap is applied correctly within the initramfs, but gets ignored by Plymouth (which is what usually prompts for passphrases).

That matches my findings. Thus, the options/workarounds currently are:

@Aragorn Would you mind splitting this into its own topic, starting with the initial post?

Mod edit: Consecutive posts merged.

4 Likes
9

Topic split as per request (I meant to do this earlier). :wink:

2 Likes
10

@fonic Thanks! That helped.
I deleted plymouth from my HOOKS line.

2 Likes
Using unencrypted root - unlocking encrypted /home fails
11

Thanks. A couple of related posts by @Minsker got omitted though, if you’d like to move those over as well.

1 Like
12

Done. I’d held back on those but since one has since been edited, both now seem to fit better here. Naturally, we try to avoid breaking thread continuity.¹

Thanks for the heads-up. :+1:

¹ Where there still is any, of course. :stuck_out_tongue:

1 Like
13

It would seem a patch has now been devised to fix this issue, but it’ll likely take some time until it gets adopted by the package maintainers.

https://gitlab.freedesktop.org/plymouth/plymouth/-/work_items/337#note_3555496

14

I’ve applied the potential fix with plymouth 26.134.222-3 in the Manjaro unstable & testing branches.

3 Likes