Dear Maintainer,
* What led up to the situation?
I tryed to list the available keymaps.
* What exactly did you do (or not do) that was effective (or
ineffective)?
; localectl list-keymaps
* What was the outcome of this action?
The following message was sent to stderr:
Couldn't find any console keymaps.
* What outcome did you expect instead?
I expected to see a list of the installed keymaps at
stdout.
Other localectl incantations seem to be working just fine:
; localectl list-locales
C.UTF-8
en_US.utf8
More info:
; aptitude show console-data | egrep ^State
State: installed
; aptitude show kbd | egrep ^State
State: installed
; strace localectl list-keymaps 2>&1 | tail -7
lstat("/usr/share/kbd/keymaps", 0x7ffceed35a40) = -1 ENOENT (No such file or directory)
lstat("/usr/lib/kbd/keymaps", 0x7ffceed35a40) = -1 ENOENT (No such file or directory)
lstat("/lib/kbd/keymaps", 0x7ffceed35a40) = -1 ENOENT (No such file or directory)
writev(2, [{"Couldn't find any console keymap"..., 34}, {"\n", 1}], 2Couldn't find any console keymaps.
) = 35
exit_group(1) = ?
+++ exited with 1 +++
The directores /usr/share/kbd/keymaps, /usr/lib/kbd/keymaps and
/lib/kbd/keymaps are not present on my system.
The console-data package seems to install some keymaps on other directories
though:
; dpkg -L console-data | grep keymaps
[...]
/usr/share/keymaps
/usr/share/keymaps/atari
/usr/share/keymaps/atari/atari-de-emacs.kmap.gz
/usr/share/keymaps/atari/atari-us.kmap.gz
/usr/share/keymaps/atari/atari-uk-deadkeys.kmap.gz
/usr/share/keymaps/atari/atari-de.kmap.gz
/usr/share/keymaps/atari/atari-fr.kmap.gz
/usr/share/keymaps/atari/atari-se.kmap.gz
/usr/share/keymaps/atari/atari-us-deadkeys.kmap.gz
/usr/share/keymaps/atari/atari-uk.kmap.gz
/usr/share/keymaps/atari/atari-de-deadkeys.kmap.gz
/usr/share/keymaps/atari/atari-se-deadkeys.kmap.gz
/usr/share/keymaps/amiga
/usr/share/keymaps/amiga/amiga-it.kmap.gz
/usr/share/keymaps/amiga/amiga-es.kmap.gz
/usr/share/keymaps/amiga/amiga-fr.kmap.gz
/usr/share/keymaps/amiga/amiga-de.kmap.gz
/usr/share/keymaps/amiga/amiga-se.kmap.gz
/usr/share/keymaps/amiga/amiga-us.kmap.gz
/usr/share/keymaps/amiga/amiga-sg.kmap.gz
/usr/share/keymaps/i386
/usr/share/keymaps/i386/fgGIod
/usr/share/keymaps/i386/fgGIod/trf.kmap.gz
/usr/share/keymaps/i386/fgGIod/trfu.kmap.gz
/usr/share/keymaps/i386/fgGIod/tr_f-latin5.kmap.gz
/usr/share/keymaps/i386/qwerty
[...]
Fedora (and other distributions as well as systemd upstream) uses "/usr/lib/systemd/systemd-vconsole-setup" and "/etc/vconsole.conf" whereas Debian uses its home-grown solution with systemd and sysvinit. So "localectl list-keymaps" cannot work. It could be patched to output an error; but is this work really worth it?
I don't know if it is worth it.
But whether it is patched to output an error or not, I suggest fixing
localectl(1), as the current version goes like this:
; man localectl
[...]
list-keymaps
List available keyboard mappings for the console, useful
for configuration with set-keymap.
[...]
If Debian's localectl cannot do that, it would be nice to say
so explicidly in the list-keymaps/set-keymap paragraphs, and also
to explain or give some pointers to the Debian "home-grown" solution,
that I am unaware of.
Seems localectl can not recognize kmap.gz file extension, rename those kmap.gz files to map.gz and then it's worked.-------------- OwenChia
The main issue afaics is that Fedora uses the keymap files from kbd [1]. We do have a kbd package in debian, but it only provides binaries but not the keymap data files. The keymap files that are installed on a Debian system seem to come from console-data. console-data seems to be based off ftp://lct.sourceforge.net/pub/lct/ but is nowadays more or less a Debian-only solution. One obvious difference between the keymap files shipped by kbd and console-data is, that kbd uses a map.gz file extension whereas console-data uses kmap.gz. Alastair, Andreas: I'd like to know more about why Debian uses the keymap files from console-data and not the one provided by kbd. If you can shed some light on this, this would be most welcome. Regards, Michael [1] https://git.kernel.org/pub/scm/linux/kernel/git/legion/kbd.git [2] https://tracker.debian.org/pkg/console-data
Am 17.11.18 um 20:32 schrieb Michael Biebl: Something like the attached patch might be sufficient for "localectl list-keymaps". It's completely untested though. There are other places like in find_converted_keymap() [1], which expect a certain directory layout. Michael [1] https://github.com/systemd/systemd/blob/master/src/locale/keymap-util.c#L590
Hi Michael, I'll do my best to fill in details that is how I've understood them (both on fedora and debian side). No promises I've got it right. I however think your description below isn't correct. AIUI Fedora uses the 'ckbcomp' part of console-setup to build static keymaps at build-time. Or atleast that's the impression I got from reading I think it was this: https://bugzilla.redhat.com/show_bug.cgi?id=837292 On the debian side, console-setup will compile the keymap if needed at runtime/bootup. See init scripts in console-setup and trace down what things like /bin/setupcon does. You also want to pay attention to /etc/console-setup/cached*gz files. If these are missing your next bootup will spawn ckbcomp. (And If your filesystem is read-only you'll get that on every boot.) (I agree with the comments on the rh bugzilla above and would personally prefer the fedora solution, but when this has been discussed in the past objections where that we can't possibly generate all possible combinations of all keymaps, modifiers, etc. I'm skeptical about letting 99.9% users pay the penalty to cater to the 0.1% if even that many.) I don't think anyone (except maybe slackware) uses the data files from kbd. I don't think console-data is relevant for most installs. As mentioned console-setup will generate the keymap if needed on the fly on regular debian installs. Keep in mind that there's lots of legacy stuff in debian, because at some point people wanted to make it possible for multiple different competing solutions. At the time it seems people where very eager about console-tools - which ultimately faded away and aren't part of debian anymore. As already mentioned, I don't think this statement is true. HTH. Regards, Andreas Henriksson
Am 17.11.18 um 20:58 schrieb Andreas Henriksson:
What I did was run strace on localectl in a Fedora 29 VM which showed
that it accessed the files in /usr/lib/kbd/keymaps/, so I ran
# rpm -qf /usr/lib/kbd/keymaps/
kbd-misc-2.0.4-9.fc29.noarch
# dnf info kbd-misc
Last metadata expiration check: 2 days, 7:10:31 ago on Thu Nov 15
15:06:02 2018.
Installed Packages
Name : kbd-misc
Version : 2.0.4
Release : 9.fc29
Arch : noarch
Size : 2.4 M
Source : kbd-2.0.4-9.fc29.src.rpm
Repo : @System
From repo : fedora
Summary : Data for kbd package
URL : http://www.kbd-project.org/
License : GPLv2+
Description : The kbd-misc package contains data for kbd package -
console fonts,
: keymaps etc. Please note that kbd-misc is not helpful
without kbd.
Thanks for your reply.
Regards,
Michael
For the record, the keymaps fedora ships in the kbd package are not from kbd upstream. They are built using ckbcomp (from console-setup) at package build time: https://src.fedoraproject.org/rpms/kbd/blob/master/f/kbd.spec#_147 Regards, Andreas Henriksson
Sorry for the delay; some history: I took over maintainership of console-tools / console-data / console-common from Yann Dirson / Martin Michlmayr in 2002. They were a fork of the (then) moribund kbd package : they added some extra functionality and console fonts / keymaps for other architectures and locales. Yann was the upstream author of console-* . console-common was a wrapper package that allowed the user to use either 'kbd' or 'console-tools' and still use the extra files. My work was primarily bugfixing and adding udeb support for the Debian Installer, which was my primary Debian work at that time. console-* themselves fell moribund, and later 'kbd' was revived. I spent some time merging the console-* packages back into kbd, and kbd took back over as the primary, along with the "new" console-setup. I still in principle maintain console-data and console-common, mostly fixing egregious bugs, but they are deprecated in favour of kbd / console-setup. (There are still some data files present that are not, I believe, present in kbd, but do not have the time /hardware to confirm. Ideally, console-data and console-common would be obsoleted and removed from Debian. Regards Alastair
Yes, hello, hello. It is now 2023...
2025 and still counting. This thing is not even fixed for Trixie -.-" So this is how debian - the most sTaBLe - works, and linux in general: oh please please, we beg you, report bugs, so we will fix them.. 12+ and 20+ years still open active bugs exists. WAKE THE HELL UP AND DO YOUR WORK! Sent with [Proton Mail](https://proton.me/mail/home) secure email.
[silensyspwnz] Terribly sorry to hear about your experience. I understand from your message you have paid quite a lot to get people to work for you. You will of course get a complete refund for everything you have paid to receive the Debian operating system.
Hi there, there are some voices on the internet that claim that there is no workaround. That's not quite true. locatectl simply doesn't recognize the files, because they're named "*.kmap.gz", but it only looks for "*.map.gz". Don't be embarrassed, I'm sure it was difficult to notice, after staring at the source code for decades. The workaround is nearly trivial: cd /usr/share/keymaps/i386/qwertz ln -s de-latin1-nodeadkeys.kmap.gz de-latin1-nodeadkeys.map.gz # And again for all the keymaps you're interested in. An actual fix would be to update the internal glob in localectl, or wherever the function lives that decides whether a filename is interesting or not. Cheers, derandere