Alternate keyboard layouts need to be loaded prior to disk decryption if encryption enabled. During installation (12.1-RELEASE) I select the us.dvorak.kbd layout, which is enabled in the rc.conf (keymap="us.dvorak.kbd") as expected. I also enabled disk encryption, which unlocks with a passphrase at boot. The problem is each time the machine bots the kernel reverts the keymap and I am required to unlock disk encryption using the US qwerty layout. ----- The only solution I found was to build a custom kernel and define the following: options ATKBD_DFLT_KEYMAP makeoptions ATKBD_DFLT_KEYMAP=us.dvorak
Another method to fix this layout limitation for installation done with bsdinstall: If user selects another layout than QWERTY (BIOS default), instruct bsdinstall to switch to use QWERTY layout just during the GELI password input screen. => The user will enter twice its password, but in fact because the layout was not the user defined but QWERTY, the real entered password will be the one corresponding the QWERTY layout. So during the bootloader GELI password phase (that will use BIOS default QWERTY), the sequence of keys entered by the user will still match the 'QWERTY' password used during bsdinstall.
Update: I just build a kernel with these options on 13-CURRENT: device atkbd options ATKBD_DFLT_KEYMAP makeoptions ATKBD_DFLT_KEYMAP=us.dvorak.kbd These instructions don't seem to have any affect.
(In reply to Olivier Cochard from comment #1) Is this method will work for every type of keyboard? Especially laptop and password with special character? Just asking.
(In reply to Loïc Bartoletti from comment #3) > Is this method will work for every type of keyboard? Especially laptop and password with special character? Just asking. I believe it should. It is possible that this scheme could result in weaker passwords (e.g. a keypress used in the password could from a character to a control key); I'm not sure how likely that is in practice. This wouldn't affect us.dvorak.kbd at least, I believe.
Admittedly I'm less familiar with the FreeBSD kernel but that feels like a workaround... Is there no capability similar to Linux initrd? To bootstrap key modules very early?
(In reply to Christer Edwards from comment #5) Indeed, this approach would be a bit of a workaround. We can and do load modules early, but keyboard maps aren't modules. It would be possible to boot with a md root a la linux initrd and do keymap configuration from there, but is a rather more significant change, and still wouldn't handle the case where we collect the password/phrase from the loader.