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.
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.)
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.
Yeah, I suppose so indeed. Shame, though, because this prevents all beta testing. :(
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
The issue on Silverblue is different. AFAIK it happens there because the keyboard layouts needs to be handled with ostree. Not an issue here.
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
+4 votes in https://pagure.io/fedora-qa/blocker-review/issue/1225 for Beta FE and Final blocker, marking as such.
Tested and it seems this is the correct fix: https://github.com/rhinstaller/anaconda/pull/5074
FEDORA-2023-755dc0b0c0 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-755dc0b0c0
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.
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.
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.