Why are non-US keyboards not supported while prompting for decryption?

Feedback
1

Context

When using full disk encryption, non-US keyboard layouts are not supported for entering the decryption passphrase.

This issue was already mentioned here, but the discussion was closed without the core issue being addressed. I want to bring the discussion up again, while giving some details that I think were overlooked.

Reason given why this should be acceptable

Reading the previous thread, the main reason given to justify the absence of non-US keyboard layout support, is that using non-ASCII passwords is bad practice.

My take on it

I can see the point being made here, from a user’s point of view: Using only ASCII avoids issues with broken systems. However, from a system point of view, in my opinion, this is not an excuse to justify bugs.

Using the term “bug” here is maybe a bit harsh. It’s more an UX issue, because when setting up the password one keyboard layout is used, and when entering it to unlock the computer, another keyboard layout is used. There should be at least a warning message.

The actual issue that was overlooked

I’m using an ASCII-only password, but I’m still affected by this design choice. The actual issue is not the characters used in the password but the keyboard layout itself. A “Q” on an US keyboard is a “A” on my keyboard. If you want to use characters like @&", and so on, you will have to look on the Internet to find where they are, to be able to log in. And this is after setting up the OS without any kind of warning that would help the user figure out why they can’t log-in.

Reason why this should be unacceptable IMO

Manjaro is user-friendly and suitable for those new to computers. At least, this is what the homepage of Majaro says. I mostly agree with this statement. Manjaro provides a near flawless Linux experience that would not throw off newbies. However, this issue does not reflect that.

Also, this issue discriminates non-US Manjaro users and this is not acceptable.

A last word

I hope that this post doesn’t come off as a rent or flaming to you. I love Manjaro. I have been using it daily for many years now. It’s for this reason that I hope this feedback will reach the Manjaro team and help improve the distribution.

2

This was answered in the very first reply. :yawning_face:

2 Likes
3

Yes, workarounds are still required. It doesn’t work out of the box. I don’t expect this to be fixed soon (even if I would like it to be). However, a warning during the install process would be welcome.

4

This is no workaround, it’s the relevant configuration.

I suppose it is not set by default because boot hooks add steps to the booting sequence, which then takes longer to complete, and is not required for everyone.
Though it may be possible for the installer to add the relevant hook, for instance if the keyboard layout used during installation is not QWERTY. But you shall then submit that to the Calamares developers.

1 Like
5

This is no workaround, it’s the relevant configuration.

Then it’s really bad user experience if by default the keyboard layout that you use to setup the password and to enter it later is not the same. I get that there could be technical limitations, but I’ll repeat myself, at least a warning should be added if the keyboard used during the install process is not QWERTY.

But you shall then submit that to the Calamares developers.

Ubuntu, as well as other distros that use Calamares don’t seem to have this issue.
Also, someone already opened an issue on the Manjaro fork 2 years ago.

1 Like
6

I can somehow understand why most software is US_EN by default, but Manjaro being a German company (AFAIK) should indeed put more efforts in supporting different Layouts by default…
:+1:

2 Likes
7

Embedding a specific type of keyboard in the efi stub is an advanced requirement - and one could ask - if first introduced - where does it end?

…
If you require a special keymap or other complex steps that GRUB is not able to configure automatically
…
Firstly, taking as an example a requirement for the dvorak keymap embedded in early-boot in order to enter a password for an encrypted /boot on a UEFI system:
…
– GRUB/Tips and tricks - ArchWiki

The distro doesn’t add features, and the features it does add I don’t want

Originally posted by Jonathon Fernyhough at Archived Manjaro forum - April 19, 2019dead link

I want Manjaro to add a feature which I want. I can’t do it myself but it’s really important to what I currently think is important so Manjaro should add it.

The developers are lazy because they don’t do what I want them to do, but they still find time to add features which other people ask for. That’s stupid and lazy.

Those features which other people want aren’t what I want, so they are a waste of time and completely bloat.

I hate bloat. Bloat is extra features that I don’t want. Not like the extra features which I do want because they aren’t bloat because I want them.

Why does Manjaro include stuff which I don’t want? Why won’t Manjaro include what I want instead of what other people want?

Why can’t Manjaro be made into what I want, and also what everyone else at the same time wants because they also want what I want (apart from the people who don’t want because they are noob and hate privacy)?

I keep asking for someone else to do something for me over and over and over again and yet they still haven’t done what I want them to. This means Manjaro is terrible and shouldn’t be used by anyone, ever. I never liked Manjaro anyway because it’s made by script kiddies, but I’m doing this because I want Manjaro to be popular because if it did what I wanted then it would be more popular and more people would want to use it because everyone wants the same thing that I want.

It just shows that because you don’t do what I want that you don’t know what you’re doing and I’m never going to recommend Manjaro to anyone.

But if you did do just this one thing which I want then Manjaro would be the best.

2 Likes
8

The point as I understood it was rather that this will bite you without so much as even a small warning anywhere.

The remedy boils down to including the “keymap” or the “sd-vconsole” HOOK and having a valid /etc/vconsole.conf when the initrd is created.

1 Like
9

Embedding a specific type of keyboard in the efi stub is an advanced requirement

Having a functional keyboard when entering a password is not a advanced requirement, it’s a basic one. Most distros don’t have this issue. This is not an issue for people that use a US QWERTY layout, but not the whole world is the US.

I want Manjaro to add a feature which I want. I can’t do it myself but it’s really important to what I currently think is important so Manjaro should add it.

The developers are lazy because they don’t do what I want them to do, but they still find time to add features which other people ask for. That’s stupid and lazy. […]

You are deforming what I said, and yes this is funny, but you are not addressing the core issue. Please, I don’t want this thread to become an Internet argument where everyone thinks that they are right and that will come to nothing productive. We all want the same thing: improving Manjaro. This is a feedback not a feature request: a simple warning during the install process would be fine, I’m not asking to make every keyboard layouts work in the GRUB.

Also, I was respectful in my initial post, so please don’t twist my words to make me say that “the developers are stupid and lazy”. I have a huge respect for the Manjaro team.

10

You will always have a functional keyboard - but adressing a specific keyboard - in this case AZERTY instead of QWERTY where the latter is - I think - more common.

It then becomes an advanced use as it requires a custom build of the efi stub and the loader becomes hardcoded to that layout.

Your reference to Ubuntu may be valid - I don’t know - I have never tested exotic keyboard layouts - they could be providiing their own efi stub where they have compiled’in various common layouts.

It is common knowledge that when it comes to passwords et al. you should stay within the bounds of the ASCII character table - because - ASCII is the only charset which is guaranteed to produce the same result on different systems.

Yes - the location of the characters within a keyboard layout may deviate but - the keycode produced for an ASCII character will always be the same no matter the layout.

If you press A on the AZERTY layout it produces the same A on the QWERTY layout.

When you have used a keyboard for as long as I have - I learned typewriting in 1975 - the letters on the keyboard becomes irrelevant - it is their location which matters - you can the set a AZERTY keyboard layout using Danish locale and I would be able to write a danish sentence anyway - using locale specific characters like æøå and know where *'&/(%&= is located as well.

And I know that my keyboard atlethics is above average - but the point is - the qwerty layout is a standard - so memorizing the difference between a AZERTY and QWERTY is a help.

There is no operating system which can accomodate for each and every possible use case.

The reference made in a comment equalling Manjaro Company and Manjaro Linux is null and void.

It is not the same … not by any measure.

Manjaro Linux is a community effort by volunteers - myself included - the community makes it possible by donations - which then makes it possible for the team to rent the necessary server space, attend conferences and buy the necessary hardware used by team members to continue providing a privacy respecting operating system free of charge to anyone.

Speaking of community effort

It would be nice if those requiring specific features actually providing working implementations of how to make it possible - this would make it much more possible the functionality would find it’s way into the ISO.

3 Likes
11

I kinda see both sides of the issue. And I agree with both.

A simple improvement would be at least an informative message inside the installer, this is possible by Manjaro team easily I think, no need to update Calamares code to add a message warning at some point in the install process.

1 Like
12

It is common knowledge that when it comes to passwords et al. you should stay within the bounds of the ASCII character table - because - ASCII is the only charset which is guaranteed to produce the same result on different systems.

Yes - the location of the characters within a keyboard layout may deviate but - the keycode produced for an ASCII character will always be the same no matter the layout.

If you press A on the AZERTY layout it produces the same A on QWERTY.

This is the most important point that was overlooked in the previous thread. I don’t know where this miss-conception come from, but no, if you press a A on the AZERTY layout but the QWERTY layout is loaded, a Q will be produced, not a A. So, even if you use ASCII only character, you will still be impacted by this.

When you have used a keyboard for as long as I have - I learned typewriting in 1975 - the letters on the keyboard becomes irrelevant

I can see why this is not an issue to you, but this kind of “design choice” would throw off new users. Manjaro meant to be “user-friendly and suitable for those new to computers”.

A simple improvement would be at least an informative message inside the installer.

Yes, that would be the right thing to do in my opinion.

13

Yes , I agree. And then embrace it, get used to it.

Comparing keyboard layouts is a good start to avoid trouble, I learned the hard way, that was not funny.

14

You are misunderstanding or misinterpreting my comment.

Forget what is printed on the keycap - an A is an A no matter where it is located - that is my point.

You are referring to - and is confused by - the visual layout - what I am saying is the visual layout is irrelevant when you know what layout is configured.

When you know that grub defaults to US QWERTY layout - you know what key to press to get a specific result.

The amount of work required to implement something, that - in this case a specific keyboard layout in grub - is not a widely recognized issue - simply does not add up.

15

OK, I see what you meant and I understand why this is a non-issue to you.

I’m just trying to view this in the eyes of a new user, someone who never tried Linux before, who don’t know what GRUB is or what key codes are. If this person types a A and a Q come up. If you start to explain to them that the A is just paint on the key, and that it’s actually a Q, maybe a warning message was needed.

16

…should we probably also take care for those that uses the “one finger search and destroy” method ?

  • (and yes, I am bad in typing)
17

They know it is bound to be different - and they will likely gladly accept the explanation.

The joke aside - I challenge you to come up with a workable solution and create a merge request for Calamares so your contribution will serve for generations to come.

18

I challenge you to come up with a workable solution and create a merge request for Calamares so your contribution will serve for generations to come.

Thanks for the challenge, but I’m not a Linux dev. I didn’t even knew that Calamares was called that way before starting this thread. I’m just an humble user making a feedback, which is my humble little contribution.

1 Like
19

There’s the wording It’s easier said than done

QWERTY is the defacto standard - and this makes the grub defaulting to QWERTY a sane default.

However I like the idea of providing some kind of label to the Encrypt checkbox in Calamares which becomes visible when you choose to encrypt the system - much like the keyphrase boxes which is not visible unless the box is ticked.

I will suggest you create an issue in the Manjaro Gitlab for Calamares - and suggest just that - you are free to use my wording - I will leave that up to you.

Create an identical issue for upstream Calamares

Link to

20

I have, further up, said this:

It is not that easy and you where correct - of course. :slightly_smiling_face:
I should have read the link in your post.

What I said only works when one has an unencrypted /boot partition.

The way Calamares installs an encrypted system is fully encrypted and Grub has to do the decryption of the container - not the tools in the initrd. (also the reason for why decryption is so slow)
These are only available once the decryption has already happend - the password has already been given.

This means that one would need to build a custom grub image - which is not exactly easy.
Details here, this post and further down. (link to EOS forum)
The procedure looks a bit daunting:

GRUB/Tips and tricks - ArchWiki

But a warning/heads up should be added when full encryption is selected, so that people are aware of the potential problem with different keyboard layouts.

1 Like