keyboard layout different changes during installation set-up and boot for de-encrypting unencrypting hard drive

[H]

Setting up Lubuntu 19.04 during install, I choose an alternate UK layout that is not QWERTY (in this case Colemak UK). Encrypting the volume I enter a password. I cannot see the password entered as it is all asterixed out. I also enter a user account password.

After install in boot, the password does not work, for unencrypting the volume. I am not told it does not work either - I simply am directed to a terminal like grub command screen.

What seems to happen is at the de-encrypt passphrase screen, the keyboard layout is in QWERTY (without indicating). So if i type the password I typed during install (in the colemak layout), but now at boot, it won't de-encrypt. at boot, if i type the password in the QWERTY layout, the drive unencrypts and allows me to go through to the user log-in page, where the layout is back to Colemak.

Similar issues with Ubuntu mate 18.10 (seems have been totally corrected in Mate 19.04 - though upon reinstall of mate 19.04 I am having similar issues). There during set up: the password that was typed, during set-up, even though i selected a colemak keyboard, the password would be typed in QWERTY (and there was no way of knowing this because there was no option to see the password). Then at boot, the keyboard layout would be colemak, even for the de-encrypt screen (so a little different to the Lubuntu 19.04 issue).

These issues can be resolved by:

1. being able to see the password typed during set-up.
2. throughout set-up, being able to see the keyboard layout selected.
3. being able to see the keyboard layout selected during boot, being able to change it if required, and possibly being able to see the password typed during unencryption and log-in.
4. If the password entered fails, being told that, instead of being directed to a GRUB terminal screen.

many thanks

[Dan Simmons (kc2bez)]

Thank you for reporting this issue. I can confirm this behavior in a Lubuntu 19.04 virtualbox VM. Calamares version 3.2.4-0ubuntu3

[apt-ghetto (apt-ghetto)]

Thank you for reporting this issue.

I have made a new installation of Lubuntu 19.04 in a virtual machine (Fedora 30 with Gnome Boxes). I choose the automatic installation with full disk encryption in BIOS mode (legacy mode: bootloader in the MBR). Calamares creates one encrypted LUKS container.

After rebooting, Grub asks for the passphrase to unlock the encrypted LUKS container. I don't see any asterisks. How did you install Lubuntu 19.04?

Grub uses by default the American keyboard layout (it is Grub, that opens the LUKS containter, not the kernel from an unencrypted /boot, like the other flavours).
Let's assume, the passphrase contains a 'z', but with the American keyboard layout, it is a 'y'. After entering the "wrong" passphrase, I was dropped into the Grub rescue shell, which is a bug, in my opinion. At least it should permit, for example, 3 attempts to enter the passphrase before dropping into the Grub rescue shell. The error messages (UUID shortened) are:
error: access denied.
error: no such cryptodisk found.
error: disk `cryptouid/ad25aed...` not found.
Entering rescue mode

Possible workaround/solution: LUKS allows you to define up to 8 different passphrases. Let's assume, the LUKS container is on /dev/sda1. You can check first, how many key slots are free:
sudo cryptsetup luksDump /dev/sda1

There are normally 6 free key slots. Then add a passphrase, which you would receive if you use the American keyboard layout:
sudo cryptsetup luksAddKey /dev/sda1

After rebooting, you can enter the "wrong" passphrase and be able to unlock the LUKS container.

[H (h2x4t)]

"After rebooting, Grub asks for the passphrase to unlock the encrypted LUKS container. I don't see any asterisks. How did you install Lubuntu 19.04?"

I am talking about Asterisks during the install process. There is no way of knowing what you are typing - ie, what layout it is in. Because in some other variants of Ubuntu, on the encryption password page in set up, it reverts back to a qwerty layout.

"Grub uses by default the American keyboard layout (it is Grub, that opens the LUKS containter, not the kernel from an unencrypted /boot, like the other flavours)." - there is no clear way of knowing this at present.

And there is no clear way of realising that your unencryption attempt did not succeed, once you are routed to the grub shell.

[apt-ghetto (apt-ghetto)]

Now I understand, what you mean with the asterisks.
I think, it is normal to hide the passwords. And you have to enter the password twice, to ensure, that there are no typos. (And from a security point of view, it would be even better not to show the asterisks)
During the installation, it uses the keyboard layout, which you have selected. (Unless there is another bug.)

The problem is, that Grub does not have the information about the keyboard layout, when it attempts to open the LUKS container (because these informations are inside the LUKS container). It uses the American keyboard layout as default.
The other flavours don't have the /boot directory in an encrypted partition. So Grub loads the kernel (or a part of it), and the kernel then opens the LUKS container.

I would say, that dropping to a Grub rescue shell when entering the wrong password is a bug, that should be solved.
And there is a request to improve the Calamares UI to provide a clear information/message/warning, that Grub is using the American keyboard layout for unlocking the LUKS container.
I am not sure, if it would be possible, to change the keyboard layout of Grub. The packages of Grub are in main, and are not maintained by the team of Lubuntu.

[H (h2x4t)]

"During the installation, it uses the keyboard layout, which you have selected. (Unless there is another bug.)" - with ubuntu mate there does seem to be an issue because even if i select a non-qwerty layout the password that gets typed in the set up page in asteriks is for some reason, in QWERTY, and there is no way of knowing this (until after installation and trying different combinations at boot). Therefore I suggest the ability to show the password entered, during set-up, should one wish, so they can see what has been typed.

with lubuntu, there does not seem to be an issue here, however the ability to see the password would clear confusion. (someone may come accross this problem in another variant of ubuntu and assume lubuntu is the same)

And yes, showing the keyboard layout during the de-encryption boot page would be helpful - or at least a NOTICE during set up, that the keyboard layout for unencryption, after installation, will be qwerty - this is something in the domain of lubuntu.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

The reason this works in MATE (and really everywhere that's not Lubuntu) is because they don't actually have a fully encrypted system. They're using LVM to do the decryption after GRUB boots, i.e. /boot is not encrypted. Calamares and how we have it set up needs to have LUKS decrypted before getting GRUB going, essentially, because /boot is encrypted. From a security standpoint, this is better. From a user experience standpoint, it's a little unfortunate.

Without having some fancy GRUB images that would affect the entirety of the Ubuntu landscape (and perhaps conflict with other design goals), there's not clearly a good solution to this. Perhaps maybe having LUKS be a little more verbose? I'm not sure Calamares can fix this, though I have a related upstream bug linked.

[Leó Kolbeinsson (leok)]

I can confirm that this is still occurring in Focal 20.04.

[Leó Kolbeinsson (leok)]

I can confirm that this is still occurring in Lubuntu Hirsute 21.04 tested daily iso 20210416
at install entered passphrase with non-English keyboard and on reboot unable to decode as Icelandic characters were in the passphrase.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1827501

[Paddy Launch (p-l)]

I have installed 22.04. LTS and have the same Problem. Very sad that disk encryption in not proberly supported.