This is a downstream report of https://invent.kde.org/plasma/plasma-setup/-/issues/52 . I was hoping that would get fixed promptly when reported, but it was not, and now it's a problem for the Fedora 44 release. Final criterion https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Keyboard_layout_configuration : "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... In the "initial setup" utility (if applicable)" https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior is also relevant: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." The actual experience when installing Fedora 44 KDE with a switched layout (Russian, for testing) is as follows: 1. The installer mostly gets things right. You pick Russian language, it auto-selects 'us,ru' as the keyboard layout configuration, which is correct. 2. You can't create a user in the installer. 3. plasma-setup runs on first boot. It doesn't pick up your selection from the installer properly; on the keyboard layout page, no option is pre-selected. If you pick Russian (the logical choice), you can't really create a user account properly, because it configures *only* Russian, so you cannot type Latin characters. The only account name you can create that satisfies the requirements is an underscore followed by a number string, e.g. _1234 4. If you do that, and go to system settings / keyboard, it appears to show *no* layouts configured at all, which is odd. You can, a bit painfully, add a U.S. English layout, at which point you can't type Russian any more. Then you can add a Russian layout, and finally you have the config you wanted all along, switchable US/Russian.
Hmm, now I look around, I remember that gnome-initial-setup has more or less the same problem: https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/103 We've been releasing that way for a while, so I guess to be consistent we shouldn't block on this either. But it is bad. I wish they'd both fix it properly. g-i-s is a *little* 'better' in that it defaults to US English as the keyboard layout when you pick Russian as the language, which is the wrong-but-workable choice.
I tested that scenario on Workstation Live and KDE Live on Beta 44. On both systems, I followed this approach: * Download the Fedora 44 Beta KDE Live ISO or Workstation Live ISO. * Boot the system from that ISO. * Start the installation. * In the installer, I always get Czech as a suggested language, and I always get English (US) as the default layout. * On Workstation, I can switch the language to Russian and add Russian as a secondary layout. On KDE, Russian is added automatically when I select Russian language so I only need to keep the layouts "as is". * Continue the installation and finish it normally. * Reboot into the installed system. * In Initial Setup, do not make any changes to language or keyboard settings. * On both systems, GIS defaults to primary language, which is US (unless the user switched that on purpose). * Then I create a user account and password using the keyboard layout available there (US). * Finish Initial Setup and proceed to the login screen or desktop session. * After that, I have a working Russian environment with dual layout, English and Russian. The system looks usable to me and although I can read cyrillic, I do not know how to use the Russian layout to type properly, but apart from that, I believe that the system is fully workable. Tomorrow, I will also try with the latest ISOs, but I do not expect the behaviour to be much different. How do I reproduce "not being able to create a user"?
> How do I reproduce "not being able to create a user"? Don't keep the defaults in plasma-setup / gnome-initial-setup, but pick Russian keyboard layout. This is something I would expect at least some Russian users to do. If you do this you will immediately be unable to type anything but Cyrillic characters and a few ASCII characters that exist on that layout, like numbers. I've confirmed that in F44 on KDE at least, and I'd expect it to still be the case for g-i-s. openQA's webUI cyrillic language install test doesn't see the same as you, but on closer inspection that's because we didn't make it configure a switched layout manually in the installer (of course, it shouldn't have to do that). I'll see if it behaves as you described if we change that.
AGREED AcceptedFinalBlocker Discussed at the 2026-03-23 (blocker / freeze exception) review meeting: This is a violation of "keyboard layout configured in installer must be used in initial setup" criterion, when non-latin layouts are configured (and a secondary latin layout is added by the installer). https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-03-23/f44-blocker-review.2026-03-23-16.00.log.txt
(In reply to Adam Williamson from comment #3) > > How do I reproduce "not being able to create a user"? > > Don't keep the defaults in plasma-setup / gnome-initial-setup, but pick > Russian keyboard layout. This is something I would expect at least some > Russian users to do. If you do this you will immediately be unable to type > anything but Cyrillic characters and a few ASCII characters that exist on > that layout, like numbers. I've confirmed that in F44 on KDE at least, and > I'd expect it to still be the case for g-i-s. > > openQA's webUI cyrillic language install test doesn't see the same as you, > but on closer inspection that's because we didn't make it configure a > switched layout manually in the installer (of course, it shouldn't have to > do that). I'll see if it behaves as you described if we change that. Just to make sure I understand correctly, which one is the one to do: 1) I should remove the English layout and choose the Russian layout in Anaconda and install with that? 2) I should choose again in G-I-S/KDE setup to surpress what has been chosen during the install?
2). I think this is likely, because the initial setup tools (IMO) don't clearly communicate that things are actually OK (according to your testing anyway, I should confirm). They don't show that the correct configuration is set (Russian *and* US English). They make it look like only US English is set. It seems likely to me that a Russian (or whatever, we just use Russian as an example) user would see that, assume it meant there was a bug, and try to "fix" it by selecting the Russian layout.
I'm actually gonna kick this back for a re-vote based on Lukas' testing. If we confirm the behavior is as he described, there's an argument that we *do* comply with the letter of the criteria here. Last meeting's discussion seemed to be based on the assumption that we didn't. So I re-tested this myself on KDE. Here's my notes: 1. The installer does show that it configured the keyboard layout as 'en,ru' - but in the live environment it does not actually *work*. If you hit meta-alt-k (the key combo to switch layouts) it shows a notification indicating you switched layouts...but you didn't. If you find a bit in the installer where you can type something and see what it comes out as, it comes out as Latin characters no matter how many times you hit meta-alt-k. 2. Switching does not work at all in plasma-setup itself. Hitting meta-alt-k just gives you a k. 3. The keyboard layout selection screen, as I noted initially, does not show *anything* as already-selected. Yes, you can hit continue in this state and it turns out to do the right thing, but this is not particularly obvious. It doesn't show US as selected, it doesn't show Russian as selected, it shows nothing. 4. Yes, if you navigate all these landmines correctly, once you finally wind up at a desktop, switching is configured and works correctly. Will re-test on GNOME later.
In GNOME, g-i-s like p-s doesn't give any real indication that both layouts will be used, on the layout selection screen. But if you do proceed without changing anything, the layout indicator appears on the next page and switching does work from then on. Switching also works in the live environment once you've configured it via GNOME control center after clicking the link in anaconda.
AGREED Delayed Decision Discussed at the 2026-03-30 (blocker / freeze exception) review meeting: Further testing has indicated there are several issues here, none of which is quite as clear-cut as first thought. We will delay the decision here so we can split this into several more specific reports that each be considered on their own merits. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-03-30/f44-blocker-review.2026-03-30-16.00.log.txt
OK, so, I poked at this all day today. I've filed a couple of new bugs for KDE: https://bugzilla.redhat.com/show_bug.cgi?id=2453216 - plasma-setup Keyboard Layout page pre-selection issues https://bugzilla.redhat.com/show_bug.cgi?id=2453260 - layout switching doesn't work right in KDE live boot environment For GNOME, mcatanzaro snuck a change into https://bodhi.fedoraproject.org/updates/FEDORA-2026-1b515008be , which we'll need to pull in to fix unrelated blocker https://bugzilla.redhat.com/show_bug.cgi?id=2446745 . He made that update also entirely disable the language and layout pages in g-i-s, on the basis that they're redundant with the webui steps for doing language and layout selection. So that means we don't really have any issues with this in g-i-s any more. The remaining issue on the GNOME flow is still that webui does not do layout configuration on GNOME because of the long-standing issue about GNOME not giving it the right interfaces or permissions or whatever, so it just shows a link to the GNOME Control Center where you have to do it. Still, that's longstanding behavior and doesn't really violate any criteria, so it's fine. We should keep this bug to be strictly about the topic, and re-consider whether it's a blocker in that case, and also consider whether https://bugzilla.redhat.com/show_bug.cgi?id=2453216 should be considered a blocker. We could also do something fuzzy like declaring that the *combination of the two problems* is a blocker and KDE has to make it less bad, somehow, to some degree...
Discussed at 2026-04-06 blocker review meeting: https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-04-06/f44-blocker-review.2026-04-06-16.00.html . We agreed that this and https://bugzilla.redhat.com/show_bug.cgi?id=2453216 , taken together, constitute a subjective violation of https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Keyboard_layout_configuration : we believe it's likely that, on encountering the Keyboard Layout screen with no choice apparently selected (because of the other bug), a reasonable user expecting a switched layout may well click on their native layout. If they do that, they do not get the switched layout they expected (and which the installer correctly gave them), but an unusable native-only configuration, due to this bug. We agreed that we expect the KDE team to try and improve the overall experience of an install where a switched layout configuration is expected, and any update intended to address this can be marked as fixing one or both bugs. We will re-assess the situation once intended improvements are available for testing.
Discussed at 2026-04-23 Fedora 44 Go/No-Go Meeting #2, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-04-23/f44-final-go-no-go-meeting-2.2026-04-23-18.00.html . This was WAIVED to Fedora 45 Final as a "Difficult to fix blocker bug" per https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases . We note that we're reliant on upstream for a fix here, and upstream tells us it is not trivial to fix this and a correct, safe and tested fix isn't realistically going to be available within a reasonable time frame for the Fedora 44 release. We further note the fact that we *did* get a fix for https://bugzilla.redhat.com/show_bug.cgi?id=2453216 substantially mitigates the impact of this bug, as it makes folks less likely to think they need to select anything on the Keyboard Layouts page. This is waived to Final rather than Beta as the violated criterion is a Final one, so this shouldn't block a Beta release.
Common issue description: https://discussion.fedoraproject.org/t/common-issue/183547