Bug 2538553

Created attachment 2158393 [details]
screenshots in pdf

qwerty is changing to qwertz

Proposed as a Blocker for 45-final by Fedora user psklenar using the blocker tracking app because:

 https://fedoraproject.org/wiki/Fedora_45_Final_Release_Criteria#Keyboard_layout_configuration

User configured Czech (QWERTY), but when unlocking encrypted volume during boot, layout is cz-us-qwertz => user's configuration QWERTY layout is NOT used.

Second case (US layout):

Add an additional layout US (United Kingdom).
The overview then shows:
Keyboard: us, uk

However, the keyboard layout in section 'encryption' and during boot is:
us-acentos

....us-acentos is neither US nor UK.

I reproduced the issue.

My suspicion is that Anaconda/systemd might be trying to derive the LUKS/VConsole keymap from all configured input sources at once. For example, `cz-us-qwertz` exists, while an equivalent `us-cz-qwertz` might not, so the conversion might fall back to the closest matching combined keymap even when `us` is the default.

I think the VConsole keymap should instead be derived only from the user's default keyboard layout:

| Configured layouts | Default   | Expected LUKS / VConsole |
| ------------------ | --------- | ------------------------ |
| US, CZ             | US        | `us`                     |
| CZ, US             | CZ QWERTZ | `cz-us-qwertz`           |
| CZ (QWERTY), US    | CZ QWERTY | `cz-qwerty`              |
| US, CZ (QWERTY)    | US        | `us`                     |
| US, UK             | US        | `us`                     |
| UK, US             | UK        | `uk`                     |

Secondary input sources might therefore not need to participate in the LUKS/VConsole keymap selection at all.

With this approach (deriving the vconsole from the user's default keyboard layout only) a user with Czech as primary and US as secondary would get keymap cz instead of cz-us-qwertz, losing the ability to toggle to US at the LUKS passphrase prompt.
Are we OK with this regression?

And as Lukas correctly pointed: The conversion happens in _resolve_missing_by_conversion [1] , which currently passes all configured X11 layouts to systemd-localed for VConsole keymap conversion.

[1] https://github.com/rhinstaller/anaconda/blob/main/pyanaconda/modules/localization/utils.py#L67

(In reply to Katerina Koukiou from comment #5)
> With this approach (deriving the vconsole from the user's default keyboard
> layout only) a user with Czech as primary and US as secondary would get
> keymap cz instead of cz-us-qwertz, losing the ability to toggle to US at the
> LUKS passphrase prompt.
> Are we OK with this regression?

I think we should discuss it. I personally would expect that if Czech keyboard is my preferred keyboard, I would want to use it for LUKS, too, but now when you ask, I am not sure others feel the same.

(In reply to Katerina Koukiou from comment #5)
> With this approach (deriving the vconsole from the user's default keyboard
> layout only) a user with Czech as primary and US as secondary would get
> keymap cz instead of cz-us-qwertz, losing the ability to toggle to US at the
> LUKS passphrase prompt.
> Are we OK with this regression?

It is just a coincidence that such a VT keymap exists. If I configure my system to use Spanish (primary) and Czech keymaps, you're not going to find a VT keymap that allows switching between those two languages. So my current opinion is that the default keymap should be used both for typing in the password in anaconda-webui and for unlocking the disk in LUKS. So in case of "us,cz(qwerty)" it would be "us", for "es,cz(qwerty)" it would be "es", for "cz,us" it would be "cz".

Is there something to be aware of for switchable keymaps (like Russian)? For "ru,fr" it would be "ru". Which means Anaconda would encrypt the disk with Cyrillic characters and LUKS would unlock them with Cyrillic characters as well (is the the default state of the "ru" VT keymap?).

> With this approach (deriving the vconsole from the user's default keyboard
> layout only) a user with Czech as primary and US as secondary would get
> keymap cz instead of cz-us-qwertz, losing the ability to toggle to US at the
> LUKS passphrase prompt.
> Are we OK with this regression?

I agree with using the default (primary) layout for the LUKS keymap.
For comment #0 default US 'us, cz(qwerty)' means that keymap should be US.

So, uh, this is complicated. :)

It involves this magic table in systemd-localed:

https://github.com/systemd/systemd/blob/main/src/locale/kbd-model-map

and this logic, with a lot of heuristics:

https://github.com/systemd/systemd/blob/1cf66d1c674ce5928f5b2709629afeaaaf79aee2/src/shared/vconsole-util.c#L418

There is a key point you need to understand in this, which is that the thing shown as "Keyboard layout during boot" is a *kbd* keymap, whereas the layouts you're selecting in GNOME Control Center are *xkb* layouts. What happens behind the scenes between you picking a set of xkb layouts in g-c-c, and anaconda showing you the "Keyboard layout during boot", is that anaconda sends the xkb configuration you picked to systemd-localed and asks it "what kbd keymap best matches this xkb configuration?", which question localed answers using this `find_legacy_keymap` function.

This is trivial in most cases, but it gets complicated when you pick more than one xkb layout. This case happens to be particularly pathological, because the xkb *layouts* for Czech qwertz and Czech qwerty are the same - they're both cz. You get qwerty if the xkb *option* 'qwerty' is set.

So in this case, what happens is this. find_legacy_keymap is working with the kbd-model-map table and an X11Context. It iterates over the kbd-model-map table, one line at a time. For each line, it first looks at the 'xlayout' (column 2) and sees if that string exactly matches the context's 'layout' (which in this case is 'us,cz'). If so, the line gets a score of 10. If not, and the 'xlayout' is a comma-separated string, it *reverses the order of the string* and sees if that matches. If so, the line gets a score of 9. There's some other logic after that which assigns lower scores, but that's irrelevant here because what happens in this case is that two lines get a score of 9, these two:

cz-us-qwertz		cz,us	pc105		-		terminate:ctrl_alt_bksp,grp:shifts_toggle,grp_led:scroll	cs-CZ,cs
cz-qwerty		cz,us	pc105		qwerty,		terminate:ctrl_alt_bksp,grp:shifts_toggle,grp_led:scroll	-

because the 'xlayout' for both of them is 'cz,us', which matches 'us,cz' when reversed.

What do we do when multiple lines score the same on the xlayout match? We go to the tie breaker! The tie breaker's logic is: if the 'xmodel' from the line matches the X11Context's 'model' value, give the line one extra point. If that's true *and* the 'xvariant' from the line matches the X11Context's 'variant' value, give the line another extra point. If that's true *and* the 'xoptions' from the line matches the X11Context's 'options' value, give the line one more extra point.

After that, the line with the best score wins. But if multiple lines are *still* tied, then the *first line encountered* wins, because the `best_matching` layout is only changed when a line is encountered that has a *higher* score than the current `best_matching`, not when a line is encountered that has an *equal* score with the current `best_matching`.

What we would *hope* would happen in this situation is that the tie breaker would get to the 'options' check and give the second line an extra point that the first line didn't get, because the second line has the 'qwerty' option and the first line doesn't. But I think this is not happening, either because the 'model' doesn't match or because the 'variant' is not considered to match, so both lines are scoring the same (either 9 or 10), and the *first* line is winning, so you get cz-us-qwertz as your kbd model, not cz-qwerty.

Now I've typed all that out, I can see why this would happen and one thing we can do to make this better. See, the way this is coded, the 'variant' match won't work. The 'xvariant' in the line is 'qwerty,' - meaning 'there are two layouts; the first has the 'qwerty' variant set, the second has no variant set'. But because your layouts are ordered the other way around - 'us,cz' - your variant string will be ',qwerty', which doesn't match.

In localed, we should remember whether we reversed the layout string to get a match, and if so, we should *also reverse the variant string*. I think that would cause us to pick cz-qwerty in this case rather than cz-us-qwertz, assuming the 'model' matches (I *think* we always set pc105 so it should, but I'll have to test).

You might still say "but I don't want cz-qwerty, I want us". But there's kind of not a perfect answer here, is there? I think it's clearly the case that 'cz-us-qwertz' is not the right match for 'us,cz(qwerty)' *or* 'cz(qwerty),us' so we should fix that. But if you asked every Czech person what the right match for 'us,cz(qwerty)' is, would they all give the same answer? Would they all pick 'us', or all pick 'cz-qwerty'? If you reckon all of them, or like 90+% of them, would pick us, then we might have to try and figure out a way to tweak it. But if the answer might be a 50/50 split or close, we should probably leave it.

Tweaking it would be hard because we absolutely can't say "just only consider the first specified xkb layout". That would break the most common "non-simple" cases, like Russian and Greek and so on. In those cases, the feedback is pretty clear that they want US to be the first xkb layout, because they usually want to type Latin characters after first booting - so they want 'us,ru' not 'ru,us'. But they definitely want 'ru' as their kbd layout, not 'us' - the 'ru' layout types Latin characters by default, and only types Cyrillic characters when switched (most other switched kbd layouts are this way), and that is what they want. They don't want to *only* be able to type Latin characters at the console.

Another thought I have while writing all this down is that, really, we should flip the orders of the xlayouts in kbd-model-map. It dates back a very long way, to a time when we didn't know that switched layout users generally want 'us' first, and system-config-keyboard would actually give you 'ru,us' if you picked 'ru' (back in The Old Days the mapping was the other way around, you picked a *console* layout and this table was used to convert it to an xkb config). Somebody filed a bug...I want to say about 12-15 years ago?...to tell us that was wrong, so we fixed it (I don't remember exactly how things were at the time), but I guess we never actually changed the ordering in this data file.

Changing it now would *probably* cause something weird and unexpected to happen, though; this whole thing is a fragile arcane mess and I hate it. This is why I'm such a big fan of kmscon. :D If we can somehow get kmscon used during initramfs, or have initramfs stage use xkb config in some other way, we could FINALLY stop caring about this mess entirely!

> Is there something to be aware of for switchable keymaps (like Russian)? For "ru,fr" it would be "ru". Which means Anaconda would encrypt the disk with Cyrillic characters and LUKS would unlock them with Cyrillic characters as well (is the the default state of the "ru" VT keymap?).

First off: no, that's not right. ru (and, I believe, almost all other switchable kbd layouts) type *Latin* characters by default. They type native characters when switched. That is, the kbd 'ru' layout is more or less the equivalent of 'us,ru' - not 'ru,us'. I believe if you picked 'ru,fr' right now we would give you 'ru' as the console layout (the part of the logic I skipped over above is that if a line's layouts don't match exactly *or* reversed, we resort to dropping elements until we get a match and then give it a score of 5 or 1 if we get a match, depending on how much stripping happens). Something like 'bg,fr' would be an interesting case, I'd have to think about what would happen there.

Anyhow, an interesting thing here is that sometimes the match for 'XX,us' or 'us,XX' is not the same as the match for 'XX'. I think one reason we don't just consider the first xkb layout, or the first xkb layout that is not 'us', actually *is* Czech!

If you look at https://github.com/systemd/systemd/blob/main/src/locale/kbd-model-map , as well as the two lines for 'cz,us', there is a later line:

cz-lat2			cz	pc105		qwerty		terminate:ctrl_alt_bksp				-

That's the best match for just 'cz'. So if localed were changed to *only* consider the first non-US xkb layout, and your configuration was 'cz,us' or 'us,cz' - with or without qwerty variant - it would, I think, give you 'cz-lat2' as your kbd layout. Not 'cz-us-qwertz' or 'cz-qwerty'. I think we actually wanted to try and make sure that if you pick 'cz,us' or 'us,cz' we give you some kind of switched console layout, not 'cz-lat2'. Interestingly, it looks like Czech is the *only* case like this in the table, so if we think it's fine for basically anyone whose first non-US xkb layout is 'cz' to get the same console layout (whichever one you pick), we could probably simplify the logic. Although there's some other aspects to consider, it gets messy. I really hate touching this code tbh.

Thinking about it gets quite mind-bending as you have to remember this table was written in "the other direction" - for conversion from kbd to xkb. And in fact localed can still do that conversion, and I think some other distros/tools still use it. So that conversion still has to be kept in mind. Also, this table *was the data source* for the tool, originally. You couldn't pick any configuration that *wasn't* in the table.

So - when it was written, the intent of the table was to give you three Czech console layouts to pick from, and give you what we thought was a matching xkb configuration for each one.

In RH-land, at least, we are now using it *backwards*, and *without the table being the data source* - we let you set up almost any arbitrary xkb configuration (not just ones that are in the table), then we try to convert from whatever xkb config you wind up picking to the "best matching" kbd layout, using the table as one source of information. This is obviously a much, much harder thing to do. It's not possible to do it perfectly, and we certainly don't. What we do is try and do the best we can based on historical experience and bug reports, with an emphasis on making sure the most common configurations work, especially the default configurations for major languages (in Fedora/RHEL and other major distros).

BTW, one thing I'm struggling with here is I don't really know the differences between the three Czech kbd layouts in question, as they're documented in Czech. How do they behave, and how similar is each of them to each of these xkb configs?

cz(qwerty),us
us,cz(qwerty)
cz,us
us,cz

Gah, error in my first comment:

> You get qwerty if the xkb *option* 'qwerty' is set.

This should be:

You get qwerty if the xkb *variant* 'qwerty' is set.

AFAIK

cz => Czech layout built according to the typewriter standards, ergo with "qwertz" layout (originated from German typewriters) works like this; the line with numbers normally produces accented letters, such as +ěščřžýáíé. Numbers are accessible via the Shift key. Right Alt (Alt Gr) produces programmatical symbols that would be normally typed with Shift-numbers on a US layout. Those symbols are scattered all around the keyboard, so '@' is RAlt+V, '€' is RAlt+E, '#' is RAlt+3.

cz qwerty => same behaviour, but Y and Z are swapped to be compatible with US keyboard.

cz lat2 => was the ISO2 latin keyboard that we used before UTF8. Today it is probably mapped to one of the above.

thanks...how about specifically the three *kbd* configurations?

cz-lat2
cz-us-qwertz
cz-qwerty

There are text explanations of them - look at /usr/lib/kbd/keymaps/legacy/i386/qwerty/cz-lat2.map.gz , /usr/lib/kbd/keymaps/legacy/i386/qwertz/cz-us-qwertz.map.gz , /usr/lib/kbd/keymaps/legacy/i386/qwerty/cz-qwerty.map.gz - but they're in Czech so I can't read them :) Presumably they all(?) implement *some* kind of way to type all the characters you need, but how do they differ? And how do they compare to switched xkb configs?

Ok, this was a fascinating archaeological investigation. You can see about Czech layouts below. I focus just on the major layouts and ignore specialized layouts (like programming layouts, etc).

== CZ layouts in Windows ==

The two major keyboards used are Czech (meaning qwertz) and Czech qwerty:

* Czech - this is the default, and therefore used by majority of population (80%?). It's based on CZ typewriter layout (based on German layout) and Czech technical norms before PCs existed. When PCs appeared, the need for new characters (@, #, $, \, {, }, [, ], <, >, |, &, etc) appeared due to programming and system commands requiring them. The numbers row was already occupied (by Czech characters úěščřžýáíé and numbers via Shift), so the new characters were assigned to "random" regular keys and triggered by AltGr (the right Alt), e.g. AltGr+V=@ , AltGr+X=#, AltGr+Q=\ , etc. The problem is that you have to remember the position of those characters by heart, because on most keyboards even today they are not marked on the physical keyboard (only the @ sometimes is, but never all the characters). This is also a reason why many people prefer to have two layouts defined (CZ and US) and switch between them when they need to type one of this special characters, because they simply don't remember the CZ combos (my wife used CZ her whole life, and still switches to US for some keys). Furthermore, there's a long-standing problem with the Czech layout with characters ~, ^ and `. Those are being written through a "dead-keys" system, which clashes with an input method in modern Windows apps. You have to press these dead-keys combos twice to make the character appear twice (e.g. ^^) and then delete one of them.

* Czech qwerty - This is a more modern layout, that tried to address the shortcomings of the old Czech layout. Because all physical keyboards (even today) sold in CZ have either US-only labels, or US+CZ labels (but never CZ-only labels), the idea was simple - use AltGr to type the US-layout character you already see on your keyboard. So AltGr+2=@, AltGr+3=#, etc. This layout is currently mostly used by IT and technical people, who need to type both Czech characters and programming characters often, and some gamers (because games often expect Z key to be easily reachable right below WASD). This never became the default in Windows, though, which means its usage is considerably lower (general users just follow the defaults).

Both CZ layouts can write *all* US-layout characters. The difference is only how convenient it is to type them and whether users actually know how.


== CZ layouts in Linux - xkb ==

Instead of replicating the two complete disjoint layouts from Windows, the xkb layouts in Linux decided to use a universal "compromise" solution. Both "cz" (meaning qwertz) and "cz(qwerty)" use almost identical layouts, just with Y and Z swapped, and very tiny other differences (not worth mentioning). Their shared layout covers both CZ and CZ qwerty keymaps from Windows. It duplicates those extra US-layout keys into multiple positions. You can type @ as AltGr+V (Windows CZ) and AltGr+2 (Windows CZ qwerty). Similarly for all the other special characters. Which means both user groups coming from Windows can mostly use their usual way of typing. There are of course some differences in some characters, but for those characters actually used in US and CZ charsets, the differences are minimal. The characters that get minimal usage (like various EU non-CZ accents) are moved to AltGr+Shift area. Furthermore, dead-keys system works perfectly on Linux, not having the same troubles as Czech layout in Windows.


== CZ layouts in Linux - kbd ==

There are lots of CZ kbd layouts, but the xkb->kbd generated ones overshadow a lot of the legacy ones, because they use the same name. So xkb->kbd cz and cz-qwerty overshadow legacy cz and cz-qwerty. The xkb->kbd generated layouts behave the same way as native xkb layouts, printing the same characters, and most importantly not being switchable (not including true US layout and a switch key). As presented above, this doesn't restrict typing any US-layout character, as long as you know how.

Legacy layouts:
* cz - Maps to Windows Czech (qwertz). Overshadowed by xkb cz.
* cz-qwerty - Exactly the same as 'cz', just with Z and Y swapped. Which means this also closely maps to Windows Czech (qwertz), not Windows Czech qwerty, which is completely different. Overshadowed by xkb cz-qwerty.
* cz-us-qwertz - This feels like a predecessor of Windows Czech qwerty, before people figured out how to do it better. It uses a very close layout to Windows Czech qwerty, but for the numbers row and some other characters, you have to hold AltGr+Shift to achieve the same character as with just AltGr in Windows Czech qwerty. That's because AltGr works here simply as a temporary switch to the US layout, and therefore AltGr+2=2, and AltGr+Shift+2=@ (while in Windows Czech qwerty, AltGr+2=@).
* cz-lat2 - This is basically identical layout as cz-us-qwertz, just uses qwerty and starts in the switched state (i.e. a US layout, which can optionally also print czech characters using AltGr).
* cz-lat2-prog - A programming keyboard, niche, let's ignore it for our purposes.
* cz-cp1250 - This is 'cz-lat2' just with byte encoding changed, let's ignore it.

All legacy layouts have a dual CZ+US layout switchable by Pause. cz, cz-qwerty and cz-us-qwertz use Czech characters by default. cz-lat2 uses US characters by default.

Xkb->kbd layouts:
* cz and cz-qwerty - These were already described in the "xkb" section above, and overshadow their legacy variants (meaning when using e.g. "KEYMAP=cz" you get xkb, never legacy). They merge both Windows Czech and Windows Czech qwerty thanks to duplicating keys. They are also not switchable (to US).


== Transitions between xkb and kbd ==

Unfortunately the xkb cz/cz-qwerty layouts don't really have a close match in the kbd layouts. If you transition from legacy cz or cz-us-qwertz to xkb cz, you might feel quite OK, because most keys are where you expect them. But if you transition from xkb cz to one of the legacy layouts, you might feel very bad, because depending on your expectations and what layout you get, you might not be able to find the right keys at all. Especially when you need to unlock your drive in LUKS, where you can't even preview or test your keys, it might be really hard to figure out how to type the password.


== Multiple separate layouts ==

While CZ layouts can write all US layout characters, there are multiple reasons for having a dual CZ+US layout defined and switch between them. The major use cases are programmers/technical users (who need to write special characters often and fast, without AltGr combos each time), gamers (games often map actions to letters and not physical keys, which means number keys don't work for actions if you have a CZ layout) and perhaps people with premium mechanical keyboards (with US-only caps). Those use cases are just a small part of the whole population, however. The majority is likely happy with just a single CZ layout.

This also explains why Linux historically offers Czech kbd layouts in a switchable CZ+US form.

Now, what to do about all this? I think kmscon using xkb layouts and allowing easy switching between multiple of them (the same ones as in GUI!) is a great step forward. We need the same thing to happen in pre-boot and in LUKS especially. That will be the proper solution. But until then...

For Czech, I think this would make sense:
* Don't use any legacy kbd layout, ever. For LUKS, we need to use the same layout that was used to type in the password (i.e. the default system layout) in that exact form. If it was xkb US, use xkb US. If it was xkb cz-qwerty, use xkb cz-qwerty. If you set any other layout (like cz-us-qwertz) because of some heuristics, there's a very high likelihood that some characters will be placed differently. Not just "special" characters @#$%^ etc which need to be typed using AltGr, but even more regular characters like ; and ' are placed differently in this very example.
* For after-boot console, use the same xkb layouts as in GUI, with alt+shift switching (already works thanks to kmscon).

I understand that some languages have different expectations or needs. For the famous 'ru' layout, they can easily use purely Cyrillic layout in GUI and possibly even in LUKS, but not in Linux console, because login names and commands require Latin. There seem to be two options in that case:
a) Make sure non-Latin layouts have a US layout defined as secondary. Allow LUKS password to use non-Latin characters, use xkb-converted language layout during LUKS unlock, and in the after-boot console require users to hit Alt+Shift to toggle to US to be able to log in and run commands. That has the downside that this doesn't apply to pre-boot rescue operations (but the layout can be overriden through boot options, if needed).
b) Make sure non-Latin layouts have a US layout defined as the primary layout. That forces LUKS password to use Latin, make sure US keymap is used during LUKS unlock, and the after-boot console just works fine as well (US by default, native language available through Alt+Shift). In GUI, US will be active by default, but it's trivial to switch the keyboard and the system remembers that.

Is this doable, or do I miss some important point somewhere? Of course this is probably not something that gets changed in time for F45 Final.

> For LUKS, we need to use the same layout that was used to type in the password (i.e. the default system layout) in that exact form. If it was xkb US, use xkb US. If it was xkb cz-qwerty, use xkb cz-qwerty. If you set any other layout (like cz-us-qwertz) because of some heuristics, there's a very high likelihood that some characters will be placed differently.

well, the thing is we don't really have a concept of a layout "for LUKS". anaconda presents it that way to the user because that's the point at which it's most *important* and, in the past, was not *obvious* (because the passphrase is obscured as you type it, and plymouth didn't used to be able to show what layout was loaded).

We only have the concept of "the configured kbd layout". Whatever layout that is gets used whenever kbd is driving things; that used to be during initramfs stage and at VTs after boot, now it's *mostly* only during the initramfs stage (but there are probably likely to be odd cases where you still get a non-kmscon console somehow or other, I'm betting).

If you want to use the xkb layout that was used for typing the password, well, for a start anaconda needs to *know what xkb layout was used for typing the passphrase* - right now it just passes the whole xkb config to localed, because that's what localed is set up to operate on. There's no mechanism to monitor which specific xkb layout is used *for typing the passphrase* when multiple layouts are configured, so anaconda would have to add that.

Honestly, I think Czech is the pathological case here and we should not change everything to suit Czech. Just about every other 'switched layout' case we handle is (AFAIK) a fairly 'simple' one where you *need* a switched layout everywhere - they're all like Russian. Czech, as far as I understand it, seems to be weird because technically you don't *need* a switched layout, right? All Latin / ASCII characters are mapped on the 'Czech' layouts. It's just that some of them are *inconvenient to type*, so some Czech people also configure a US layout they can switch to to make it *easier* to type those characters. That makes it very hard to know what to do when converting.

It occurs to me that the simplest thing to do might be to just use the autoconverted xkb layouts for Czech setups. So, something like: if the first non-US layout in your config is 'cz*', use the autoconverted version of the first layout in your config as the kbd layout. So for 'us,cz' you'd get us. For 'cz,us' you'd get autoconverted cz. I mean, it sounds like none of the available, switched console layouts really matches any xkb config, right? And the switching is not *necessary*? So maybe we just give up on it.

It further occurs to me that it might be very simple to do this: we could just *drop the cz lines from kbd-model-map entirely*. That file is, obviously, not at all comprehensive. It basically exists to try and make 'special cases' work (I think some other lines on it don't need to exist, but that's a conversation for elsewhere). So maybe we just make Czech 'not special'?

I'll experiment with that a bit today.

BTW, I worked on the 'reverse the variant list when we reversed the layout list' thing yesterday but couldn't get it to work because of the awkwardness of trailing commas. I'll bash at it a bit more today.

Hmm, dropping the cz lines also affects conversion in the other direction, though (console to xkb). It would mean any installer etc. that lets people pick those console layout then 'converts' it to xkb, would now not produce a switched xkb config. Not sure if that's desired.

Discussed in 2026-09-28 blocker review meeting: https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-09-28/f45-blocker-review.2026-09-28-16.00.html . This was rejected as a blocker as it's very specific to Czech, requires the user to set a custom config rather than just using the default, the behavior has not changed in 45 (except for consoles now using xkb config due to kmscon, but this should be an improvement), and it not being clear what the "correct" thing to do in this case is anyway and there's a high risk trying to fix it makes something worse / somebody unhappy.

FEDORA-2026-a41a303f79 (anaconda-webui-87-1.fc46) has been submitted as an update to Fedora 46.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-a41a303f79

I linked incorrectly this bug in latest rawhide update, this is not affected anyhow: https://bodhi.fedoraproject.org/updates/FEDORA-2026-a41a303f79#comment-4794525

FEDORA-2026-0bfff6b9ca (anaconda-webui-87-2.fc46) has been submitted as an update to Fedora 46.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-0bfff6b9ca

FEDORA-2026-0bfff6b9ca (anaconda-webui-87-2.fc46) has been pushed to the Fedora 46 stable repository.
If problem still persists, please make note of it in this bug report.