Bug 1955793

yeah, the 'fi' layout is in kbd-legacy, so this is likely the same as 1955162 . If you install from a traditional installer image (Server DVD or netinst) and enable a remote repository during install, it will likely work, as the kbd-legacy package will be available to the installer. Sorry for the trouble.

*** This bug has been marked as a duplicate of bug 1955162 ***

As a note to anyone who might try the above, installing with a netinst image does not help.

Huh. It really ought to. I wonder if there's a different problem for Finnish? I'll try it out and see. Sorry for the trouble.

I think it might be another issue with the Finnish keymap altogether after all. This is because I installed kbd-legacy and rebooted, but that didn't fix the issue. I'm still trying to figure out what it could be. Sorry for the misleading initial report.

It's okay, I might have been too quick to assume it was the same thing. I'll try a Finnish install today and see if I can work anything out. Let's un-dupe this for now.

Ahh, okay. So, I see what's going on here. Finnish is a bit of a special case.

So the whole story here is that we generally try to use converted xkb layouts for console layouts, rather than the "legacy" console layouts that are in the kbd source tarball. But this doesn't work for what are referred to as "switched" layouts, for languages which have a non-Latin alphabet and where the normal way to type is to 'switch' between a map for inputting Latin characters and one for inputting native characters. xkb-converted layouts don't work in this case because they only allow input of native characters, they have no other 'map' for inputting Latin characters (because in X you're expected to switch between the native layout and the 'us' layout, whereas at the console both maps are encoded into a single layout on different 'levels').

So in the kbd spec, we auto-convert all the xkb layouts, but then we delete any that can't input the ASCII character U+0041. The expectation is then that the identically-named layout from the kbd-legacy package will then be used for that case.

The problem we had for these 'switched' layouts was that anaconda didn't know to install kbd-legacy when one would be used. So we fixed that in anaconda by having anaconda use a property langtable provides that encodes the same logic:

        if self.vc_keymap and not langtable.supports_ascii(self.vc_keymap):
            requirements.append(Requirement.for_package(
                package_name="kbd-legacy",
                reason="Required to support the '{}' keymap.".format(self.vc_keymap)
            ))

so basically "if the xkb layout we picked doesn't support ASCII input, install kbd-legacy".

But...Finnish is different. It's not a switched layout, exactly. The xkb 'fi' layout *does* support ASCII input. However, there was a bug filed back in 2014 which said the converted 'fi' xkb layout is still not the best choice for console input, and requested the 'legacy' layout be used instead: https://bugzilla.redhat.com/show_bug.cgi?id=1117891

So, we did that. After the xkb conversion happens and the "delete all converted layouts that can't input ASCII" filter runs, there's a specific stanza in the kbd spec which renames the xkb-converted 'fi' layout to 'fi-kotoistus'. So in the 'kbd' package, there is no 'fi' layout. There is only 'fi-kotoistus' and several other variants. The only layout actually called 'fi' is in kbd-legacy.

However, because the 'fi' xkb layout *does* allow ASCII input, the bit we added to anaconda doesn't fire. We don't add kbd-legacy to the package set to be installed.

So, the fix for Finnish in the end will have to be extending the anaconda check a bit to just explicitly add kbd-legacy if the layout is called 'fi', I think.

Sorry again for the trouble :(

That's okay, these things happen.

TL;DR installing kbd-legacy _and_ running "sudo dracut --force" fixes the issue

I discovered that installing kbd-legacy did fix something after all: after successfully booting and then going into a virtual console, the keys all worked as expected. So then it was only during boot that the keymap wasn't working right. The error message I mentioned earlier seemed to say something about dracut, and after searching for it, I found the command "sudo dracut --force". Running that after installing kbd-legacy has now fixed the problem during password entry as well.

I suppose the installation media still can't be fixed, but at least now if someone else runs into the same problem, here's the solution.

oh, yeah, I should've mentioned that in the commonbugs entry. My bad. Indeed during decryption we're in the initramfs environment - obviously, since the main system is still encrypted! - so that needs updating for encrypted systems. I'll enhance the commonbugs page.

*** Bug 1967457 has been marked as a duplicate of this bug. ***

Thank you very much for your efforts around this, Adam.

There's been some developments since 2014 when BZ#1117891 was discussed. The national standard SFS 5966 has been revised and SFS 5966:2019 does not require AltGr+Space to produce non-breaking space anymore. That change is now reflected in all xkeyboard-config and kbd Finnish keymaps, so using any them on Linux console shouldn't cause nasty surprises anymore.

I guess otherwise we could leave things as-is but due to this package dependency should we now consider changes so that kbd-legacy would not be required with Finnish keymap? IOW, we could at least try to reduce (or perhaps do away completely) special-casing around Finnish console keymaps.

Thanks.

Thanks Marko! Honestly, when it comes to keymap/input method stuff, my approach is mostly to trust native users when it comes to the question of how it ought to work, and focus more on the question of how it actually works and, if it doesn't work the way it should, why not :D If we want to change how things work for a given language, that should probably be done between whoever wants to propose it (ideally including some native users who can say it's a sensible idea) and anaconda team, and possibly langtable (https://github.com/mike-fabian/langtable/tree/master/langtable ) devs if langtable is involved.

Your approach makes a lot of sense :)

Since I've been involved with the Finnish locale and keymaps for a few decades already, I'll have a look at these details in the coming weeks and file new BZs as needed, hopefully completing the effort.

For completeness sake, here are the different components that have required updates from Finnish keyboard (and locale) point of view in the past:

Higher level:

* National standards (SFS 5966 and SFS 5966:2019 define the new keyboard layout for use in Finland)
* CLDR (localization related)

Upstream projects:

* glibc (locale)
* kbd (console keymaps)
* xkeyboard-config (desktop keymaps)
* libX11 (compose sequences for desktop)
* langtable (keyboard and localization defaults)

Fedora specific:

* anaconda (installer)

There are also components that deal with the language itself, like voikko (https://voikko.puimula.org/) and to certain extent ibus-typing-booster but, like translations of individual packages, those are more user-related than the above listed upstream/Fedora related system-related components.

The above list of all the pieces of the puzzle should be pretty complete unless I forgot something.

Thanks.

I have now reviewed all the above components and otherwise everything else was in shape.

Since the current default Finnish xkb keymap is safe to use on console as well it's best that we'll just remove the special casing. I have submitted a BZ and a patch to do so in kbd.rpm:

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

Once we have kbd.rpm with that change as part of the distribution I think we could revert this Anaconda change:

https://github.com/rhinstaller/anaconda/commit/b9c33400831024394e351753d7e413643f6a4757

Let me know if you have any concerns around this or suggestions when exactly we should revert this patch? I think perhaps we should create a new BZ for it?

Thanks.

This all looks good to me, I think. I think it should be OK to merge it for F35 after Beta, and Rawhide just whenever. Yes, once the kbd change is done, a new bug for anaconda would be clearer. I guess we should close this one, in fact, as we did make the change to fix this bug at the time.

oh, if you don't get any action on the kbd change, I can do it (I'm a provenpackager).

Thanks Adam! For reference, the kbd change got applied already (https://bugzilla.redhat.com/show_bug.cgi?id=2001787, https://src.fedoraproject.org/rpms/kbd/c/918f776f5df0b6ab34198a761efec864f2745a34) and I've just filed a new Anaconda bug here: https://bugzilla.redhat.com/show_bug.cgi?id=2003937.

Four months later.
British English isn't legacy. 
Please restore uk keyboard mapping to the kbd package.
Otherwise, basic installations don't with without kbd-legacy, which isn't installed automatically since 2019.

The British English layout is called 'gb', not 'uk', and it's in kbd-misc:

[adamw@xps13k ~]$ rpm -qf /usr/lib/kbd/keymaps/xkb/gb.map.gz 
kbd-misc-2.4.0-8.fc36.noarch

what problem are you seeing with it?

You are incorrect. 

My /etc/vconsole.conf reads
KEYMAP=uk.

Across multiple other working distros and has done for decades without problems. I'm not Ukrainian, btw. You're thinking of X GUIs or the locale.conf LANG=en_GB and not consoles.

With Fedora kbd and kbd-misc installed, by group @"Minimal Install" I believe, I'm not getting the uk keymap.

#localectl list-keymaps | grep uk
gb-dvorakukp

Installing kbd-legacy gives the uk keymap from the above grep.
atari-uk-falcon
dvorak-uk
dvorak-ukp
gb-dvorakukp
mac-uk
sunt5-uk
sunt5-uk
uk

Maybe I misunderstood, are you saying you've changed the uk KEYMAP to be called gb?

Well, this is actually kind of an interesting question now I look into it!

Keyboard layouts are kind of infamously messy in Linux. We actually have two major sets of keyboard layouts:

* The xkb ones which originate from XFree86 / X.org - https://github.com/freedesktop/xkeyboard-config
* The kbd ones, which are console layouts and as old as the hills - https://github.com/legionus/kbd

You can't natively use kbd layouts in X.org/Wayland graphical environments, or xkb layouts at the console. For many many years Fedora by default installed both sets of layouts, and tried to select an appropriate console layout and (set of) xkb layout(s) for the language selected at install time based on a data table that was part of the installer (I think it moved to systemd/localed after a while).

Some time ago, we changed the approach slightly in an attempt to make things slightly more consistent. We now automatically convert all the xkb layouts to kbd layouts at the time of building the kbd package, and install those to /usr/lib/kbd/keymaps/xkb as part of the package 'kbd-misc'. Those are the default console layouts, rather than the ones from the kbd project. The layouts from the kbd project itself are moved to /usr/lib/kbd/keymaps/legacy as part of the package 'kbd-legacy', and usually not installed by default. These days the data source for deciding what layout configuration to use for what languages is the 'langtable' project - https://github.com/mike-fabian/langtable .

The fly in the ointment with this system turned out to be languages/scripts where 'layout switching' is normal, which is kind of what this bug is about. But that's not relevant to the UK English case. What's more interesting to the UK English case is that the xkb layout for a UK English keyboard is called 'gb', while the kbd layout is called 'uk'. So in Fedora there are two UK English console layouts - there's /usr/lib/kbd/keymaps/xkb/gb.map.gz in kbd-misc, converted from the xkb 'gb' layout, and /usr/lib/kbd/keymaps/legacy/i386/qwerty/uk.map.gz in kbd-legacy, which is the native kbd layout. The 'uk' one is not installed by default if you do a fresh UK English install. I've just tested, and both those layouts do work (act like a UK keyboard) if you have them installed. On a fresh install, both console and graphical input configurations should be set to use the 'gb' layout - I think I'll go and test that now.

So effectively, yeah, at some point we changed the default console layout for UK English in Fedora from 'uk' to 'gb'. This should have been handled on upgrades of older systems - at the time we did it, we set it up so kbd-legacy would be installed on upgrade of existing systems, so they would have kept using the same 'uk' map. It's only left out of fresh installs. This happened a long time ago, though: nearly 9 years ago. The conversion was added in January 2013 - https://src.fedoraproject.org/rpms/kbd/c/4cc3010 - and kbd layouts were moved to 'kbd-legacy' in May 2013 - https://src.fedoraproject.org/rpms/kbd/c/fb41a90 .

The whole locale/keymaps thing is a mess I agree.

I've only just re-discovered that Fedora have glibc suite for locales - I'd forgotten - rather than generating the locales a la ArchLinux etc. Those are very helpful!

It's actually helpful to be able to replace uk with gb; uk is an anomaly compared with the locales being en_GB etc. ArchLinux has a news feed, including RSS, for changes to packages, I don't think Fedora has the same does it? It would be ideal for this UK->GB change.

I'm against too much set-up being scripted in the package install. Debian suffers for that.

Apologies for my mistaken outburst.
Can someone let me know if there is a feed for package changes like this please?

Fedora's system for tracking major changes is called, well, Changes:

https://docs.fedoraproject.org/en-US/program_management/changes_policy/

there isn't a news feed for it, exactly, but you can see the accepted changes for each release on the wiki, e.g. here are 35's:

https://fedoraproject.org/wiki/Releases/35/ChangeSet

Each release also has release notes which cover the major changes, here again are f35's:

https://docs.fedoraproject.org/en-US/fedora/f35/release-notes/

The switch to using xkb-generated layouts by default was I think mentioned in the release notes for whatever release it happened in, but it may well be that it didn't go into so much detail as to mention something specific like this (it may not even exactly have been noticed by the docs writers). It's hard to capture *everything*. I don't know if we do a better or worse job of it than Arch, overall, as I'm not familiar with Arch's nes feed :)

Note the stuff I mentioned happening in the kbd package happens at package *build* time, not install time. It's in the package spec file:

https://src.fedoraproject.org/rpms/kbd/blob/rawhide/f/kbd.spec

The xkb->kbd conversion happens around line 157. You can see various other things we have to fiddle with to deal with all sorts of other little issues for specific languages and keymaps there too. The whole area is honestly a mess, but it's kind of difficult to do much to make it better, at the very least unless someone finally implements a way for xkb-style layouts to be used at consoles (there has been talk about this for at least a decade, but it never seems to happen).