Red Hat Bugzilla – Bug 880271
Wrong keyboard layout in initramdisk
Last modified: 2013-01-10 21:53:26 EST
Description of problem:
The keyboard layout for unlocking the luks-encrypted root-filesystem is en_US after upgrading from fedora 17 even tough the layout was different when fedora was installed.
Version-Release number of selected component (if applicable): 024-10.git20121121.fc18
Steps to Reproduce:
1.Install Fedora 17 with encrypted root using a german keyboard layout
2.Upgrade using this description:
3.upgrade to kernel 3.6.7-5.fc18
the initramfs-3.6.7-5.fc18.x86_64.img does not seem to contain any hint of a german keyboard layout.
the keyboard layout in the initramdisk should be german.
Additional info: /etc/grub2.cfg and /boot/grub2/grub.cfg both contain the correct keyboard layout. executing dracut manually does not change the keyboard layout in the initramdisk.
What is the output of:
# cat /proc/cmdline
# cat /etc/sysconfig/keyboard
# cat /etc/vconsole.conf
# lsinitrd /boot/initramfs-3.6.7-5.fc18.x86_64.img etc/vconsole.conf
cat /proc/cmdline returns:
BOOT_IMAGE=/vmlinuz-3.6.7-5.fc18.x86_64 root=/dev/mapper/vg-lv_root ro rd.md=0 rd.dm=0 SYSFONT=True rd.lvm.lv=vg/lv_root rd.luks.uuid=luks-* KEYTABLE=de-latin1-nodeadkeys rd.lvm.lv=vg/lv_swap LANG=en_US.UTF-8 rhgb quiet
cat /etc/sysconfig/keyboard returns:
cat: /etc/sysconfig/keyboard: No such file or directory
cat /etc/vconsole.conf returns:
lsinitrd /boot/initramfs-3.6.7-5.fc18.x86_64.img etc/vconsole.conf returns nothing
yes, you are right... spotted the bug.
Nominating it as a blocker bug for F18
How was the system upgraded from F17 to F18? If yum was used, does the same problem manifest using FedUp?
I assume that this wouldn't affect a clean install, am I understanding correctly?
Same problem here, I upgraded with yum but I had the same issue with FedUp before trying yum.
In addition, the GDM login screen has the wrong keyboard layout (en_US). In GNOME however, it's fine.
My /proc/cmdline says KEYTABLE=fr and LANG=fr_FR.UTF-8
/etc/sysconfig/keyboard was non-existant before I tried system-config-keyboard to fix the problem (it did not fix it)
/etc/vconsole.conf contains KEYMAP=fr
I did not try a clean install.
The bug is in the dracut code to generate /etc/vconsole.conf from the old "KEYBOARD" parameters on the kernel command line. The function runs in parallel to systemd-vconsole-setup.service instead of before it.
(In reply to comment #6)
> The bug is in the dracut code to generate /etc/vconsole.conf from the old
> "KEYBOARD" parameters on the kernel command line. The function runs in
> parallel to systemd-vconsole-setup.service instead of before it.
Discussed at 2012-12-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-10/f18final-blocker-review-3.2012-12-10-17.13.log.txt . Accepted as a blocker per criterion "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using all officially recommended upgrade mechanisms. The upgraded system must meet all release criteria" - the criterion not met is "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to create a working user account" in the case of a non-en-us keymap.
dracut-024-15.git20121218.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-024-15.git20121218.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
dracut-024-15.git20121218.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Does not work for me. I don't know if it is because /etc/vconsole.conf (as per its man page) contains KEYMAP=it, and the kernel expects KEYTABLE=it?
Nevertheless, if I regenerate the initramfs and reboot, I still have troubles with "*" being over 8, as in the US layout, instead than two keys to the right of "P", as in the Italian / German layouts (I tried both).
Reopening per comment 12.
(In reply to comment #12)
> Does not work for me. I don't know if it is because /etc/vconsole.conf (as
> per its man page) contains KEYMAP=it, and the kernel expects KEYTABLE=it?
> Nevertheless, if I regenerate the initramfs and reboot, I still have
> troubles with "*" being over 8, as in the US layout, instead than two keys
> to the right of "P", as in the Italian / German layouts (I tried both).
"vconsole.keymap=it" on the kernel command line
(In reply to comment #14)
> (In reply to comment #12)
> > Does not work for me. I don't know if it is because /etc/vconsole.conf (as
> > per its man page) contains KEYMAP=it, and the kernel expects KEYTABLE=it?
> > Nevertheless, if I regenerate the initramfs and reboot, I still have
> > troubles with "*" being over 8, as in the US layout, instead than two keys
> > to the right of "P", as in the Italian / German layouts (I tried both).
> "vconsole.keymap=it" on the kernel command line
"vconsole.keymap=de-latin1" or "KEYMAP=de-latin1" works for me like a charm
Okay, my bad. Adding that to the kernel command line works for me also.
Question: why is this not automatically inferred by /etc/vconsole.conf, as language is inferred by /etc/locale.conf? LANG=IT_it.utf8, for instance, is added automatically by grubby, I guess by using locale.conf.
I am referring to section 2.3.2. of the Fedora 18 release notes.
I would expect dracut to be able to set all environment variables during init, after sourcing locale.conf and vconsole.conf during initramfs creation, and kernel command line parameters to override these system-wide settings.
Incidentally, I hope anaconda is able to generate grub.cfg correctly the first time (with the KEYMAP and LANG parameters), because calling grub-mkconfig does not add such trailing parameters unless they are already present in /etc/default/grub — kind of a repetition, in my opinion, since we have locale.conf + vconsole.conf for that.
https://bugzilla.redhat.com/show_bug.cgi?id=875567 may be relevant here, though I'm getting lost in all these keymap bugs. That's a patch to set the vconsole.keymap kernel parameter, which is apparently only needed for some layouts, not all.
This bug with wrong keyboard layout still exists in dracut-024-18.git20130102.fc18.x86_64.
I made a clean install of F18 Beta and update all.
It actually works for me. It was my fault in the last comment (18) - I had keyboard layout problem because Xorg wrongly recognized layout of my keyboard not because dracut didn't load correct vconsole/locale settings. Sorry on this false alert.
For me, it was also fixed by updating to grubby 8.21-1 (released Fri Jan 04 2013). Thanks.