This is a follow-on from https://bugzilla.redhat.com/show_bug.cgi?id=2236343 . In current Rawhide, AFAICT, gnome-initial-setup is doing "the right thing", but there's still a problem, so setting this to anaconda. When we install in Russian, using the web UI flow, on the installed system, the console keyboard layout is set to "us". This isn't right. It should be "ru". Reproducible: Always Steps to Reproduce: 1. Boot a current Rawhide Workstation live image. 2. Set the locale to Russia on the first g-i-s page. 3. On the second g-i-s page, confirm the keyboard layout is set to Russian. 4. Proceed to the third page. Note that the currently set layout is "us", but "ru" is available as the second option (this is correct). 5. Proceed to the installer and install the system. 6. Boot to the installed system. Note that, again, both "us" and "ru" layouts are available, with "us" as the default. 7. Go to a console, type some characters (you should see Latin characters), then press ctrl+shift and type some more characters. Also check the contents of /etc/vconsole.conf Actual Results: Hitting ctrl+shift does not switch to inputting Cyrillic characters, and /etc/vconsole.conf says KEYMAP="us". Expected Results: Hitting ctrl+shift at the console should switch to inputting Cyrillic characters, and /etc/vconsole.conf should say KEYMAP="ru". anaconda has some very careful handling of this stuff in pyanaconda/keyboard.py `set_x_keyboard_defaults`. Note especially the block under the comment that starts "the console layout configured should be "native" by default". However...we don't hit that code at all on the webUI flow. We instead hit the new code in pyanaconda/modules/localization/live_keyboard.py . What this code winds up doing is just asking localed to convert the *single currently active* xkb layout to a kbd layout. So if you happen to have the 'ru' layout selected whenever this code is hit, I guess, you'll get the 'ru' console layout. But that is not the usual case. People installing in Russian - and other similar languages affected by this class of issues - will usually have 'us' selected in the installer (even if we *don't* make it the default, they will likely switch to it if they need to type anything), because they generally need to type Latin characters in the installer. But this doesn't mean they want "us" as their console layout! In other words, the assumption jkonecny put in the commit message for this code - "Look for currently used keyboard layout and set that as virtual console keymap after conversion. It's probably what user wants to use because it was used during the installation." - is just not correct. Because of the difference between how layout switching works in kbd and xkb, you cannot assume that the currently-active xkb layout is the layout the user wants on the console.
Fixing this might be a bit fun. We can try to replicate something like the very-special-purpose logic `set_x_keyboard_defaults` uses: "if there's more than one layout in the xkb layout list, and the second one does not support ASCII, pick that for the vconsole layout". Or, we can just pass the whole list of xkb layouts to `convert_layouts`, which should ultimately dump the problem on localed and its good ol' kbd-model-map lookup table...but that will actually only give us the right answer if we feed it the list "ru,us", whereas the order we actually want in X is "us,ru" (I think kbd-model-map was never updated after https://bugzilla.redhat.com/show_bug.cgi?id=1039185 ). We could possibly add new lines to kbd-model-map that are the same as the current ones for all "XX,us" entries, except reversed to be "us,XX". That would...probably solve the problem.
Proposing as a Final blocker for F40, as a violation of "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in at a console" (for these "fun" switched cases, we always read that to mean "if you install in Russian, you should get 'ru' as your console layout").
OK, so I think I have a plan to fix both this and https://bugzilla.redhat.com/show_bug.cgi?id=2239213 : make anaconda try less hard. Drop the special-case code for setting the console keymap on this live install path, and also drop the special-case code for setting it for switched layouts in the old set_x_keyboard_defaults path. In both cases, just get the X layouts right, then ask localed to convert. Right now this gives wrong results, but I have a patch that fixes localed to handle these cases better. If I can get that merged we can make anaconda much simpler. I need to tidy up both anaconda and systemd patches a bit and update the test suites, but I did some preliminary testing and it looks good.
Thanks Adam for providing the fix and all the other work you have done for this!
don't thank me till we work out what I broke :P
FEDORA-2023-8d954317bd has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-8d954317bd
FEDORA-2023-8d954317bd 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-8d954317bd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-8d954317bd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-8d954317bd has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.