Dropped the support for non US keyboard layouts for boot encryption

Hello everyone

a few years ago, when you’d set up a boot password and a different Keyboard layout, it would still work.

However apperantly this was removed and now when I encrypt my whole drive GRUB is starting with the US layout, making it literally impossible to enter my password correctly, because the Characters simply aren’t on the US layout.

I’m aware that I could use more simple passwords or only use characters which are on the US layout but both of these approaches don’t tackle the issue, that these workarounds shouldn’t be necessary in the first place.

So my question is: was there a good reason to drop this kind of support? I remember very vividly having Manjaro as my daily driver on my old netbook when they still had 32bit support. And I was able to use the German Keyboard layout for entering the disk password to boot.

The functionality has not changed. For the time I have been using Manjaro (approx. 5y) it has been necessary to specifically include the keyboard hook before autodetect if using encryption and the password includes non-ascii chars with non-us keyboard layouts.

I remember a member using dvorak layout - I don’t think that issue was ever solved.

In one of the articles on encryption - found on Arch wiki - it is mentioned that to be able to use other keyboard layouts for decryption you will need to ensure the layout is available in initramfs. This is done by adding modules to the mkinitcpio.conf and/or rearranging existing modules.

keyboard
Tip: For systems that are booted with different hardware configurations (e.g. laptops with external keyboard vs. internal keyboard or headless systems), it is helpful to place this hook before autodetect in order to always include all keyboard drivers. Otherwise the external keyboard only works in early userspace if it was connected when creating the image. - dm-crypt/System configuration - ArchWiki

Forum Search

Archive Search

1 Like

I think: Using keys from non-US-keyboards in passwords / passphrases is bad practice (I have been hit once)
Be aware that:
If this ever breaks, you will lose access to your system until someone fixes it

I knew this problem in the past. Full encrypt disk is overkill.
In my opinion, the encryption of home partition is sufficient, important drivers do not need to be encrypted.

1 Like

That depends on your standards and requirements.

An unencrypted root may allow for malicios intent by changing system files and thus snoop on decryption password using keylogging.

If you are in a position where you are a person of interest then full disk encryption is prefrerred and even then it could be possible to corrupt the firmware to snoop on security - but yet again it would require your data to be extremely interesting.

It all boils down to your own requirements based on informed decisions based on intelligence to determine the minimum level of security for your usecase.

2 Likes

As mentioned I am aware that there are workarounds. But I honestly think that they shouldn’t be necessary because in older versions of Manjaro it worked fine with just setting up everything in calamares including the layout and you’re good to go because everything is set up.

The real fix would be to reverse the change and use this Splash screen kind of password input and not grub.

Manjaro wants to be an OS for everyone but doing that change as in: using grub and needing to go into some configuration files, isn’t exactly user friendly and quite honestly just unnecessarily frustrating.

The team added a obstacles where there shouldn’t be one and where there wasn’t one.

Here’s btw an album how I set everything up.

As I mentioned earlier - and referred to - it has always been an issue to use non ascii characters for the decryption phrase and it is therefore a general recommendation to avoid characters local to your region as this is the way to avoid issues like the one you are having.

If you refer to the articles and searches I linked to you will find that decryption phrase input using non-ascii chars always presents a challenge.

A challenge easily avoided by following the above mentioned rule - that is really all there is to this.

Manjaro switched from syslinux to grub (late 2017 I think) when i686 was removed upstream and I really don’t know if the bootloader has any correlation to your issue - if it has then you are 4y late.

The selection you can do in the installer bootloader is convenience settings when you boot without network. The choices set the defaults for installer - previous syslinux has these built in grub does not.

The settings you choose here has no bearig for the installed system - only the installer - the installed system is configured using Calamares.

Installed systems always used grub, regardless if the ISO had syslinux or not. I’ve to check if we added those keyboard layout stuff in the past somehow, which got reverted when grub was brought back to a more similar PKGBUILD as upstream Arch ships … however, we always recommended US-Layout passwords.

Yeah that was exactly the last time when I used Manjaro. That was literally a unique selling point for Manjaro because it was, as far as I’m aware, the only Arch distribution which used it and therefore allowed non US passwords as a boot password.

It would be good if the Manjaro team could add a solution to that because it is not clear at all that you need to keep this in mind, you literally need to know this and it is therefore not very user-friendly.
Nowhere in the installation process it is mentioned that non US Passwords need any kind of additional tweaks.

Using a US Layout compatible password would require a password which is less secure and renders the whole procedure almost useless.

@linux-aarhus mentioned a few times now that it is apperantly relatively easy if you know what you need to do. Maybe this is something which could be added into the installation routine of Manjaro?

The final installation has always used grub - so the issue would have been then too - as only the installer booted using syslinux.

The only reason ascii chars is recommended is because when ithe keyboard pukes on you and you don’t have the exact model you are doomed anyway.

The statement about more secure phrases - I really don’t buy it - you can make your passphrase equally secure using the ascii charset.

I find that argument really odd. People who use the US Layout anyways don’t lose anything. They still can setup the US layout and are good to go. From a home user perspective you’re, well, using your own computer. So if your Keyboard decides to “puke on you” thats something the individual user needs to take care of anyways.
Your points are also different issues and not an argument against using syslinux to enable Non-US Layouts for entering a boot password. Most other Distributuions do it that way and it works absolutley fine.

Not when you’re not using the US Layout as a daily driver. Again it is highly unfriendly to users and I really think this needs a change.

Manjaro - enjoy the simplicity

Then please Team: let users enjoy the simplicity, especially in an important topic as the bootpassword. It makes absolutley no sense to restrict that because it might break eventually on individual systems.

Your tagline reference is misplaced - the simplicity is a reference to Manjaro as an Arch based system - not simplicity as a general phrase.

There is no restriction - only those you put on yourself. You can tweak your system to your preference - that’s the whole idea.

When you have special requirements - such as using non ascii characters for your encryption phrase - then you have to adjust the system accordingly - if you don’t know how - you will have to learn.

Such preference is not a task for Manjaro as distribution.

I don’t really feel like discussing different interpretations of the Manjaro statement. If that’s yours I’m good with it. I understand it differently but I’m not willing to add this to the discussion.

I hope that @philm and the team can at least considerate a few things I’m saying here and maybe add syslinux back to get everything more userfriendly.