At boot, grub, when decrypting master key, my custom keymap, or dvorak for that matter, does not load.

So my problem is that at every boot, I am asked to decrypt my disk as I have encrypted it and that for some reason, it does not load my custom keymap, nor dvorak on which it is based on.

$ localectl status

   System Locale: LANG=fr_FR.UTF-8
       VC Keymap: yr
      X11 Layout: yr
       X11 Model: tm2030USK

Changing to dvorak does not change anything.

$ inxi -Fxxxza --no-host

System:    Kernel: 4.19.81-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.19-x86_64 
           root=UUID=3d1ec5b7-03a7-4be0-bd24-fabc673c2ae5 rw quiet 
           Desktop: Xfce 4.14.1 tk: Gtk 3.24.12 info: xfce4-panel wm: xfwm4 dm: LightDM 1.30.0 
           Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: ASRock model: J4105-ITX serial: <filter> UEFI: American Megatrends 
           v: P1.00 date: 01/03/2018 
CPU:       Topology: Quad Core model: Intel Celeron J4105 bits: 64 type: MCP arch: Goldmont Plus 
           family: 6 model-id: 7A (122) stepping: 1 microcode: 2E L2 cache: 4096 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 11984 
           Speed: 799 MHz min/max: 800/2500 MHz Core speeds (MHz): 1: 799 2: 799 3: 799 4: 799 
           Vulnerabilities: Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Enhanced IBRS, IBPB: conditional, RSB filling 
Graphics:  Device-1: Intel vendor: ASRock driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:3185 
           Display: x11 server: X.Org 1.20.5 driver: intel unloaded: modesetting 
           alternate: fbdev,vesa resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 600 (Geminilake 2x6) v: 4.5 Mesa 19.2.2 
           compat-v: 3.0 direct render: Yes 
Audio:     Device-1: Intel vendor: ASRock driver: snd_hda_intel v: kernel bus ID: 00:0e.0 
           chip ID: 8086:3198 
           Sound Server: ALSA v: k4.19.81-1-MANJARO 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASRock 
           driver: r8168 v: 8.047.04-NAPI port: e000 bus ID: 03:00.0 chip ID: 10ec:8168 
           IF: enp3s0 state: down mac: <filter> 
           Device-2: Realtek RTL8812AU 802.11a/b/g/n/ac 2T2R DB WLAN Adapter type: USB 
           driver: rtl8812au bus ID: 1-3:2 chip ID: 0bda:8812 serial: <filter> 
           IF: wlp0s21f0u3 state: up mac: <filter> 
           IF-ID-1: docker0 state: down mac: <filter> 
Drives:    Local Storage: total: 223.57 GiB used: 149.52 GiB (66.9%) 
           ID-1: /dev/sda vendor: LITE-ON model: PH4-CE240 size: 223.57 GiB block size: 
           physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 1.0 scheme: GPT 
Partition: ID-1: / raw size: 223.27 GiB size: 218.77 GiB (97.98%) used: 149.52 GiB (68.3%) fs: ext4 
           dev: /dev/dm-0 
Sensors:   System Temperatures: cpu: 46.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 192 Uptime: 10m Memory: 7.45 GiB used: 1.73 GiB (23.3%) Init: systemd v: 242 
           Compilers: gcc: 9.2.0 clang: 9.0.0 Shell: bash v: 5.0.11 running in: xfce4-terminal 
           inxi: 3.0.36 

$ journalctl -p3 -b -0

-- Logs begin at Wed 2019-07-17 14:34:41 CEST, end at Sat 2019-11-09 00:08:44 CET. --
nov 08 23:51:30 Pjehrsohmehj systemd-vconsole-setup[344]: /usr/bin/loadkeys failed with exit status 1.
nov 08 23:51:44 Pjehrsohmehj systemd-vconsole-setup[781]: /usr/bin/loadkeys failed with exit status 1.
nov 08 23:53:20 Pjehrsohmehj lightdm[860]: gkr-pam: unable to locate daemon control file

$ cat /boot/grub/grub.cfg | grep keymap

keymap /boot/grub/yr.gkb

$ ls -lha /boot/grub

total 48K
drwxr-xr-x 5 root root 4,0K  5 nov 20:16 .
drwxr-xr-x 5 root root 4,0K  5 nov 20:13 ..
-rw------- 1 root root 8,4K  5 nov 20:16 grub.cfg
-rw-r--r-- 1 root root 2,6K 21 jul 10:52 yr.gkb

If you're talking about the prompt appearing before the grub list, there's no way to set another keymap there.

Why not?

I don't know if it will work but you could try moving the mkinitcpio keyboard hook to appear before autodetect and rebuild your initramfs.

Hm, I have searched and it looks like there are solutions:

Try to find out if that works.

Alright, I'll try

$ cat /etc/mkinitcpio.conf | grep HOOKS=\"

-- HOOKS="base udev autodetect modconf block keyboard keymap  encrypt filesystems"
++ HOOKS="base udev keyboard keymap autodetect modconf block encrypt filesystems"

$ sudo mkinitcpio -P
$ sudo reboot

Wish me luck..


That didn't work. I will try out the ubuntu second method. (00_header)


That didn't work either. One big difference though is this:

$ grep GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=c101d989-4af4-42f3-9de1-a02acbf6d348:luks-c101d989-4af4-42f3-9de1-a02acbf6d348 root=/dev/mapper/luks-c101d989-4af4-42f3-9de1-a02acbf6d348 resume=/dev/mapper/luks-c101d989-4af4-42f3-9de1-a02acbf6d348"

Try that Gentoo solution. It's more detailed and up-to-date. Just pay attention to what you're doing.

Done that, but it doesn't work.
I see that I'm having the same issue as below which never got solved:

I'm not an expert on this. What I'd do if I were in your situation is simply add another passphrase consisting of letters which have the same position both on English and French keyboard. I mean if you have "AZERTY" don't use A, Z, Q and W and so on.
Or don't use full-disk encryption, it is actually not that fun to wait while grub decrypts your disk.

1 Like

I will take that advice as a grave insult on par with
"switch to windows" written to every person that comes to this forum with an issue.

I come to this forum to see problems solved, not how to "avoid" them.

Oh, it's not an advice, it's a description of my hypothetical steps to work around this trouble.
It's not an issue to me since I have QWERTY keyboard and don't use Grub's way to decrypt and boot. I prefer direct UEFI boot instead.

PS: don't know what you mean by saying "grave insult", looks like you are at least disappointed. Well, if you like to fight windmills, go ahead, I'm not going to stop you!

I think the solution lies in here:

This looks very risky tough and I do want to take the plunge unless I know for sure that everything has been set up correctly.

Following the instructions I have created memdisk is of dvorak, bepo and yr are just standing there doing nothing.

$ ls -lha /boot/grub/layouts/

total 32K
drwxr-xr-x 2 root root 4,0K 11 nov 07:48 .
drwxr-xr-x 6 root root 4,0K 11 nov 06:58 ..
-rw-r--r-- 1 root root 2,6K  9 nov 11:19 bepo.gkb
-rw-r--r-- 1 root root 2,6K  9 nov 09:38 dvorak.gkb
-rw-r--r-- 1 root root  10K 11 nov 07:48 memdisk.tar
-rw-r--r-- 1 root root 2,6K  9 nov 09:40 yr.gkb

$ cat /boot/grub/early-grub.cfg


terminal_input at_keyboard
keymap /dvorak.gkb

cryptomount -u c101d9894af442f39de1a02acbf6d348
set root='cryptouuid/c101d9894af442f39de1a02acbf6d348'
set prefix=($root)/grub

configfile grub.cfg

The next step is where my doubts are setting in.
How do I list all the modules? Is it like this:

$ grep insmod grub.cfg

insmod part_gpt
insmod part_msdos
    insmod all_video
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
  insmod gfxterm
  insmod terminal
  insmod keylayouts
  insmod at_keyboard
  insmod gettext
insmod part_gpt
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod ext2
insmod gfxmenu
insmod png
	insmod gzio
	insmod part_gpt
	insmod cryptodisk
	insmod luks
	insmod gcry_rijndael
	insmod gcry_rijndael
	insmod gcry_sha256
	insmod ext2
		insmod gzio
		insmod part_gpt
		insmod cryptodisk
		insmod luks
		insmod gcry_rijndael
		insmod gcry_rijndael
		insmod gcry_sha256
		insmod ext2
		insmod gzio
		insmod part_gpt
		insmod cryptodisk
		insmod luks
		insmod gcry_rijndael
		insmod gcry_rijndael
		insmod gcry_sha256
		insmod ext2

And get all the unique ones?
How do I know if I use BIOS and not EFI?
If I do use BIOS, does anything need to be changed?
How do I place the generated EFI core image in my EFI partition and enable it with efibootmgr?

Are you really? Are you tokin to me?? :angry:

Grub is not a dog that needs to be trained to follow human commands AFAIK. It's a utility, a bunch of code lines written by a (only) human. If that conforms an insult to you, we have to investigate this problem... :man_health_worker:

Here's what grub is capable of:

17.4 Input terminal

Firmware console on BIOS, IEEE1275 and ARC doesn’t allow you to enter non-ASCII characters. EFI specification allows for such but author is unaware of any actual implementations. Serial input is currently limited for latin1 (unlikely to change). Own keyboard implementations (at_keyboard and usb_keyboard) supports any key but work on one-char-per-keystroke. So no dead keys or advanced input method. Also there is no keymap change hotkey. In practice it makes difficult to enter any text using non-Latin alphabet. Moreover all current input consumers are limited to ASCII.

Please, give some attention to the bold text and come back with any questions (and a better mood).

I'm not talking you down or grub.
I talk down the
"Learn to live with your defects"
or "buy from the monopolists" attitude.
That's defeatist and humiliating

And I will not, be, humiliated!

I don't find the "Learn to live with your defects" quote humiliating at all, by experience.
If some terrible accident makes me lose a leg, I will live!
I don't imagine you may have another option... Sorry...

If it's solvable without having to code, then I want it solved.

ASCII I can live with.
That's too bad that GRUB has not fixed that issue.
I was already aware of that and accepted that it would be dvorak only.
I could perhaps even use the yr layout and wait until it does get accepted.
Yr is only a dvorak+ layout (lots of Alt Gr+ c = ç stuff).
My current password still consists of normal numbers and letters, so that's no problem.

It's the dvorak on early-grub that I'm now trying to get.
That seems doable from what I read on the archlinux wiki.

I've done this to the best of my knowledge.

$ grub-mkimage -c early-grub.cfg -o grubx64.efi -O x86_64-efi -m /boot/grub/layouts/memdisk.tar part_gpt part_msdos all_video efi_gop efi_uga video_bochs video_cirrus cryptodisk luks gcry_rijndael gcry_sha256 ext2 gfxterm terminal keylayouts at_keyboard gettext png gzio memdisk tar configfile
$ mv /boot/efi/EFI/grubx64.efi /boot/efi/EFI/grubx64.efi.old
$ mv grubx64.efi /boot/efi/EFI/grubx64.efi

And I'm ready to take the plunge

If I were you, I would have a different approach. Proper Keyboard Layouts in early grub are basicaly when changing text input frequently, or mostly dynamically. Passwords are commonly not changed that frequently...

  • Boot to grub2 menu.
  • Press C to get to grub prompt.
  • Press my keyboard keys (from left to right and top to bottom) and copy down the output per key.
  • Find a combination for password that fits the available key options. Use this combination (reversed?) for changing current(?) master key password of Xorg layout. (I hope you know what I try to say...)

Anyway, a password is for narrowing the possibility for a foreign hacker to guess it, no matter the keycodes, but the possible combinations for brute force guessing. :man_shrugging:. If you think about it, a natural language password is supposed to be easier to find/guess, when using social engineering techniques.

An OS, or a bootloader for that matter, should not be a minefield where one avoids problems.
If early grub can support qwerty, then it should be able to support dvorak as well.

The whole premise of Linux or at least GNU/Linux is supposed to be 'free as in freedom'.


I took the plunge by the way.
The new grubx64.efi loaded, but the keyboard stopped working altogether.

:rofl: you have no idea what you're talking about.
Have you ever created even half a program in C for Linux?
Being rude and ignorant makes you famous, but not necessarily smarter.
Live your dream! :sweat_smile:

Ye..Oh wait..for Linux, the kernel (or an OS I assume, not an app).
No, I haven't.

I'm talking about Free as in Freedom, the dream that Richard Stallman has been crusading for all his life. He is the founder of GNU.
And it's not because that statement comes from a high authority that I quote that I profess "counters your statement",
but it's because it's the very core principle of what GNU and by extension Linux has been founded on.

Forum kindly sponsored by