Bug 880271

Summary: Wrong keyboard layout in initramdisk
Product: [Fedora] Fedora Reporter: ghutzriop
Component: dracutAssignee: dracut-maint
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: adundovi, aurelien, awilliam, dracut-maint, harald, jonathan, jvcelak, kparal, matteo, robatino, tflink
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-20 13:11:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 752661, 881624    

Description ghutzriop 2012-11-26 15:38:39 UTC
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


How reproducible:


Steps to Reproduce:
1.Install Fedora 17 with encrypted root using a german keyboard layout
2.Upgrade using this description:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18
3.upgrade to kernel 3.6.7-5.fc18
  
Actual results:
the initramfs-3.6.7-5.fc18.x86_64.img does not seem to contain any hint of a german keyboard layout.

Expected results:
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.

Comment 1 Harald Hoyer 2012-11-28 10:44:52 UTC
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

Comment 2 ghutzriop 2012-11-29 12:11:47 UTC
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:
FONT=True
KEYMAP=de-latin1-nodeadkeys
lsinitrd /boot/initramfs-3.6.7-5.fc18.x86_64.img etc/vconsole.conf returns nothing

Comment 3 Harald Hoyer 2012-11-29 15:20:42 UTC
yes, you are right... spotted the bug.

Nominating it as a blocker bug for F18

Comment 4 Tim Flink 2012-11-30 18:38:08 UTC
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?

Comment 5 Aurelien Bompard 2012-11-30 23:10:57 UTC
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.

Comment 6 Harald Hoyer 2012-12-03 12:27:16 UTC
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.

Comment 7 Harald Hoyer 2012-12-03 12:27:47 UTC
(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.

s/KEYBOARD/KEYTABLE

Comment 8 Adam Williamson 2012-12-10 19:04:56 UTC
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.

Comment 9 Fedora Update System 2012-12-18 15:57:37 UTC
dracut-024-15.git20121218.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-15.git20121218.fc18

Comment 10 Fedora Update System 2012-12-18 21:28:01 UTC
Package dracut-024-15.git20121218.fc18:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2012-20580/dracut-024-15.git20121218.fc18
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2012-12-20 05:37:35 UTC
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.

Comment 12 Matteo Settenvini 2012-12-20 12:42:38 UTC
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).

Comment 13 Kamil Páral 2012-12-20 13:01:32 UTC
Reopening per comment 12.

Comment 14 Harald Hoyer 2012-12-20 13:06:40 UTC
(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

Comment 15 Harald Hoyer 2012-12-20 13:11:56 UTC
(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

Comment 16 Matteo Settenvini 2012-12-20 13:56:53 UTC
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.

Comment 17 Adam Williamson 2012-12-21 00:28:38 UTC
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.

Comment 18 Andrej 2013-01-10 19:01:00 UTC
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.

Comment 19 Andrej 2013-01-11 00:54:44 UTC
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.

Comment 20 Matteo Settenvini 2013-01-11 02:53:26 UTC
For me, it was also fixed by updating to grubby 8.21-1 (released Fri Jan 04 2013). Thanks.