Bug 1028207 - non US keyboard layouts not working at console
Summary: non US keyboard layouts not working at console
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kbd
Version: 20
Hardware: x86_64
OS: All
unspecified
high
Target Milestone: ---
Assignee: Vitezslav Crhonek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Keywords: CommonBugs, i18n
Depends On: 981805
Blocks: F20FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2013-11-07 22:03 UTC by Adam Williamson
Modified: 2013-11-26 03:57 UTC (History)
22 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-11-26 03:57:41 UTC


Attachments (Terms of Use)

Description Adam Williamson 2013-11-07 22:03:40 UTC
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.

Comment 1 Adam Williamson 2013-11-07 22:04:26 UTC
Proposing as a Final blocker for the encryption passphrase / password entry problems when the keymap is not what you expect it to be.

Comment 2 Mike FABIAN 2013-11-08 00:14:03 UTC
langtable doesn’t have any “uk” keyboard layout, only “gb” exists.

Comment 3 Vratislav Podzimek 2013-11-08 07:33:01 UTC
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.

Comment 4 Adam Williamson 2013-11-08 16:50:54 UTC
Why does loadkeys fail if gb.map.gz files do exist in other subdirs? Does loadkeys run through langtable now or what?

Comment 5 Mike FABIAN 2013-11-09 13:29:47 UTC
Leslie Satenstein reports a similar problem for the French Canadian
keyboard, see https://bugzilla.redhat.com/show_bug.cgi?id=892110#c32

Comment 6 Mike FABIAN 2013-11-09 13:30:57 UTC
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

Comment 7 Mike FABIAN 2013-11-09 13:33:10 UTC
[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 ~]$

Comment 8 Leslie Satenstein 2013-11-09 13:52:35 UTC
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?

Comment 9 Mike FABIAN 2013-11-09 16:43:56 UTC
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.

Comment 10 Mike FABIAN 2013-11-09 16:45:35 UTC
But after a reboot, it is broken again.

Comment 11 Adam Williamson 2013-11-09 17:40:14 UTC
mike: then it would help to have more context for your loadkeys failure during startup. I did 'grep -5', note.

Comment 12 Mike FABIAN 2013-11-10 09:58:42 UTC
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 ~]$

Comment 13 Mike FABIAN 2013-11-10 10:02:34 UTC
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 ~]$

Comment 14 Mike FABIAN 2013-11-10 10:06:28 UTC
[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 ~]$

Comment 15 Adam Williamson 2013-11-10 17:50:02 UTC
yeah, this is starting to look more like a race than a case of trying to open a map that doesn't exist.

Comment 16 Mike FABIAN 2013-11-12 10:28:56 UTC
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.

Comment 17 Mike Ruckman 2013-11-12 18:54:42 UTC
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

Comment 18 Mike FABIAN 2013-11-13 07:02:06 UTC
(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.

Comment 19 Mike FABIAN 2013-11-13 08:05:13 UTC
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.

Comment 20 Mike FABIAN 2013-11-13 08:07:30 UTC
[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 ~]$

Comment 21 Mike FABIAN 2013-11-13 08:10:26 UTC
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).

Comment 22 Mike FABIAN 2013-11-13 08:24:24 UTC
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!)

Comment 23 Mike FABIAN 2013-11-13 13:16:21 UTC
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?

Comment 24 Mamoru TASAKA 2013-11-13 13:51:52 UTC
Maybe the same issue as bug 1026065 ?

Comment 25 Mike FABIAN 2013-11-13 14:30:15 UTC
(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)

Comment 26 Mike FABIAN 2013-11-13 16:04:54 UTC
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 ~]$

Comment 27 Mike FABIAN 2013-11-13 16:55:03 UTC
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.

Comment 28 Adam Williamson 2013-11-13 18:09:20 UTC
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.

Comment 29 Mike FABIAN 2013-11-14 07:06:05 UTC
(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.

Comment 30 Mike FABIAN 2013-11-14 07:14:20 UTC
(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.

Comment 31 Mike FABIAN 2013-11-14 07:34:08 UTC
(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.

Comment 32 Mike FABIAN 2013-11-14 07:35:10 UTC
    sudo systemctl restart systemd-vconsole-setup.service

Comment 33 Mike FABIAN 2013-11-14 07:36:22 UTC
    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).

Comment 34 Mike Ruckman 2013-11-14 17:49:51 UTC
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

Comment 35 Mike FABIAN 2013-11-15 10:48:15 UTC
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).

Comment 36 Rudd-O DragonFear 2013-11-16 09:57:04 UTC
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.

Comment 37 Rudd-O DragonFear 2013-11-16 09:57:55 UTC
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

Comment 38 Mike FABIAN 2013-11-16 20:40:09 UTC
> ~@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 ~]$

Comment 39 Mike FABIAN 2013-11-16 20:51:16 UTC
(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/... ?

Comment 40 Michal Sekletar 2013-11-16 22:14:35 UTC
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?

Comment 41 Mike FABIAN 2013-11-16 23:11:53 UTC
(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.

Comment 42 Adam Williamson 2013-11-16 23:22:39 UTC
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.

Comment 43 Zbigniew Jędrzejewski-Szmek 2013-11-17 00:59:09 UTC
(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.

Comment 44 Adam Williamson 2013-11-17 01:26:22 UTC
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 .

Comment 45 Vitezslav Crhonek 2013-11-18 11:06:27 UTC
(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 ~]$

Comment 46 Vitezslav Crhonek 2013-11-18 11:12:28 UTC
(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.

Comment 47 Mike FABIAN 2013-11-18 11:17:28 UTC
(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.

Comment 48 Mike FABIAN 2013-11-18 11:26:51 UTC
(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?

Comment 49 Vitezslav Crhonek 2013-11-18 12:09:34 UTC
(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.

Comment 50 Vitezslav Crhonek 2013-11-18 12:19:53 UTC
Hm, but keymaps in initramfs are already gunzipped...

Comment 51 Mike FABIAN 2013-11-18 12:25:01 UTC
(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 ~]$

Comment 52 Vitezslav Crhonek 2013-11-18 12:39:31 UTC
(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"

Comment 53 Mike FABIAN 2013-11-18 12:53:54 UTC
(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.

Comment 54 Mike FABIAN 2013-11-18 12:55:49 UTC
(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]$

Comment 55 Vitezslav Crhonek 2013-11-18 13:43:31 UTC
(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.

Comment 56 Mike FABIAN 2013-11-18 13:54:16 UTC
(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.

Comment 57 Adam Williamson 2013-11-18 16:21:33 UTC
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

Comment 58 Adam Williamson 2013-11-18 17:13:40 UTC
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?)

Comment 59 Zbigniew Jędrzejewski-Szmek 2013-11-18 19:05:12 UTC
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.

Comment 60 Adam Williamson 2013-11-19 00:05:52 UTC
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 :/

Comment 61 Vitezslav Crhonek 2013-11-19 09:57:20 UTC
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

Comment 62 Zbigniew Jędrzejewski-Szmek 2013-11-19 14:25:39 UTC
Looks OK from a quick glance.

Comment 63 Adam Williamson 2013-11-19 17:35:40 UTC
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 .

Comment 64 Mike FABIAN 2013-11-20 06:50:02 UTC
(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?

Comment 65 Adam Williamson 2013-11-20 07:05:47 UTC
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.

Comment 66 Mike FABIAN 2013-11-20 07:07:54 UTC
(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!

Comment 67 Adam Williamson 2013-11-20 19:47:44 UTC
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.

Comment 68 Vitezslav Crhonek 2013-11-21 10:07:40 UTC
(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.

Comment 69 Mike FABIAN 2013-11-21 10:35:58 UTC
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! 

Comment 70 Mike FABIAN 2013-11-21 11:31:01 UTC
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?

Comment 71 Mike FABIAN 2013-11-21 11:44:54 UTC
“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]$

Comment 72 Mike FABIAN 2013-11-21 13:07:29 UTC
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

Comment 73 Mike FABIAN 2013-11-21 14:03:02 UTC
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]

Comment 74 Mike FABIAN 2013-11-21 17:00:46 UTC
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.

Comment 75 Adam Williamson 2013-11-21 17:27:20 UTC
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?

Comment 76 Fedora Update System 2013-11-21 17:56:28 UTC
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

Comment 77 Adam Williamson 2013-11-21 18:42:12 UTC
(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?

Comment 78 Mike FABIAN 2013-11-21 18:52:40 UTC
(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.

Comment 79 Mike FABIAN 2013-11-21 19:04:15 UTC
(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.

Comment 80 Adam Williamson 2013-11-21 19:44:51 UTC
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!)

Comment 81 Fedora Update System 2013-11-24 04:06:15 UTC
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).

Comment 82 Fedora Update System 2013-11-26 03:57:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.