Not sure exactly where the problem is here, could be systemd-localed, could be langtable, could be the kbd generation stuff. But here's what happens: I install Fedora 20 Beta (RC5 has been declared go) DVD. In installation, I add the 'English (UK)' keyboard layout and put it at the top of the list, above 'English (US)'. When I boot the installed system, the US keymap is used for encryption passphrase entry (if the disk is encrypted) and for all VTs. UK keymap is used for X. In the logs, I see: systemd-vconsole-setup[56]: /usr/bin/loadkeys failed with error code 1. systemd-vconsole-setup[56]: cannot open file uk which is obviously the problem. There is no 'uk' file in /lib/kbd/keymaps/xkb , but there are 'uk.map.gz' files in /lib/kbd/keymaps/i386/qwerty and /lib/kbd/keymaps/legacy/i386/qwerty . /etc/vconsole.conf states: KEYMAP="uk" /proc/cmdline contains: vconsole.keymap=uk and /etc/X11/xorg.conf.d/00-keyboard.conf contains: Option "XkbLayout" "gb,us" Note 'gb', not 'uk'. There is a /lib/kbd/keymaps/xkb/gb.map.gz , so one thing that we could say is 'wrong' here is that systemd is still using /usr/share/systemd/kbd-model-map - I think that's what results in the translation of 'gb' (xkb) to 'uk' (old kbd). Since we implemented the xkb-maps-for-kbd plan in Fedora 20, I don't think localed should still be using kbd-model-map, and I thought I'd filed a bug for that before, but apparently not. Still, I don't know if it'd be expected that one of the 'uk' layouts in the other directories ought to work in this scenario.
Proposing as a Final blocker for the encryption passphrase / password entry problems when the keymap is not what you expect it to be.
langtable doesn’t have any “uk” keyboard layout, only “gb” exists.
anaconda uses systemd-localed for a suggestion which console keymap it should use in place of an X layout. As Adam has already pointed out in the description of this bug, systemd-localed should suggest the converted 'gb' keymap for the 'gb' X layout.
Why does loadkeys fail if gb.map.gz files do exist in other subdirs? Does loadkeys run through langtable now or what?
Leslie Satenstein reports a similar problem for the French Canadian keyboard, see https://bugzilla.redhat.com/show_bug.cgi?id=892110#c32
And I can reproduce this using the German keyboard layout: - Japanese install with the German keyboard layout added in anaconda and moved to top priority (the layout before adding the German one is the Japanese one, *not* US English). - In the gnome session, the German keyboard is selected by default and works, in the virtual terminals the layout is US English. Tested on Fedora-20-Beta-RC5-x86_64-netinst.iso
[mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ journalctl -b | grep loadkeys 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd-vconsole-setup[70]: /usr/bin/loadkeys failed with error code 1. [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$
FYI, I did a new F20 install, tty2-tt66 (consoles) do not follow the preferred settings of anaconda keyboard selection. Every time I reboot, In place of the CA(FR) keyboard, I get the USA english. I have only one keyboard per system. I do my correction via system-config-keyboard. Should this approach now be the norm?
The "de" keyboard has apparently been written correctly to the config file: [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ cat /etc/vconsole.conf KEYMAP="de" FONT="latarcyrheb-sun16" [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ And when I now execute this: [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo /usr/lib/systemd/systemd-vconsole-setup [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ Then the German keyboard layout is set correctly on the consoles.
But after a reboot, it is broken again.
mike: then it would help to have more context for your loadkeys failure during startup. I did 'grep -5', note.
More context: 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting Swap. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Reached target Swap. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting Local File Systems. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Reached target Local File Systems. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd-vconsole-setup[70]: /usr/bin/loadkeys failed with error code 1. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Started Create list of required static device nodes for the current kernel. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting Create static device nodes in /dev... 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins dracut-cmdline[66]: dracut-20 (Heisenbug) dracut-034-19.git20131021.fc20 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Started Create static device nodes in /dev. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd-vconsole-setup[70]: cannot open file de 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Started Setup Virtual Console. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Started dracut cmdline hook. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Started dracut pre-udev hook. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting udev Kernel Device Manager... 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd-udevd[179]: starting version 208 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Started udev Kernel Device Manager. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Started dracut pre-trigger hook. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting udev Coldplug all Devices... 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Started udev Coldplug all Devices. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting dracut initqueue hook... 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting Show Plymouth Boot Screen... 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting System Initialization. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Reached target System Initialization. 11月 09 14:01:58 Fedora-20-Beta-RC5-x86_64-netins kernel: e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI Strange things: - Why are there 2 lines from systemd-vconsole-setup[70], one with “loadkeys failed with error code 1” and one with “cannot open file de”? - Are the static device nodes relevant? Do they have to be there when systemd-vconsole-setup is called? (Because it works when I call systemd-vconsole-setup manually later, maybe it is called too early during booting when not everything it needs is available yet?) - And why “cannot open file de” although it seems to be there, even several versions, one of them probably converted from the X11 xkb files: [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ find /lib/kbd -name "de.map.gz" /lib/kbd/keymaps/legacy/i386/qwertz/de.map.gz /lib/kbd/keymaps/i386/qwertz/de.map.gz /lib/kbd/keymaps/xkb/de.map.gz [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$
Manually calling loadkeys after the system is booted also works and shows which files are loaded: [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo loadkeys de Loading /lib/kbd/keymaps/i386/qwertz/de.map.gz [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo loadkeys gb Loading /lib/kbd/keymaps/xkb/gb.map.gz [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo loadkeys uk Loading /lib/kbd/keymaps/i386/qwerty/uk.map.gz [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$
[mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo loadkeys foobar cannot open file foobar [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo loadkeys /tmp/foobar cannot open file /tmp/foobar [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$
yeah, this is starting to look more like a race than a case of trying to open a map that doesn't exist.
I added "debug" to the kernel command line to see more in the journal: 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Forked /usr/bin/mkdir as 69 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: kmod-static-nodes.service changed dead -> start-pre 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: ConditionPathExists=/dev/tty0 succeeded for systemd-vconsole-setup.service. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting Setup Virtual Console... 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: About to execute: /usr/lib/systemd/systemd-vconsole-setup 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Forked /usr/lib/systemd/systemd-vconsole-setup as 70 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: systemd-vconsole-setup.service changed dead -> start 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: ConditionPathIsReadWrite=/sys succeeded for systemd-udevd-kernel.socket. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting udev Kernel Socket. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: systemd-udevd-kernel.socket changed dead -> listening 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Job systemd-udevd-kernel.socket/start finished, result=done 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Listening on udev Kernel Socket. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: ConditionPathIsReadWrite=/sys succeeded for systemd-udevd-control.socket. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting udev Control Socket. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[69]: Executing: /usr/bin/mkdir -p /run/tmpfiles.d 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: systemd-udevd-control.socket changed dead -> listening 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Job systemd-udevd-control.socket/start finished, result=done 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Listening on udev Control Socket. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting Sockets. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: sockets.target changed dead -> active 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Job sockets.target/start finished, result=done 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Reached target Sockets. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting Swap. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: swap.target changed dead -> active 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Job swap.target/start finished, result=done 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Reached target Swap. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Starting Local File Systems. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: local-fs.target changed dead -> active 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Job local-fs.target/start finished, result=done 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Reached target Local File Systems. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Set up jobs progress timerfd. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Set up idle_pipe watch. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Received SIGCHLD from PID 65 (n/a). 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[70]: Executing: /usr/lib/systemd/systemd-vconsole-setup 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Received SIGCHLD from PID 69 (mkdir). 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Got SIGCHLD for process 69 (mkdir) 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Child 69 died (code=exited, status=0/SUCCESS) 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Child 69 belongs to kmod-static-nodes.service 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: kmod-static-nodes.service: control process exited, code=exited status=0 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: kmod-static-nodes.service got final SIGCHLD for state start-pre 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: About to execute: /usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Forked /usr/bin/kmod as 75 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: kmod-static-nodes.service changed start-pre -> start 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Accepted connection on private bus. 11月 12 12:25:40 Fedora-20-Beta-RC5-x86_64-netins systemd[1]: Accepted connection on private bus.
Mike, does manually running loadkeys work to fix the issue after boot? Trying to update F20 Common Bugs [1] and I'm looking for a workaround. I couldn't get the keymap to change with a minimal install via either loadkeys or localectl --set-keymap. Thanks. [1] https://fedoraproject.org/wiki/Common_F20_bugs
(In reply to Mike Ruckman from comment #17) > Mike, does manually running loadkeys work to fix the issue after boot? > Trying to update F20 Common Bugs [1] and I'm looking for a workaround. I > couldn't get the keymap to change with a minimal install via either loadkeys > or localectl --set-keymap. > > Thanks. > > [1] https://fedoraproject.org/wiki/Common_F20_bugs Yes, after booting, something like “sudo loadkeys de" or "sudo loadkeys uk" works. What also works after booting is sudo systemctl restart systemd-vconsole-setup.service That calls loadkeys. When done after booting it works, during booting it fails, I don’t yet know why.
I added some debug output to vconsole-setup.c and found this in “journalctl -b” after doing that: 11月 13 09:46:54 Fedora-20-Beta-RC5-x86_64-netins systemd-vconsole-setup[70]: stat /lib/kbd/keymaps/xkb failed 11月 13 09:46:54 Fedora-20-Beta-RC5-x86_64-netins systemd-vconsole-setup[70]: stat /lib/kbd/keymaps/i386 failed 11月 13 09:46:54 Fedora-20-Beta-RC5-x86_64-netins systemd-vconsole-setup[70]: stat /lib/kbd/keymaps/i386/qwertz failed 11月 13 09:46:54 Fedora-20-Beta-RC5-x86_64-netins systemd-vconsole-setup[70]: stat /lib/kbd/keymaps/xkb/de.map.gz failed 11月 13 09:46:54 Fedora-20-Beta-RC5-x86_64-netins systemd-vconsole-setup[70]: stat /lib/kbd/keymaps/i386/qwertz/de.map.gz fail ed I.e. the /lib/kbd/keymaps/xkb and /lib/kbd/keymaps/i386 directories do not exist yet when systemd-vconsole-setup.service is started during booting.
[mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ diff -u /usr/lib/systemd/system/systemd-vconsole-setup.service.orig /usr/lib/systemd/system/systemd-vconsole-setup.service --- /usr/lib/systemd/system/systemd-vconsole-setup.service.orig 2013-11-12 11:41:47.508149606 +0100 +++ /usr/lib/systemd/system/systemd-vconsole-setup.service 2013-11-13 08:56:41.110581780 +0100 @@ -13,6 +13,8 @@ After=systemd-readahead-collect.service systemd-readahead-replay.service Before=sysinit.target shutdown.target ConditionPathExists=/dev/tty0 +ConditionPathExists=/usr/bin/loadkeys +ConditionPathExists=/lib/kbd/keymaps/xkb [Service] Type=oneshot [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$
The change in comment#20 makes it work during booting. (I do *not* yet know whether it already works then when the encryption passphrase is entered, if I understand it correctly, the change in comment#20 delays starting of systemd-vconsole-setup.service until /lib/kbd/keymaps/xkb exists. I don’t yet know whether that is too late for entering the encryption passphrase).
I tested that +ConditionPathExists=/usr/bin/loadkeys is not necessary, +ConditionPathExists=/lib/kbd/keymaps/xkb alone is enough to make it work. (I tested also "uk" by editing /etc/vconsole.conf to contain KEYMAP="uk" and by editing the kernel command line in grub to have vconsole.keymap=uk: [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11.7-300.fc20.x86_64 root=/dev/mapper/fedora_fedora--20--beta--rc5--x86_64--netins-root ro rd.lvm.lv=fedora_fedora-20-beta-rc5-x86_64-netins/root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora_fedora-20-beta-rc5-x86_64-netins/swap vconsole.keymap=uk rhgb quiet LANG=ja_JP.UTF-8 [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ Then, the British English keyboard also works automatically when the booting has finished. (I still have not tested the encryption passphrase thing!)
I did 2 more installs today and to my great surprise, I could not reproduce the problem anymore with these 2 installs. 1st try: ======== - Install in British English, keyboard not changed (defaults to British English keyboard then) - I did choose to encrypt the disc and did choose a password which where the difference between the US English and the British English keyboard would make a difference and I would surely notice if I got an US English layout during input of the password when booting - for everything else I used the defaults. - After the installation had finished and I rebooted, I could enter the password for the encrypted disc just fine, apparently I had the British English keyboard active at that time - I waited for the boot to finish and when I saw gdm, I switched to a virtual console and logged in and tested the keyboard layout -> British English layout was active!!! 2nd try: ======== - Install in Japanese - add British English keyboard layout and make it the top priority. - ... continue as in 1st try ... ... and this worked as well! Weird!! Has that been fixed? I installed using the same Fedora-20-Beta-RC5-x86_64-netinst.iso iso-image which I used in comment#6. But as it is a netinstall, this might use packages which have been updated since comment#6, i.e. updated between 2013-11-09 and today. Could that be an explanation?
Maybe the same issue as bug 1026065 ?
(In reply to Mamoru TASAKA from comment #24) > Maybe the same issue as bug 1026065 ? Maybe. "sudo loadkeys jp106" works for me after boot on the installation I mentioned in comment#23 “2nd try”. And "sudo loadkeys de" or "sudo loadkeys uk" also worked for me in the installation where the keyboard layout did not work by default after booting (see comment#18)
I did a third installation, in Japanese with German keyboard layout added to highest priority and *without* encryption of the disc (from the same Fedora-20-Beta-RC5-x86_64-netinst.iso) and again it worked fine. After the installation, I could also switch keyboard layouts like this without problem: [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo loadkeys jp Loading /lib/kbd/keymaps/xkb/jp.map.gz [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo loadkeys jp106 Loading /lib/kbd/keymaps/i386/qwerty/jp106.map.gz [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$ sudo loadkeys de Loading /lib/kbd/keymaps/xkb/de.map.gz [mfabian@Fedora-20-Beta-RC5-x86_64-netins ~]$
Now I did a DVD install from Fedora-20-Beta-x86_64-DVD.iso. (Japanese, German keyboard top priority). Does *not* work. ("sudo loadkeys jp106" after booting works correctly on this installation as well, i.e. I could never reproduce the problem Mamoru TASAKA reports in bug#1026065) As it worked 3 times today with 3 different netinstalls but did not work with the DVD install, I guess that something which changed in the updated packages pulled in by the netinstall fixes it.
your 'conditionpathexists' approach does not look correct, btw. a) it's not what that's supposed to be used for, and b) if the 'condition' is not fulfilled, systemd does not wait for it to be fulfilled, it simply doesn't start the service at all - so it wouldn't actually fix the bug.
(In reply to Adam Williamson from comment #28) > your 'conditionpathexists' approach does not look correct, btw. a) it's not > what that's supposed to be used for, and b) if the 'condition' is not > fulfilled, systemd does not wait for it to be fulfilled, it simply doesn't > start the service at all - so it wouldn't actually fix the bug. Yes, I don’t yet understand at all what is going on here. Somehow that change made it work, but as you say this is probably only an accident because I did not understand the meaning of that ConditionPathExists=/lib/kbd/keymaps/xkb correctly.
(In reply to Mike FABIAN from comment #27) > Now I did a DVD install from Fedora-20-Beta-x86_64-DVD.iso. > > (Japanese, German keyboard top priority). > > Does *not* work. > > ("sudo loadkeys jp106" after booting works correctly on this installation > as well, i.e. I could never reproduce the problem Mamoru TASAKA reports in > bug#1026065) > > As it worked 3 times today with 3 different netinstalls but did > not work with the DVD install, I guess that something which changed > in the updated packages pulled in by the netinstall fixes it. On that DVD install, journalctl -b contains: 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting Setup Virtual Console... 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting Swap. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Reached target Swap. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting Local File Systems. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Reached target Local File Systems. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Started Create list of required static device nodes for the current kernel. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting Create static device nodes in /dev... 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Started Create static device nodes in /dev. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd-vconsole-setup[70]: sh: gzip: command not found 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is dracut-cmdline[66]: dracut-20 (Heisenbug) dracut-034-19.git20131021.fc20 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Started Setup Virtual Console. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Started dracut cmdline hook. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Started dracut pre-udev hook. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting udev Kernel Device Manager... 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Started udev Kernel Device Manager. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Started dracut pre-trigger hook. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting udev Coldplug all Devices... 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd-udevd[182]: starting version 208 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Started udev Coldplug all Devices. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting dracut initqueue hook... 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting Show Plymouth Boot Screen... 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Starting System Initialization. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is systemd[1]: Reached target System Initialization. 11月 14 09:01:06 Fedora-20-Beta-RC5-x86_64-DVD.is kernel: e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI What? gzip not found? So something is really weird at the time when this vconsole setup is attempted.
(In reply to Adam Williamson from comment #28) > your 'conditionpathexists' approach does not look correct, btw. a) it's not > what that's supposed to be used for, and b) if the 'condition' is not > fulfilled, systemd does not wait for it to be fulfilled, it simply doesn't > start the service at all - so it wouldn't actually fix the bug. And on the DVD install I tried above (where I saw the “systemd-vconsole-setup[70]: sh: gzip: command not found” in journalctl), doing that conditionpathexists change did *not* fix the problem, so you are right, it was only a weird accident that it seemed to fix the problem on my netinstall of RC5 installed on 2013-11-09.
sudo systemctl restart systemd-vconsole-setup.service
sudo systemctl restart systemd-vconsole-setup.service after booting fixes the problem temporarily on the DVD install as well. ("restart", not "start", "start" does not fix it).
Discussed in 2013-11-14 Blocker Review Meeting [1]. Voted as an AcceptedBlocker as this violates alpha criterion "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" [2] when it comes to booting from an encrypted drive with one of the affected keymaps. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-14/ [2] http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Post-install_requirements
The problem still occurs on Fedora-20-TC1-x86_64-netinst.iso: [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ journalctl -b | grep vconsole 11月 15 11:40:33 Fedora-20-TC1-x86_64-netinst.iso kernel: Command line: BOOT_IMAGE=/vmlinuz-3.11.8-300.fc20.x86_64 root=/dev/mapper/fedora_fedora--20--tc1--x86_64--netinst-root ro rd.lvm.lv=fedora_fedora-20-tc1-x86_64-netinst/root rd.lvm.lv=fedora_fedora-20-tc1-x86_64-netinst/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=de rhgb quiet LANG=ja_JP.UTF-8 11月 15 11:40:33 Fedora-20-TC1-x86_64-netinst.iso kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-3.11.8-300.fc20.x86_64 root=/dev/mapper/fedora_fedora--20--tc1--x86_64--netinst-root ro rd.lvm.lv=fedora_fedora-20-tc1-x86_64-netinst/root rd.lvm.lv=fedora_fedora-20-tc1-x86_64-netinst/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=de rhgb quiet LANG=ja_JP.UTF-8 11月 15 11:40:33 Fedora-20-TC1-x86_64-netinst.iso systemd-vconsole-setup[68]: sh: gzip: command not found [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ With the same "gzip: command not found" error as in my DVD install of Fedora-20-Beta-x86_64-DVD.iso (see comment#30).
still occurs with F20 as of today. colemak (legacy/.../en-latin9.map.gz) won't load unless I manually pass the full path to loadkeys.
note lsinitrd /boot/initramfs-3.11.7-300.fc20.x86_64.img | egrep 'lib/kbd' drwxr-xr-x 4 root root 0 Nov 16 00:57 usr/lib/kbd drwxr-xr-x 2 root root 0 Nov 16 00:57 usr/lib/kbd/consolefonts -rw-r--r-- 1 root root 10312 Nov 6 04:39 usr/lib/kbd/consolefonts/latarcyrheb-sun16.psfu drwxr-xr-x 3 root root 0 Nov 16 00:57 usr/lib/kbd/keymaps drwxr-xr-x 4 root root 0 Nov 16 00:57 usr/lib/kbd/keymaps/legacy drwxr-xr-x 4 root root 0 Nov 16 00:57 usr/lib/kbd/keymaps/legacy/i386 drwxr-xr-x 2 root root 0 Nov 16 00:57 usr/lib/kbd/keymaps/legacy/i386/colemak -rw-r--r-- 1 root root 5930 Nov 6 04:39 usr/lib/kbd/keymaps/legacy/i386/colemak/en-latin9.map but ~@karen.dragonfear loadkeys en-latin9 cannot open file en-latin9
> ~@karen.dragonfear > loadkeys en-latin9 > cannot open file en-latin9 I can reproduce that: [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys en-latin9 cannot open file en-latin9 [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys /lib/kbd/keymaps/legacy/i386/colemak/en-latin9.map.gz Loading /lib/kbd/keymaps/legacy/i386/colemak/en-latin9.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ But, for the keymaps which are not in the “legacy” subdirectory, it works without giving the full path: [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys de Loading /lib/kbd/keymaps/i386/qwertz/de.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys fr Loading /lib/kbd/keymaps/i386/azerty/fr.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys uk Loading /lib/kbd/keymaps/i386/qwerty/uk.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys us Loading /lib/kbd/keymaps/i386/qwerty/us.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$
(In reply to Rudd-O DragonFear from comment #37) > lsinitrd /boot/initramfs-3.11.7-300.fc20.x86_64.img | egrep 'lib/kbd' > drwxr-xr-x 4 root root 0 Nov 16 00:57 usr/lib/kbd > drwxr-xr-x 2 root root 0 Nov 16 00:57 > usr/lib/kbd/consolefonts > -rw-r--r-- 1 root root 10312 Nov 6 04:39 > usr/lib/kbd/consolefonts/latarcyrheb-sun16.psfu > drwxr-xr-x 3 root root 0 Nov 16 00:57 usr/lib/kbd/keymaps > drwxr-xr-x 4 root root 0 Nov 16 00:57 > usr/lib/kbd/keymaps/legacy > drwxr-xr-x 4 root root 0 Nov 16 00:57 > usr/lib/kbd/keymaps/legacy/i386 > drwxr-xr-x 2 root root 0 Nov 16 00:57 > usr/lib/kbd/keymaps/legacy/i386/colemak > -rw-r--r-- 1 root root 5930 Nov 6 04:39 > usr/lib/kbd/keymaps/legacy/i386/colemak/en-latin9.map Apparently these are in usr/lib/kbd, *not* lib/kbd. But the loadkeys commands from comment#38 seem to indicate that the files are loaded from /lib/kbd/... And the debug code output I pasted in comment#19 shows that the /lib/kbd/keymaps/xkb/ and /lib/kbd/keymaps/i386/ were not there at this stage of the boot process. Could it be a problem that initrd has these files in usr/lib/kbd/keymaps/... but loadkeys looks only in /lib/kbd/keymaps/... ?
systemd-vconsole-setup hasn't changed for some time. It depends on other tools to apply settings from /etc/vconsole.conf or options passed on on kernel cmdline. I think this is not a systemd bug. When systemd-vconsole-setup runs /usr/bin/loadkeys, it fails because it is trying to find keymaps under /usr/lib/kbd/keymaps/ however keymaps are actually stored under /usr/lib/kbd/keymaps/legacy in initramfs. These legacy keymaps are from kbd-legacy which is dependency of kbd package. When initramfs is generated (i18n module) it finds compressed keymaps in /usr/lib/kbd/keymaps/legacy and according to /etc/vconsole.conf it decompress some of them into the image, however loadkeys binary is unable to use them as mentioned previously. Reassigning to dracut to get feedback from harald. Also I'd like to know why we still have to keep those legacy keymaps around?
(In reply to Michal Sekletar from comment #40) > When systemd-vconsole-setup runs /usr/bin/loadkeys, it fails because it is > trying to find keymaps under /usr/lib/kbd/keymaps/ however keymaps are > actually stored under /usr/lib/kbd/keymaps/legacy in initramfs. [...] > Also I'd like to know why we still have to keep those legacy keymaps > around? I don’t know whether we still need those legacy keymaps, but the problem seems to occur for non-legacy keymaps as well. [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo lsinitrd /boot/initramfs-3.11.8-300.fc20.x86_64.img | grep kbd [sudo] password for mfabian: -rwxr-xr-x 1 root root 14144 Nov 15 07:53 usr/bin/kbd_mode drwxr-xr-x 4 root root 0 Nov 15 07:53 usr/lib/kbd drwxr-xr-x 2 root root 0 Nov 15 07:53 usr/lib/kbd/consolefonts -rw-r--r-- 1 root root 10312 Nov 6 13:39 usr/lib/kbd/consolefonts/latarcyrheb-sun16.psfu drwxr-xr-x 4 root root 0 Nov 15 07:53 usr/lib/kbd/keymaps drwxr-xr-x 3 root root 0 Nov 15 07:53 usr/lib/kbd/keymaps/i386 drwxr-xr-x 2 root root 0 Nov 15 07:53 usr/lib/kbd/keymaps/i386/qwertz -rw-r--r-- 1 root root 124811 Nov 6 13:45 usr/lib/kbd/keymaps/i386/qwertz/de.map drwxr-xr-x 2 root root 0 Nov 15 07:53 usr/lib/kbd/keymaps/xkb -rw-r--r-- 1 root root 3902 Nov 6 13:45 usr/lib/kbd/keymaps/xkb/de.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ So there is a usr/lib/kbd/keymaps/xkb/de.map.gz, nevertheless loading it during booting does not work.
Michal: as Mike said, the legacy keymaps are not the only issue here. They're still around because we only switched to xkb-converted layouts by 'default' in F20; it would be a bit radical to just ditch the old kbd layouts entirely right away.
(In reply to Mike FABIAN from comment #39) > Apparently these are in usr/lib/kbd, *not* lib/kbd. > Could it be a problem that initrd has these files in usr/lib/kbd/keymaps/... > but loadkeys looks only in /lib/kbd/keymaps/... ? Dracut adds a symlink /lib -> /usr/lib. sudo lsinitrd /boot/initramfs-3.11.7-300.fc20.x86_64.img|grep ' lib ' lrwxrwxrwx 1 root root 7 Nov 12 17:14 lib -> usr/lib So, no, I don't see how that could be relevant. > But the loadkeys commands from comment#38 seem to indicate > that the files are loaded from /lib/kbd/... > > And the debug code output I pasted in comment#19 shows > that the /lib/kbd/keymaps/xkb/ and /lib/kbd/keymaps/i386/ > were not there at this stage of the boot process. This is also very unlikely -- in the sense that the fs isn't modified at any point during the boot process, so if they were not there in the beginning, they will not be there at the end either. Both the dracut initramfs, and the real fs. Dracut defers to loadkeys. It looks like loadkeys has issues with the changed layout, reassigning. (In reply to Michal Sekletar from comment #40) > When systemd-vconsole-setup runs /usr/bin/loadkeys, it fails because it is > trying to find keymaps under /usr/lib/kbd/keymaps/ however keymaps are > actually stored under /usr/lib/kbd/keymaps/legacy in initramfs. These legacy > keymaps are from kbd-legacy which is dependency of kbd package. When > initramfs is generated (i18n module) it finds compressed keymaps in > /usr/lib/kbd/keymaps/legacy and according to /etc/vconsole.conf it > decompress some of them into the image, however loadkeys binary is unable to > use them as mentioned previously. Yes, this seems to be the problem. > Also I'd like to know why we still have to keep those legacy keymaps around? Because we have configurations which refer to them by name. They are "still" around only as symlinks.
Zbigniew: "Yes, this seems to be the problem." No, it isn't, or at least not the only problem, because - again - it is not only legacy layouts that fail to work. "> Also I'd like to know why we still have to keep those legacy keymaps around? Because we have configurations which refer to them by name. They are "still" around only as symlinks." No. They are not symlinks, and it's not really 'because we have configurations which refer to them by name' - I think systemd may still be writing such configs, but it _shouldn't_. They are the layouts that we used to ship as the only console (kbd) layouts in all Fedora releases prior to F19 - the separate set of layouts that predates xkb entirely. As of F20, instead of having separate xkb and kbd layout sets, we have started shipping a set of layouts for kbd which represents the full set of xkb layouts converted to kbd format, with the intent that these should be used by default rather than the 'legacy' kbd-specific layouts: you pick one or more xkb layouts in anaconda, and you get that exact xkb layout(s) in X, and the kbd-converted version of that layout(s) at the console. See https://bugzilla.redhat.com/show_bug.cgi?id=680990 , https://bugzilla.redhat.com/show_bug.cgi?id=837292 and https://lists.fedoraproject.org/pipermail/devel/2013-May/183099.html .
(In reply to Mike FABIAN from comment #38) > > ~@karen.dragonfear > > loadkeys en-latin9 > > cannot open file en-latin9 > > I can reproduce that: > > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys en-latin9 > cannot open file en-latin9 > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys > /lib/kbd/keymaps/legacy/i386/colemak/en-latin9.map.gz > Loading /lib/kbd/keymaps/legacy/i386/colemak/en-latin9.map.gz > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ > > But, for the keymaps which are not in the “legacy” subdirectory, > it works without giving the full path: That's expected behaviour. Keymaps from "legacy" directory are not in loadkeys search path. (Well, this can be changed and maybe it's reasonable to do so.) > > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys de > Loading /lib/kbd/keymaps/i386/qwertz/de.map.gz > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys fr > Loading /lib/kbd/keymaps/i386/azerty/fr.map.gz > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys uk > Loading /lib/kbd/keymaps/i386/qwerty/uk.map.gz > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys us > Loading /lib/kbd/keymaps/i386/qwerty/us.map.gz > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$
(In reply to Zbigniew Jędrzejewski-Szmek from comment #43) > (In reply to Mike FABIAN from comment #39) > > Apparently these are in usr/lib/kbd, *not* lib/kbd. > > Could it be a problem that initrd has these files in usr/lib/kbd/keymaps/... > > but loadkeys looks only in /lib/kbd/keymaps/... ? > Dracut adds a symlink /lib -> /usr/lib. > > sudo lsinitrd /boot/initramfs-3.11.7-300.fc20.x86_64.img|grep ' lib ' > lrwxrwxrwx 1 root root 7 Nov 12 17:14 lib -> usr/lib > > So, no, I don't see how that could be relevant. > > > But the loadkeys commands from comment#38 seem to indicate > > that the files are loaded from /lib/kbd/... > > > > And the debug code output I pasted in comment#19 shows > > that the /lib/kbd/keymaps/xkb/ and /lib/kbd/keymaps/i386/ > > were not there at this stage of the boot process. > This is also very unlikely -- in the sense that the fs isn't modified at any > point during the boot process, so if they were not there in the beginning, > they will not be there at the end either. Both the dracut initramfs, and the > real fs. > > Dracut defers to loadkeys. It looks like loadkeys has issues with the > changed layout, reassigning. I don't think so. In my opinion "systemd-vconsole-setup[70]: sh: gzip: command not found" looks very suspicious - loadkeys uses "gzip -d -c" to uncompress keymaps. Is it somehow possible that gzip is not available at that moment? That would also explain why it works fine after boot. > > (In reply to Michal Sekletar from comment #40) > > When systemd-vconsole-setup runs /usr/bin/loadkeys, it fails because it is > > trying to find keymaps under /usr/lib/kbd/keymaps/ however keymaps are > > actually stored under /usr/lib/kbd/keymaps/legacy in initramfs. These legacy > > keymaps are from kbd-legacy which is dependency of kbd package. When > > initramfs is generated (i18n module) it finds compressed keymaps in > > /usr/lib/kbd/keymaps/legacy and according to /etc/vconsole.conf it > > decompress some of them into the image, however loadkeys binary is unable to > > use them as mentioned previously. > Yes, this seems to be the problem. > > > Also I'd like to know why we still have to keep those legacy keymaps around? > Because we have configurations which refer to them by name. They are "still" > around only as symlinks.
(In reply to Vitezslav Crhonek from comment #45) > > But, for the keymaps which are not in the “legacy” subdirectory, > > it works without giving the full path: > > > That's expected behaviour. Keymaps from "legacy" directory are not in > loadkeys search path. (Well, this can be changed and maybe it's reasonable > to do so.) Ah, OK. I personally do not really worry about the maps in the legacy directory, so I have no opinion on whether the search path should be changed or not. I am only worried why non-legacy maps like "de" do not work automatically after booting.
(In reply to Vitezslav Crhonek from comment #46) > I don't think so. > > In my opinion "systemd-vconsole-setup[70]: sh: gzip: command not found" > looks very suspicious - loadkeys uses "gzip -d -c" to uncompress keymaps. Is > it somehow possible that gzip is not available at that moment? > > That would also explain why it works fine after boot. Yes, that could be the reason. (However, note that there was the error message systemd-vconsole-setup[70]: cannot open file de earlier, see comment#12, then it suddenly worked for me on 3 netinstalls of Fedora-20-Beta-RC5-x86_64-netinst.iso on 2013-11-13). But the gzip problem seems to be the best clue we have at the moment. There seems to be no gzip binary in initramfs: [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo lsinitrd /boot/initramfs-3.11.8-300.fc20.x86_64.img | grep gzip [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ Although a libz is there: [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo lsinitrd /boot/initramfs-3.11.8-300.fc20.x86_64.img | grep libz lrwxrwxrwx 1 root root 13 Nov 15 07:53 usr/lib64/libz.so.1 -> libz.so.1.2.8 -rwxr-xr-x 1 root root 92560 Nov 15 07:53 usr/lib64/libz.so.1.2.8 [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ But if I understand you correctly, the existence of libz does not matter because loadkeys uses the binary “gzip -d -c”, right?
(In reply to Mike FABIAN from comment #48) > But if I understand you correctly, the existence of libz does not > matter because loadkeys uses the binary “gzip -d -c”, right? Right, it does read-only popen() with that command.
Hm, but keymaps in initramfs are already gunzipped...
(In reply to Vitezslav Crhonek from comment #50) > Hm, but keymaps in initramfs are already gunzipped... Some of them: [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo lsinitrd /boot/initramfs-3.11.8-300.fc20.x86_64.img | grep de\\.map -rw-r--r-- 1 root root 124811 Nov 6 13:45 usr/lib/kbd/keymaps/i386/qwertz/de.map -rw-r--r-- 1 root root 3902 Nov 6 13:45 usr/lib/kbd/keymaps/xkb/de.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ The one in the xkb directory seems to be gzipped. But I don’t know whether that matters because the map from the i386/qwertz/ directory seems to be the one which is loaded: [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ sudo loadkeys de Loading /lib/kbd/keymaps/i386/qwertz/de.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$
(In reply to Mike FABIAN from comment #51) > The one in the xkb directory seems to be gzipped. But I don’t know whether > that matters because the map from the i386/qwertz/ directory seems to be the > one > which is loaded: "/lib/kbd/keymaps/i386/qwertz/de.map" should be symlink to "/lib/kbd/keymaps/xkb/de.map.gz"
(In reply to Vitezslav Crhonek from comment #52) > (In reply to Mike FABIAN from comment #51) > > The one in the xkb directory seems to be gzipped. But I don’t know whether > > that matters because the map from the i386/qwertz/ directory seems to be the > > one > > which is loaded: > > "/lib/kbd/keymaps/i386/qwertz/de.map" should be symlink to > "/lib/kbd/keymaps/xkb/de.map.gz" In the installed system, this is the case: [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ ll /lib/kbd/keymaps/i386/qwertz/de.map.gz lrwxrwxrwx. 1 root root 30 11月 15 07:45 /lib/kbd/keymaps/i386/qwertz/de.map.gz -> /lib/kbd/keymaps/xkb/de.map.gz [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ But it does not seem to be the case in initramfs.
(In reply to Mike FABIAN from comment #53) > (In reply to Vitezslav Crhonek from comment #52) > > (In reply to Mike FABIAN from comment #51) > > > The one in the xkb directory seems to be gzipped. But I don’t know whether > > > that matters because the map from the i386/qwertz/ directory seems to be the > > > one > > > which is loaded: > > > > "/lib/kbd/keymaps/i386/qwertz/de.map" should be symlink to > > "/lib/kbd/keymaps/xkb/de.map.gz" > > In the installed system, this is the case: > > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ ll > /lib/kbd/keymaps/i386/qwertz/de.map.gz > lrwxrwxrwx. 1 root root 30 11月 15 07:45 > /lib/kbd/keymaps/i386/qwertz/de.map.gz -> /lib/kbd/keymaps/xkb/de.map.gz > [mfabian@Fedora-20-TC1-x86_64-netinst ~]$ > > But it does not seem to be the case in initramfs. In unpacked initramfs-3.11.8-300.fc20.x86_64.img in a temporary directory to check this: [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ ls bin dev etc init initramfs-3.11.8-300.fc20.x86_64.img lib lib64 proc root run sbin shutdown sys sysroot tmp usr var [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ ls -l lib lrwxrwxrwx. 1 mfabian mfabian 7 11月 18 13:50 lib -> usr/lib [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ file usr/lib/kbd/keymaps/i386/qwertz/de.map usr/lib/kbd/keymaps/i386/qwertz/de.map: ASCII text, with very long lines [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ file usr/lib/kbd/keymaps/xkb/de.map.gz usr/lib/kbd/keymaps/xkb/de.map.gz: gzip compressed data, from Unix, last modified: Wed Nov 6 13:45:26 2013 [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$
(In reply to Mike FABIAN from comment #54) > In unpacked initramfs-3.11.8-300.fc20.x86_64.img in a temporary directory > to check this: > > [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ ls > bin dev etc init initramfs-3.11.8-300.fc20.x86_64.img lib lib64 proc > root run sbin shutdown sys sysroot tmp usr var > [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ ls -l lib > lrwxrwxrwx. 1 mfabian mfabian 7 11月 18 13:50 lib -> usr/lib > [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ file > usr/lib/kbd/keymaps/i386/qwertz/de.map > usr/lib/kbd/keymaps/i386/qwertz/de.map: ASCII text, with very long lines > [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ file > usr/lib/kbd/keymaps/xkb/de.map.gz > usr/lib/kbd/keymaps/xkb/de.map.gz: gzip compressed data, from Unix, last > modified: Wed Nov 6 13:45:26 2013 > [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ I checked it and both files contain the same keymap... In my opinion if "usr/lib/kbd/keymaps/i386/qwertz/de.map" is loaded, then gzip is not needed (and usr/lib/kbd/keymaps/xkb/de.map.gz is not needed too). Another weird thing I noticed - it seems that also font setting to "latarcyrheb-sun16" doesn't work automatically after boot. I had to call "setfont latarcyrheb-sun16" or "systemctl restart systemd-vconsole-setup" in order to switch to this font.
(In reply to Vitezslav Crhonek from comment #55) > Another weird thing I noticed - it seems that also font setting to > "latarcyrheb-sun16" doesn't work automatically after boot. I had to call > "setfont latarcyrheb-sun16" or "systemctl restart systemd-vconsole-setup" in > order to switch to this font. Yes, I see that as well. I think that is bug#970030, it is still not fixed.
Vitezslav: "That's expected behaviour. Keymaps from "legacy" directory are not in loadkeys search path. (Well, this can be changed and maybe it's reasonable to do so.)" I don't know about 'reasonable' or not, but it's definitely not sane for _both_ 'legacy' to be taken out of the path _and_ logind to still 'convert' xkb layout names to legacy kbd layout names: https://bugzilla.redhat.com/show_bug.cgi?id=981805
On the symlink thing - are sure sure initramfs is the appropriate place to be looking? Could the problem not rather be with the regular system, and the problem of having a 'de.map' which is actually a symlink to a gzipped file? Couldn't that be confusing loadkeys somehow? (Why do we have this setup where we have the old layout names existing but as symlinks to the xkb-converted layouts again?)
So, it seems that this bug is composed of many different buglets. Let's kill them off one by one :) For starters, I prepared a patch for bug#981805, which should stop systemd from using the legacy keymaps. (In reply to Adam Williamson from comment #57) > Vitezslav: "That's expected behaviour. Keymaps from "legacy" directory are > not in loadkeys search path. (Well, this can be changed and maybe it's reasonable > to do so.)" > > I don't know about 'reasonable' or not, but it's definitely not sane for > _both_ 'legacy' to be taken out of the path _and_ logind to still 'convert' > xkb layout names to legacy kbd layout names: > https://bugzilla.redhat.com/show_bug.cgi?id=981805 I'm pretty sure that loadkeys must have legacy keymaps in search path, because people can have them configured in /etc/vconsole.conf and we should not break their setups. Legacy keymaps should have the lowest priority though.
zbigniew: ah, of course. that's the reason we have the symlinks: rather than having the legacy maps themselves available we have the legacy *names* symlinked to the converted layouts. of course, people who need to switch layouts are going to get an unpleasant surprise when they upgrade to find a non-switchable layout :/
OK, I modified the kbd to have xkb/legacy subdirs in loadkeys search path (xkb keymaps are taken first, legacy second) and removed legacy names symlinks following /usr/share/systemd/kbd-model-map mapping. SRPM: http://vcrhonek.fedorapeople.org/kbd-f20/kbd-1.15.5-11.fc20.src.rpm Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6197018
Looks OK from a quick glance.
I'll try and give it some testing, along with the localed patch. After that the missing piece of the puzzle, I guess, would be to patch localed further to do the 'layout translation' when switchable layouts are required, but we can follow that up in 1031848 .
(In reply to Vitezslav Crhonek from comment #61) > OK, I modified the kbd to have xkb/legacy subdirs in loadkeys search path > (xkb keymaps are taken first, legacy second) and removed legacy names > symlinks following /usr/share/systemd/kbd-model-map mapping. > > SRPM: > http://vcrhonek.fedorapeople.org/kbd-f20/kbd-1.15.5-11.fc20.src.rpm > > Scratch build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=6197018 Does that also address the problem we had with gzip missing in initrd?
I don't know if we ever definitively identified what's causing the initial issue in this bug report, but the test live images I made both happened to result in working UK layouts at the console post-install. Probably need a few more test runs to be sure it works OK for everyone.
(In reply to Adam Williamson from comment #65) > I don't know if we ever definitively identified what's causing the initial > issue in this bug report, but the test live images I made both happened to > result in working UK layouts at the console post-install. Probably need a > few more test runs to be sure it works OK for everyone. Ah, that sounds good!
Status reviewed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . My testing suggests that the changes proposed by vitezslav in c#61 may address this bug, but we don't have an entirely convincing explanation as to why :) But we do want those changes, and a change to fix #1031848 (either my proposed change or some other one), and the new systemd to fix #981805. So my proposal is that we build a new kbd with the changes from c#61 and a fix for #1031848 ASAP, and then get a TC3 built with that kbd and systemd, and ask for wider testing.
(In reply to Adam Williamson from comment #67) > So my proposal is that we > build a new kbd with the changes from c#61 and a fix for #1031848 ASAP, and > then get a TC3 built with that kbd and systemd, and ask for wider testing. OK.
I tried to test whether the fixes we have so far work. I tested like this: I installed Fedora-20-TC2-x86_64-netinst.iso with German "de" keyboard top priority. After installation, it did not yet work. But of course I expected this. I installed systemd-208-6 and kbd-1.15.5-11.fc20.x86_64.rpm kbd-misc-1.15.5-11.fc20.noarch.rpm kbd-legacy-1.15.5-11.fc20.noarch.rpm Then called “dracut -f” and rebooted. It worked. So up to this point this looks really good!
Now I changed /etc/vconsole.conf to look like: [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ cat /etc/vconsole.conf KEYMAP="gb" FONT="latarcyrheb-sun16" [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ Then called dracut -f again. After that: [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ sudo lsinitrd | grep keymaps [sudo] password for mfabian: drwxr-xr-x 3 root root 0 Nov 21 10:21 usr/lib/kbd/keymaps drwxr-xr-x 2 root root 0 Nov 21 10:21 usr/lib/kbd/keymaps/xkb -rw-r--r-- 1 root root 124667 Nov 19 10:38 usr/lib/kbd/keymaps/xkb/gb.map [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ So the contents of initrd have changed. Before I changed /etc/vconsole.conf and called “dracut -f” it contained de.map It looks correct that initrd contains gb.map after I changed vconsole.conf and called “dracut -f”, so I happily rebooted. And was disappointed that the British keyboard (gb) did *not* work. Why not? journalctl -b says: 11月 21 10:30:47 Fedora-20-TC2-x86_64-netinst.iso systemd-vconsole-setup[68]: /usr/bin/loadkeys failed with error code 1. [13年11月21日 11:12:50] 11月 21 10:30:47 Fedora-20-TC2-x86_64-netinst.iso systemd[1]: Started Create list of required static device nodes for the current kernel. 11月 21 10:30:47 Fedora-20-TC2-x86_64-netinst.iso systemd[1]: Starting Create static device nodes in /dev... 11月 21 10:30:47 Fedora-20-TC2-x86_64-netinst.iso systemd[1]: Started Create static device nodes in /dev. 11月 21 10:30:47 Fedora-20-TC2-x86_64-netinst.iso dracut-cmdline[66]: dracut-20 (Heisenbug) dracut-034-19.git20131021.fc20 11月 21 10:30:47 Fedora-20-TC2-x86_64-netinst.iso systemd-vconsole-setup[68]: cannot open file de Why “de”‽ Where does systemd-vconsole-setup get the information from which map it should load? Of course it cannot load de.map because I now have gb.map in initrd. But why does systemd-vconsole-setup still try to load de?
“dracut -f” seems to write the changed /etc/vconsole.conf correctly into initrd: [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ sudo localectl set-keymap gb [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ sudo dracut -f [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ mkdir tmp [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ cd tmp [mfabian@Fedora-20-TC2-x86_64-netinst tmp]$ sudo cp /boot/initramfs-3.11.8-300.fc20.x86_64.img . [mfabian@Fedora-20-TC2-x86_64-netinst tmp]$ sudo chown mfabian: * [mfabian@Fedora-20-TC2-x86_64-netinst tmp]$ gzip -d -c initramfs-3.11.8-300.fc20.x86_64.img | cpio -i cpio: dev/kmsg: Cannot mknod: 許可されていない操作です cpio: dev/console: Cannot mknod: 許可されていない操作です cpio: dev/null: Cannot mknod: 許可されていない操作です 58197 blocks [mfabian@Fedora-20-TC2-x86_64-netinst tmp]$ ls bin init lib64 run sys usr dev initramfs-3.11.8-300.fc20.x86_64.img proc sbin sysroot var etc lib root shutdown tmp [mfabian@Fedora-20-TC2-x86_64-netinst tmp]$ cat etc/vconsole.conf KEYMAP="gb" UNICODE="1" FONT="latarcyrheb-sun16" [mfabian@Fedora-20-TC2-x86_64-netinst tmp]$
I added some debug output to vconsole-setup.c and compiled my own systemd-vconsole-setup. Running it with strace shows: [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ sudo strace -eopen ./systemd-vconsole-setup open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 open("/dev/tty0", O_RDWR|O_CLOEXEC) = 3 open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 4 open("/etc/vconsole.conf", O_RDONLY|O_CLOEXEC) = 4 open("/proc/1/environ", O_RDONLY|O_CLOEXEC) = 4 open("/proc/cmdline", O_RDONLY|O_CLOEXEC) = 4 open("/sys/module/vt/parameters/default_utf8", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 4 args[0]=/usr/bin/loadkeys args[1]=-q args[2]=-C args[3]=/dev/tty0 args[4]=-u args[5]=de --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9804, si_status=0, si_utime=0, si_stime=0} --- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9803, si_status=0, si_utime=3, si_stime=0} --- open("/dev/tty1", O_RDWR|O_CLOEXEC) = 4 open("/dev/tty3", O_RDWR|O_CLOEXEC) = 4 open("/dev/tty4", O_RDWR|O_CLOEXEC) = 4 open("/dev/tty5", O_RDWR|O_CLOEXEC) = 4 open("/dev/tty6", O_RDWR|O_CLOEXEC) = 4 +++ exited with 0 +++ [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ So it does read /etc/vconsole.conf (which contains “KEYMAP=gb” because of “localectl set-keymap gb”. But it also reads /proc/cmdline which contains: [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11.8-300.fc20.x86_64 root=/dev/mapper/fedora_fedora--20--tc2--x86_64--netinst-root ro rd.lvm.lv=fedora_fedora-20-tc2-x86_64-netinst/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora_fedora-20-tc2-x86_64-netinst/root vconsole.keymap=de rhgb quiet LANG=ja_JP.UTF-8 [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ and apparently the vconsole.keymap=de from there is preferred, my debug output shows the arguments used to call loadkeys, “loadkeys -q -C /dev/tty0 -u de” is called. In the installed system, the result is only, that the keyboard layout on the vconsole stays at “de” and the “gb” in /etc/vconsole.conf is ignored. “dracut -f” correctly writes “KEYMAP=gb” into the etc/vconsole.conf which is in initrd. And it removes de.map from initrd and puts gb.map into initrd instead. But /boot/grub2/grub.cfg stays unchanged: [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ sudo grep vconsole /boot/grub2/grub.cfg linux /vmlinuz-3.11.8-300.fc20.x86_64 root=/dev/mapper/fedora_fedora--20--tc2--x86_64--netinst-root ro rd.lvm.lv=fedora_fedora-20-tc2-x86_64-netinst/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora_fedora-20-tc2-x86_64-netinst/root vconsole.keymap=de rhgb quiet LANG=ja_JP.UTF-8 linux /vmlinuz-0-rescue-fe0528cc8f164ff9a6377ad51a209ea2 root=/dev/mapper/fedora_fedora--20--tc2--x86_64--netinst-root ro rd.lvm.lv=fedora_fedora-20-tc2-x86_64-netinst/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora_fedora-20-tc2-x86_64-netinst/root vconsole.keymap=de rhgb quiet [mfabian@Fedora-20-TC2-x86_64-netinst ~]$ It still contains “vconsole.keymap=de” after calling “localectl set-keymap gb”. Therefore, at the next boot, systemd-vconsole-setup prefers the “de” it gets from /proc/cmdline and calls “loadkeys de” which fails because now we have gb.map in initrd and de.map is gone. Finally I may have understood the error message from journalctl: 11月 21 10:30:47 Fedora-20-TC2-x86_64-netinst.iso systemd-vconsole-setup[68]: cannot open file de
From #systemd@freenode: <mfabian> Earnestly: thank you. But as gb.map exists in Fedora, this does not cause the problem. The problem is, that “localectl set-keymap gb” changes /etc/vconsole.conf and if followed by “dracut -f”, the etc/vconsole.conf in initrd is also changed and the contents of usr/lib/kbd/keymaps/ in initrd are changed to contain only gb.map (The de.map which was there before is removed). But when booting after that, the “vconsole.keymap=de” on [13年11月21日 14:53:58] <mfabian> the kernel command line is still there because “localectl set-keymap gb” did *not* change the kernel command line in /boot/grub2/grub.cfg. And systemd apparently prefers the “vconsole.keymap=de” from the kernel command line over the contents of etc/vconsole.conf. So it still tries to load de.map, which is not there anymore. And the result is the the console defaults to US English layout. <kay> mfabian: kernel cmdline always wins, has the highest prio everywhere, no setting in a file can change that [13年11月21日 14:54:51] <mfabian> kay: but shouldn’t “localectl set-keymap gb” change grub.cfg then? [13年11月21日 14:55:30] <mfabian> kay: Or, maybe vconsole.keymap=de should not be in grub.cfg by default? [13年11月21日 14:56:39] <blami_o> imho isn't good idea to have vconsole.keymap=something in kernel line [13年11月21日 14:56:47] <kay> mfabian: we have no business really with grub, we don't want to know about grub. stuff should just not be on the kernel cmdline [13年11月21日 14:56:54] <mfabian> OK, so vconsole.keymap=de should *not* be in grub.cfg (unless the user puts it there manually of course) [13年11月21日 14:57:26] <kay> mbiebl: the kernel cmdline is for admins, not for the distro [13年11月21日 14:57:29] <kay> mfabian: right, ideally it would be that way [13年11月21日 14:57:47] <mfabian> At the moment, on Fedora 20, it seems to be added to grub.cfg by default. [13年11月21日 14:58:21] <blami_o> from my experience kernel cmdline should be as minimalistic as possible [13年11月21日 14:58:37] <kay> mfabian: could be yeah, it's a mess [13年11月21日 14:59:29] * kay has not seen grub for a long time :) [13年11月21日 14:59:54] <mfabian> OK, I’ll try to find out who puts this into grub.cfg [13年11月21日 15:00:05]
According to https://bugzilla.redhat.com/show_bug.cgi?id=875567#c16 it looks like dracut is putting the keyboard layout into grub.cfg to make the layout available when the LUKS password is entered, which is seems to be so early that systemd could not yet setup the keyboard layout. But then dracut should probably change grub.cfg again when doing “localectl set-keymap gb; dracut -f” otherwise the newly set map gb won’t work after reboot.
Mike: it might be best to start a new bug for this follow-up issue, as if I'm reading it correctly, it's really a separate problem. I suppose the reason we write vconsole.keymap to the cmdline is for the encrypted root case itself: there's no way the initramfs can read /etc/vconsole.conf and find out what the correct layout is if /etc is on a partition that hasn't been decrypted yet?
kbd-1.15.5-11.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kbd-1.15.5-11.fc20
(follow-up to c#75)...but no, that's not it, as vconsole.conf is written into the initramfs itself. So why are we putting it on the cmdline?
(In reply to Adam Williamson from comment #75) > Mike: it might be best to start a new bug for this follow-up issue, as if > I'm reading it correctly, it's really a separate problem. Ah, yes, I think you are right, I’ll open a new bug for this. > I suppose the reason we write vconsole.keymap to the cmdline is for > the encrypted root case itself: Yes, see bug#875567 > there's no way the initramfs can read /etc/vconsole.conf and find > out what the correct layout is if /etc is on a partition that hasn't > been decrypted yet? initramfs has its own copy of /etc/vconsole.conf, “dracut -f” puts it in there. After “dracut -f”, the KEYMAP=... in the /etc/vconsole.conf in the system and in the etc/vconsole.conf in initramfs are the same. But I don’t know whether this etc/vconsole.conf in initramfs is used by systemd early enough to make it work when typing the encryption password is necessary. If I understand bug#875567 correctly, it is too late, therefore the option for the keyboard layout was added to grub.cfg.
(In reply to Mike FABIAN from comment #78) > Ah, yes, I think you are right, I’ll open a new bug for this. bug#1033250.
So I built a live image with kbd-1.15.5-11.fc20 and systemd-208-6 and testing looks good. Did US English, UK English, Czech and Russian installs and all behave as I'd expect and intend. I'll up-karma the updates and we can pull them into Final TC3 when it gets built. If others can up-karma too that'd be great (assuming you don't find any problems I missed, of course!)
Package kbd-1.15.5-11.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kbd-1.15.5-11.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22058/kbd-1.15.5-11.fc20 then log in and leave karma (feedback).
kbd-1.15.5-11.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.