Bug 2235728

Summary: Keyboard layout for LUKS decryption prompt is English (US)
Product: [Fedora] Fedora Reporter: Michael Catanzaro <mcatanza>
Component: anacondaAssignee: Jiri Konecny <jkonecny>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 39CC: anaconda-maint, awilliam, jkonecny, robatino, rstrode, sbonazzo, vslavik, w
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard: AcceptedFreezeException AcceptedBlocker
Fixed In Version: anaconda-39.32.2-1.fc39 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-09-08 20:25:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2231339, 2143445, 2143446    

Description Michael Catanzaro 2023-08-29 15:02:03 UTC
I selected English (Dvorak) keyboard layout in gnome-initial-setup and entered my LUKS passphrase in that keyboard layout. But anaconda used English (US) for the installed system, so it's not possible for me to unlock the installed system because I don't know how to type my passphrase in this keyboard layout.

This is basically the same as bug #1890085, except it affects Fedora Workstation now in addition to Silverblue.

There is a scheme proposed at https://bugzilla.redhat.com/show_bug.cgi?id=2231085#c5 for anaconda to compute the current keyboard layout from GNOME settings.

Reproducible: Always

Comment 1 Fedora Blocker Bugs Application 2023-08-29 15:06:40 UTC
Proposed as a Blocker for 39-beta by Fedora user catanzaro using the blocker tracking app because:

 All release-blocking images must boot in their supported configurations.

A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so.

(It's extremely difficult to boot because I have to manually look up how to type every single key in my passphrase by mapping them to English US, and then not make any mistakes when typing them because I cannot see which characters are actually entered. Technically it's *possible* to boot, but it's so hard that nobody would realistically ever use the installed system.)

Comment 2 Adam Williamson 2023-08-29 15:23:27 UTC
Well, there is a criterion that specifically covers this: "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When unlocking encrypted storage volumes during boot"

But it is explicitly a *Final* criterion: https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria#Keyboard_layout_configuration

I would say that kinda makes our intention clear that this kind of bug blocks Final, not Beta.

Comment 3 Michael Catanzaro 2023-08-29 15:49:25 UTC
Yeah, I suppose so indeed. Shame, though, because this prevents all beta testing. :(

Comment 4 Adam Williamson 2023-08-29 16:00:18 UTC
Eh, well, there's workarounds. The one I generally use to avoid this kind of problem is to make the password 111111 , since that types the same on almost any keyboard layout. :D

Comment 5 Jiri Konecny 2023-08-30 13:50:00 UTC
The issue on Silverblue is different. AFAIK it happens there because the keyboard layouts needs to be handled with ostree. Not an issue here.

Comment 6 Jiri Konecny 2023-08-30 15:58:05 UTC
I see the issue. My code in Anaconda for reading Gnome Shell keyboard layouts doesn't work in GIS session. It is getting 

```
unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly
```

I'm getting '@a(ss) []' (read empty) value for everything. Sources but also mru-sources

Comment 7 Adam Williamson 2023-08-30 20:01:54 UTC
+4 votes in https://pagure.io/fedora-qa/blocker-review/issue/1225 for Beta FE and Final blocker, marking as such.

Comment 8 Jiri Konecny 2023-09-01 11:12:38 UTC
Tested and it seems this is the correct fix: https://github.com/rhinstaller/anaconda/pull/5074

Comment 9 Jiri Konecny 2023-09-05 16:37:36 UTC
PR: https://github.com/rhinstaller/anaconda/pull/5129

Comment 10 Fedora Update System 2023-09-07 15:48:44 UTC
FEDORA-2023-755dc0b0c0 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-755dc0b0c0

Comment 11 Fedora Update System 2023-09-08 01:37:06 UTC
FEDORA-2023-755dc0b0c0 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-755dc0b0c0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-755dc0b0c0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Adam Williamson 2023-09-08 06:36:19 UTC
This does seem fixed for single-layout cases (I tested a French install). There's still a problem with dual-layout cases (e.g. Russian), but I think that's caused by https://bugzilla.redhat.com/show_bug.cgi?id=2236343 - see details there.

Comment 13 Fedora Update System 2023-09-08 20:25:30 UTC
FEDORA-2023-755dc0b0c0 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.