Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2235728 - Keyboard layout for LUKS decryption prompt is English (US)
Summary: Keyboard layout for LUKS decryption prompt is English (US)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 39
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jiri Konecny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException AcceptedBlocker
Depends On:
Blocks: AnacondaWebUITracker F39BetaFreezeException F39FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2023-08-29 15:02 UTC by Michael Catanzaro
Modified: 2023-09-08 20:25 UTC (History)
8 users (show)

Fixed In Version: anaconda-39.32.2-1.fc39
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-09-08 20:25:30 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github rhinstaller anaconda pull 5129 0 None Merged core: Look up live user from PKEXEC_UID 2023-09-06 16:46:13 UTC

Internal Links: 1890085

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.
Note You need to log in before you can comment on or make changes to this bug.