Bug 1955793

Summary: System fails to set keymap during boot, leading to incorrect keymap during disk decrypt password prompt (Finnish special case)
Product: [Fedora] Fedora Reporter: iolo
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: MODIFIED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 34CC: anaconda-maint-list, awilliam, jonathan, kellin, vanmeeuwen+fedora, vponcova, w
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: anaconda-35.16-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-04 16:21:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description iolo 2021-04-30 19:17:59 UTC
Description of problem:
I installed Fedora 34 Workstation with a Finnish keyboard layout, and also encrypted my disk. The installation itself went fine. However, when Plymouth prompts me for the encryption password after booting the machine, I must enter the password as if I was using a US keyboard. That is, despite the indicator beneath the password prompt saying FI to indicate a Finnish keymap, I must look up a picture of a US keyboard, and then type my password in as if I was using one of those. In other words if my password has a / character, I must type it in by pressing the key where it _would_ be on a US keyboard, rather than where it actually is on my physical keyboard.

I suspect this is related to a bug[1] in the kbd package, because I also see the same error message when booting, just before Plymouth shows up:

[FAILED] Failed to start Setup Virtual Console
[DEPEND] Dependency failed for dracĊİadditional cmdline parameters

I believe that the system fails to set the keymap to FI, and then defaults to US. However, once I have typed the password in with the wrong keymap and get into a graphical environment, the keyboard layout is correct once again.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1955162

Version-Release number of selected component (if applicable):
I'm not quite sure, but it's whatever is on the latest installation medium for F34 Workstation.

How reproducible:
I have now tried this twice, on two different machines, and had the same problem both times.

Steps to Reproduce:
1. Install F34 Workstation with a Finnish keyboard layout and a disk encryption password containing special characters like &, / and ?, whose physical locations differ between Finnish and US keymaps
2. Boot the machine
3. Try to decrypt the disk by entering the password as if using a Finnish keymap

Actual results:
The password must be entered as if using a US keyboard.

Expected results:
The password can be entered using the Finnish keyboard layout, as selected during installation and as indicated by Plymouth beneath the password prompt.

Additional info:

Comment 1 Adam Williamson 2021-05-04 16:21:58 UTC
yeah, the 'fi' layout is in kbd-legacy, so this is likely the same as 1955162 . If you install from a traditional installer image (Server DVD or netinst) and enable a remote repository during install, it will likely work, as the kbd-legacy package will be available to the installer. Sorry for the trouble.

*** This bug has been marked as a duplicate of bug 1955162 ***

Comment 2 iolo 2021-05-05 09:42:00 UTC
As a note to anyone who might try the above, installing with a netinst image does not help.

Comment 3 Adam Williamson 2021-05-05 16:10:04 UTC
Huh. It really ought to. I wonder if there's a different problem for Finnish? I'll try it out and see. Sorry for the trouble.

Comment 4 iolo 2021-05-05 16:21:03 UTC
I think it might be another issue with the Finnish keymap altogether after all. This is because I installed kbd-legacy and rebooted, but that didn't fix the issue. I'm still trying to figure out what it could be. Sorry for the misleading initial report.

Comment 5 Adam Williamson 2021-05-05 16:34:05 UTC
It's okay, I might have been too quick to assume it was the same thing. I'll try a Finnish install today and see if I can work anything out. Let's un-dupe this for now.

Comment 6 Adam Williamson 2021-05-05 17:31:26 UTC
Ahh, okay. So, I see what's going on here. Finnish is a bit of a special case.

So the whole story here is that we generally try to use converted xkb layouts for console layouts, rather than the "legacy" console layouts that are in the kbd source tarball. But this doesn't work for what are referred to as "switched" layouts, for languages which have a non-Latin alphabet and where the normal way to type is to 'switch' between a map for inputting Latin characters and one for inputting native characters. xkb-converted layouts don't work in this case because they only allow input of native characters, they have no other 'map' for inputting Latin characters (because in X you're expected to switch between the native layout and the 'us' layout, whereas at the console both maps are encoded into a single layout on different 'levels').

So in the kbd spec, we auto-convert all the xkb layouts, but then we delete any that can't input the ASCII character U+0041. The expectation is then that the identically-named layout from the kbd-legacy package will then be used for that case.

The problem we had for these 'switched' layouts was that anaconda didn't know to install kbd-legacy when one would be used. So we fixed that in anaconda by having anaconda use a property langtable provides that encodes the same logic:

        if self.vc_keymap and not langtable.supports_ascii(self.vc_keymap):
                reason="Required to support the '{}' keymap.".format(self.vc_keymap)

so basically "if the xkb layout we picked doesn't support ASCII input, install kbd-legacy".

But...Finnish is different. It's not a switched layout, exactly. The xkb 'fi' layout *does* support ASCII input. However, there was a bug filed back in 2014 which said the converted 'fi' xkb layout is still not the best choice for console input, and requested the 'legacy' layout be used instead: https://bugzilla.redhat.com/show_bug.cgi?id=1117891

So, we did that. After the xkb conversion happens and the "delete all converted layouts that can't input ASCII" filter runs, there's a specific stanza in the kbd spec which renames the xkb-converted 'fi' layout to 'fi-kotoistus'. So in the 'kbd' package, there is no 'fi' layout. There is only 'fi-kotoistus' and several other variants. The only layout actually called 'fi' is in kbd-legacy.

However, because the 'fi' xkb layout *does* allow ASCII input, the bit we added to anaconda doesn't fire. We don't add kbd-legacy to the package set to be installed.

So, the fix for Finnish in the end will have to be extending the anaconda check a bit to just explicitly add kbd-legacy if the layout is called 'fi', I think.

Sorry again for the trouble :(

Comment 7 iolo 2021-05-05 19:04:15 UTC
That's okay, these things happen.

TL;DR installing kbd-legacy _and_ running "sudo dracut --force" fixes the issue

I discovered that installing kbd-legacy did fix something after all: after successfully booting and then going into a virtual console, the keys all worked as expected. So then it was only during boot that the keymap wasn't working right. The error message I mentioned earlier seemed to say something about dracut, and after searching for it, I found the command "sudo dracut --force". Running that after installing kbd-legacy has now fixed the problem during password entry as well.

I suppose the installation media still can't be fixed, but at least now if someone else runs into the same problem, here's the solution.

Comment 8 Adam Williamson 2021-05-05 20:38:11 UTC
oh, yeah, I should've mentioned that in the commonbugs entry. My bad. Indeed during decryption we're in the initramfs environment - obviously, since the main system is still encrypted! - so that needs updating for encrypted systems. I'll enhance the commonbugs page.