Manjaro’s graphical installer gives you the possibility to encrypt the destination disk, but if you have a keyboard layout different than US and, as you are supposed to do, set it during installation, and after choosing to encrypt the destination disk you input a passphrase with non-ascii characters, you won’t pass the passphrase prompt during boot, because the keyboard layout you have set when installing does not get loaded before it (it is possible to do it, at least on Arch: see wiki[dot]archlinux[dot]org/title/Dm-crypt/System_configuration#mkinitcpio (had to replace the dots with “[dot]” because i can’t post links, probably due to this post being my first here)).
1 Like
I can’t help with your issue, but consider this a learning experience until your forum privileges have increased sufficiently:
`https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio`
Now, others can simply copy/paste the link.
Cheers.
Hi @pezcurrel and welcome to the Manjaro community.
As a new forum user, please take some time to familiarise yourself with Forum requirements; in particular, the many ways to use the forum to your benefit.
To that end, some or all these links may be invaluable:
- [How to] Request Support
- [How to] Find Error Logs
- [How to] Find System Information
- [How to] Post
Screenshots andLinks
Please avoid posting screenshots of text. - [How to] Post Command Output and File Content as Formatted Text
- Tutorials (category) There’s much to be found here!
- Forum Rules
- Strict Forum Rules and Guidelines
Last, but not least, the Update Announcements, which you should check frequently for important update related information.
An issue may be directly related to a particular update; these announcements should generally be checked before posting a request for support.
I hope this is helpful.
Cheers.
2 Likes
That is indeed, not well thought out and hopefully will someday be fixed.
I do not use encryption, but the situation is similar with the grub menu and console (you only have QWERTY) and the login greeter. Everything can be fixed easily with some simple commands and config files edits, but it is not done automatically by installer, which can lead to very frustrating first experience for new users.
2 Likes
This might deserve some ongoing attention.
Can this be scripted (for instances where a non-English keyboard layout and/or language is selected) so that non-language-aware configurations (such as @Teo alludes to) can be automatically set during install, or at first boot?
Not sure how easy will it be to script, because it was somewhat interactive process and varies. As said, i do not have encryption. But i am currently on a laptop with German keyboard, QWERTZ. And some vital characters like \ ~ etc. have different places in comparison with US QWERTY. So i took some precautions to adjust the keyboard layouts, in case i cannot boot to graphical (i know, live usb, but still).
So in case i need the grub (rescue) console, or to edit kernel parameters before boot, i installed german layout on grub as per this or some similar guide
https://debianforum.de/forum/viewtopic.php?t=174164
And then there is the tty, if i need something other than 7 
Which will be especially useful for nvidia and plasma users i guess 
https://wiki.archlinux.org/title/Linux_console/Keyboard_configuration
[teo@teo-lenovo-v15 ~]$ cat /etc/vconsole.conf
# Written by systemd-localed(8) or systemd-firstboot(1), read by systemd-localed
# and systemd-vconsole-setup(8). Use localectl(1) to update this file.
KEYMAP=de-latin1-nodeadkeys
FONT=
FONT_MAP=
XKBLAYOUT=de,us
That is however heavily dependend on the model of the keyboard of the laptop!
And maybe we also ping @philm on this… i doubt @Yochanan uses anything else than QWERTY.
This is a well known issue.
It has existed for as long as I have been using Manjaro - as this has been discussed on many occasions - I am confident you can find other topis using the search function.
Yes. But that is only part of it.
/etc/vconsole needs to be configured properly with the correct keymap
and
either the “consolefont” HOOK or the “sd-vconsole” HOOK needs to be placed into /etc/mkinitcpio.conf
so that the initrd uses the correct keymap and the password can be typed.
But this will only work if /boot is not encrypted.
(time permitting, I will try and verify this, since it has been some time since I did encounter it
and I have always avoided this by not encrypting /boot)
With a fully encrypted system as the Calamares installer creates it, Grub does the decryption
and it needs to know about the keymap.
That process is described here:
It may be difficult to script - I don’t know.
But a big fat warning needs to be there that it is important that people know how to type their password on a different keyboard layout
or to choose a simple password which can be typed everywhere.
The first is at least awkward, 
the second almost defeats the purpose of having an encrypted system.
1 Like
I think scripting all the variables and then property testing it is a bit of a project and probably not realistic shortterm, so i vote for a warning message for now. It is better than the current nothing.
There is also section 12.1 a bit further down.
This looks much easier to implement, although I’m not at all sure and knowledgeable about the EFI and whether it is always unencrypted anyway.
And on top:
there is not only EFI systems, but the older Bios as well - and this would not work there.
I guess when I try, I try this one.
consolefont is there by default.
But it does not correlate to any font being set.
I do wonder how this would all work out with systemd (and then sd-vconsole and sd-encrypt) in use …
It changes the requirements, such as in the case of hibernation that resume= is not required to be set in grub conf … so maybe it could add some simplification here as well?
right
I read the table wrong
→ the Arch wiki on mkinitcpio
I used the wrong HOOK
I meant to say: keymap
… the font is how a character looks - the keymap is what it is
In my own config - the one with unencrypted /boot that I mentioned - I used both,
with keymap being the really crucial one
this is how it looks:
HOOKS="base udev autodetect modconf block keyboard keymap consolefont encrypt filesystems fsck resume"
It was a few years ago now - I did try using sd-… hooks but could not make it work back then
so this is what it was and still is.
I am using sd-vconsole, seems to work also without specifying font, i have posted my config above. The other things are important, generating kbd and adding the path to it as shown in the debian guide.
I moved this to the Support category and changed the title.
It is not a bug - but rather a limitation on how the system initialize.
If you are using encrypted /boot - the limitation is quite visible.
If you are using unencrypted boot it is easier to get a nice cryptphrase input.
Systemd boot will work OOB as the kernel is expected to be stored in the EFI partition.
1 Like
You don’t tell us whether you’re trying to place your initramfs/initrd (generated by mkinitcpio) on an encrypted partition. If that’s the case, you might want to look into grub-kbdcomp for Grub, which is used to unlock the partition.
I don’t use Grub anymore, so I don’t fully remember how to properly set up the keymap for Grub. However, I do know that systemd-boot or Limine can avoid this issue, as they move the initramfs to an unencrypted partition while supporting the functionality you need.
Grub tries to handle everything on its own but comes with more config complexity.
This seems to open the proverbial can of worms. At face value, the impression is obvious that there is no easy workaround that encompasses everything.
A warning only goes so far, especially with new users.
Might it be better to address the issue after install (and remove the option from Calamares)?
Does it make any sense to create a post-install script instead; thereby avoiding possible encryption issues during first boot? → or, perhaps a detailed guide could be drafted for the user to follow, that also accounts for these discrepancies.
A user could then be confident that the system boots and functions as expected, before deciding to encrypyt.
I dare say, there must be a percentage of users who have no prior expectation/understanding of encryption on Linux in any case, and just click the toggle when they see it;
with the assumption that everything will magically “just work”.
1 Like
The origin of this (what the OP said) stems from what the Manjaro installer can and cannot do,
and that there is no hint that the password input will assume a standard english keyboard,
leading to problems when that is not the case.
Of course this can be addressed after the installation in a few ways.
grub-kbdcomp for Grub
or
using a different boot loader
or
placing the relevant files in the EFI partition
or
splitting out /boot to be unencrypted …
But as of now, if someone like me, with a german keyboard, doesn’t know this
there will be problems right from the start,
because typing the decryption password will be a challenge.
It should be mentioned - a warning / informational message - when full disk encryption is chosen.
1 Like
A warning makes sense…
And, so does removing the issue completely…
I suppose it’s a question of which is most practical, and more importantly, most effective.
I recall reading through that once or twice (I don’t use encryption) and it’s a good resource, but it doesn’t help those who just click the checkbox thinking everything is fine. Sure, they’ll soon learn; I suppose that might be some consolation.
1 Like
Perhaps an easier thing to do this could be
to “translate” the keystrokes from the actual keyboard layout to the english one
and use a second key slot to store this.
I struggle to describe the idea - it should result in both keyboard variants being able to unlock the encrypted system.
In my case that would involve swapping the z and y key, and pretty much all the symbols and punctuation marks.
1 Like
This is going to complicate things for new users; I’d sooner it be a symlink to there if possible, with the target /boot/whatever being unencrypted. The user will need a much bigger efi partition, for one thing.
This would likely avoid a lot of these issues.
Thing is, do some of these new users really need full disk encryption, if any at all? Why is it in a prominent position in Calamares, without these suggested warnings?
1 Like