Bug 2239213

Summary:	anaconda should use localed layout conversion when setting default console layout
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	anaconda	Assignee:	Adam Williamson <awilliam>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	39	CC:	anaconda-maint, gmarr, jkonecny, robatino, vslavik, w
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:	AcceptedBlocker
Fixed In Version:	anaconda-39.32.4-1.fc39	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	2243206 (view as bug list)		Environment:
Last Closed:	2023-10-13 16:20:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2143446

Description Adam Williamson 2023-09-16 00:29:01 UTC

I ran across this while writing a fix for https://bugzilla.redhat.com/show_bug.cgi?id=2238854 . Turns out there's a bug on the 'old' path here, too.

In 40a604afb9b2573c8f9bd93d5a35f34d29dd245e we added code to try and ensure we set the right console layout on the awkward "switched layout" path for languages like Russian, where we set the X layout config to "us,ru" as requested in https://bugzilla.redhat.com/show_bug.cgi?id=1039185 . I filed the bug that led to this code being added:

https://bugzilla.redhat.com/show_bug.cgi?id=1912609

Now I look at it carefully, though, the fix isn't really right. All we're doing is literally setting the name of the 'native' *xkb* layout as the console layout. But that's not always correct. It happens to work for Russian, because the native xkb layout and the native console layout are both called 'ru'. But it does not work for e.g. Bulgarian. If you do an install in Bulgarian, you'll see we set the xkb layouts to "us,bg", so this code results in us writing KEYMAP="bg" into /etc/vconsole.conf . However, there is no console (kbd) layout called "bg", so we get an error on startup, and console input falls back to the "us" layout.

What I think we ought to do here is something like what I'm proposing on the new g-i-s/live install path. We need to query localed for a console layout - as we were doing before this change - but we need to tweak the input we give it. If we give it our actual xkb config - "us,bg" - it will give us "us" for the console layout, because that's the best match it can find in its data. We need to instead give it "bg,us" or "bg" - the former is optimal, the latter will work in practice (after a systemd fix I also realized we need, boy this is a fun day). So we need to work out the codepath this hits that ultimately gets into the localed proxy stuff, and intercept it along the way and add a special-case for the "us,(SOMETHINGNONASCIICAPABLE)" situation.

An alternative, I guess, is we could just drop the code from 40a604afb9b2573c8f9bd93d5a35f34d29dd245e and I can try and fix systemd's conversion logic to return the line for "bg,us" when we ask it to match "us,bg". I wrote a patch for this but didn't test it yet as I decided it wasn't needed on the live path, but now I'm writing this bug, we might want it for this path.

*Or* we could add new lines to kbd-model-map, but I'm always a bit reluctant to touch that file.

This has been your annual reminder that keyboard layouts *suck*.

Reproducible: Always

Steps to Reproduce:
1. Install in Bulgarian
2. Check /etc/vconsole.conf after install

Actual Results:
It says KEYMAP="bg", you'll find an error about vconsole in the system logs, and the actual console keymap will be us

Expected Results:
It should say KEYMAP="bg_bds-utf8" (if we fix the bug in systemd), or at least KEYMAP="bg_pho-utf8" (if we don't).

Comment 1 Adam Williamson 2023-09-16 03:04:22 UTC

OK, so I think I have a plan to fix both this and https://bugzilla.redhat.com/show_bug.cgi?id=2238854 : 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.

Comment 2 Adam Williamson 2023-09-19 06:28:02 UTC

systemd PR: https://github.com/systemd/systemd/pull/29215 . will do some more testing before sending anaconda PR.

Comment 3 Adam Williamson 2023-09-20 23:03:02 UTC

I'm proposing this as a Final blocker. Criterion: If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in at a console". This is not currently the case for traditional installs using Bulgarian and, I believe, Kazakh (haven't tested that yet, but it looks to have the same issue as Bulgarian: the xkb layout is called 'kz', but there is no console layout called kz, the correct one is called 'kazakh').

Khmer also looks like it's affected, but in fact there's no console layout called 'khmer', it exists only as a symlink to 'us' in SUSE in order to make their keyboard configuration code (which is equally as silly as ours, just in different ways!) work properly, so in fact it doesn't matter much to us.

For Macedonian and Ukrainian, we currently select the non-UTF-8 version of the console layout, when we probably should select the UTF-8 one (this will fix that).

Comment 4 Geoffrey Marr 2023-09-25 23:36:29 UTC

Discussed during the 2023-09-25 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in at a console" in the case of Bulgarian and Kazakh layouts.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-09-25/f39-blocker-review.2023-09-25-16.02.txt

Comment 5 Fedora Update System 2023-10-05 17:12:08 UTC

FEDORA-2023-3355cdb0a8 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3355cdb0a8

Comment 6 Fedora Update System 2023-10-05 21:15:03 UTC

FEDORA-2023-3355cdb0a8 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Adam Williamson 2023-10-07 02:15:42 UTC

note, the systemd update was just a precursor, we need an anaconda update to fix this.

Comment 8 Fedora Update System 2023-10-09 13:03:16 UTC

FEDORA-2023-8d954317bd has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-8d954317bd

Comment 9 Fedora Update System 2023-10-10 01:49:02 UTC

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.

Comment 10 Fedora Update System 2023-10-13 16:20:27 UTC

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.