On the KDE live image, anaconda-webui offers direct keyboard layout configuration (unlike the Workstation live). However, this interface really doesn't work for multiple layout scenarios, e.g. Russian. The keyboard layout selector gives you a list of layouts and allows you to select just one. This just isn't correct for everyone. If you look at https://github.com/systemd/systemd/blob/main/src/locale/kbd-model-map , in every case where the third column has two entries (e.g. 'ru,us' for Russian), the standard X layout configuration for that language is to have *two* layouts configured: one layout for entering 'native' (e.g. Cyrillic) characters, and one layout for entering ASCII characters (usually 'us'). These languages have enough native characters that a single layout cannot encompass both all the native characters *and* all the ASCII characters that are commonly used even by non-English speakers, so having two layouts is effectively required. You cannot reasonably use a computer with *only* a Russian (or Ukrainian or Bulgarian or whatever) X keyboard layout configured. You can see how this is supposed to work by using a DVD or network installer, where we get the old GTK UI flow with full control of layout configuration. If you pick Russian as your language, it automatically (via localed, behind the scenes, which is ultimately using that kbd-model-map file...) sets up *both* 'us' and 'ru' layouts, and lets you switch between them. This kind of complication, along with the messy interface between 'kbd' and 'xkb' layouts, is why we don't stick a layout selector front and centre in GTK UI - it's intentional that we only present a language choice up front and expect most people to stick with the 'default' keyboard layout config for the language they select, as it cuts down on weird consequences of unexpected choices. And it's why the keyboard layout spoke in GTK UI, if you *do* choose to access it, lets you configure multiple layouts, not just one. The current interface is more of a footgun than a help. For instance, if you pick Russian as your layout, you can barely install with encryption enabled, as you can barely enter any ASCII characters, and we require that encryption passphrases be ASCII-only) - you have to set a passphrase containing only digits and ASCII punctuation, those being the only ASCII characters you can type. You also cannot create a username and password using ASCII characters, which is what most real-world users do, they do not usually use Cyrillic characters in their username or password (as experience has shown it tends to cause weird bugs and it's just safer to use ASCII).
Proposing as a Final FE as this is a bad experience during install that cannot be fixed with a post-release patch. I was close to proposing it as a blocker but it's a bit tricky to make the argument and we'd *probably* waive it for being a bit late anyway.
On a desktop where anaconda has the ability to control the layout config, I would suggest we should act as similarly as possible to GTK UI. Only offer language selection, and do a sensible default layout config for the language automatically. If we really really must provide a choose-your-own-layout experience at all, it should be optional, start from the default config for the user's selected language, and be multi-select and handle hotkey switching.
(see also bug 2402459 which I just opened - seems an overall problem)
I sent https://github.com/rhinstaller/anaconda-webui/pull/1037 as a tentative minimal 'fix' for this, by just hiding keyboard layouts that can't input ASCII. It depends on https://github.com/rhinstaller/anaconda/pull/6692 as well. Needs review by someone who understands javascript.
(In reply to Adam Williamson from comment #1) > I was close to proposing it as a blocker but it's a bit tricky to make the argument and we'd *probably* waive it for being a bit late anyway. I'll propose it anyway. This sounds like a serious issue, and even if we waive it for being too difficult to fix, it will at least be immediately accepted for F44. Also, during F44 cycle people won't be able to say "but it already worked this way in F43, so it's not a regression...".
Fair point. I'd like to test my fix but I can't because I still don't know of a good way to test anaconda-webui changes :( The makeupdates script in anaconda-webui does not work, and you cannot easily do a scratch build with any changes because it triggers a nodejs rebuild that fails. This time, I realized that's actually an apparent packaging guideline violation, so I reported it: https://pagure.io/packaging-committee/issue/1496
+4 blocker in https://pagure.io/fedora-qa/blocker-review/issue/1966 , marking accepted.
FEDORA-2025-ace7e79b36 (anaconda-43.44-3.fc43 and anaconda-webui-53^20251014git7ea927a-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-ace7e79b36
I checked this myself and it does appear to work, with the caveat that we still show layouts which aren't actually ASCII-capable but which langtable doesn't have data for. It's hard/impossible to avoid that, though, other than sending patches for all of them to langtable (which we should probably get around to).
I checked this update, too, but I am not convinced. Just by itself, Anaconda does not let me select more then one layout, if I select a Russian layout, Anaconda does not accept cyrillic for the user name, when trying to set up root account using cyrillic, it crashes with "Password too weak" (which was a different issue). The only way I could install is to switch to Russian and leave the default US layout.
> The only way I could install is to switch to Russian and leave the default US layout. This is generally the correct outcome. You are not supposed to run a successful installation with just a single layout without ascii characters. So the core issue here is not to allow that kind of installation, but to highlight early enough and clearly enough (ideally without a complete crash of the UI) that it won't work.
wait, but Lukas is saying anaconda let him through with "a Russian layout", which we're trying to avoid. He was probably bitten by the 'langtable doesn't know about some layouts' problem, though. Lukas, do you remember *exactly* what layout you picked?
FEDORA-2025-ace7e79b36 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-ace7e79b36` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-ace7e79b36 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Adam Williamson from comment #12) > wait, but Lukas is saying anaconda let him through with "a Russian layout", > which we're trying to avoid. > > He was probably bitten by the 'langtable doesn't know about some layouts' > problem, though. Lukas, do you remember *exactly* what layout you picked? Yes, I was able to select the Russian layout and the Cyrillic alphabet and I could proceed to the user creation pane, where it would not let me use a login name with non-ascii characters, so I wanted to trick it by selecting root only system and when I attempted to write the password in cyrillic, webUI showed the Password too weak error, and offered to report the crash.
FEDORA-2025-ace7e79b36 (anaconda-43.44-3.fc43 and anaconda-webui-53^20251014git7ea927a-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Reopening until we can verify that this is indeed fixed.
Well, it's sort of fixed. anaconda does the 'right thing' now, in the context of its limited current design: it tries to not list non-ASCII-capable layouts for selection. Unfortunately, langtable doesn't know about *every possible* xkb layout that's not ASCII capable, so it winds up still offering things like "Russian (Belarus)", which is not ASCII-capable but langtable doesn't know that. We can send some patches for langtable with additional data, but we're actually hoping to be able to land some significant enhancements to the anaconda design which will make it actually do what it should (allow multiple layouts, and default to the correct 'switched' configurations for major switched languages, like gtkui does on non-live installs).
Ok, closing this as "fixed to a reasonable extent", and keeping this in CommonBugs so that we can document the edge cases, if we don't get a better implementation before F43 is released.
FEDORA-2025-d0c150f260 (anaconda-webui-53.1-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-d0c150f260
FEDORA-2025-d0c150f260 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-d0c150f260` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-d0c150f260 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-d0c150f260 (anaconda-webui-53.1-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.