Bug 875567 - anaconda doesnt set keyboard layout for LUKS password at reboot
anaconda doesnt set keyboard layout for LUKS password at reboot
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Vratislav Podzimek
Fedora Extras Quality Assurance
AcceptedNTH
: Reopened
: 890537 (view as bug list)
Depends On:
Blocks: F18-accepted/F18FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-11-11 21:32 EST by Jan Teichmann
Modified: 2013-11-25 08:13 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-02 16:51:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
grub.cfg from the installed system (4.42 KB, text/plain)
2012-11-30 05:43 EST, Vratislav Podzimek
no flags Details

  None (edit)
Description Jan Teichmann 2012-11-11 21:32:33 EST
Description of problem:
I set the live session and anaconda to non-US keyboard layout. I then entered a password for hdd encrytion using LUKS. On reboot the keyboard layout for the LUKS password is US. 

Version-Release number of selected component (if applicable):
fedora nightly
http://koji.fedoraproject.org/koji/taskinfo?taskID=4673781
anaconda 18.28-1.fc18
Comment 1 Vratislav Podzimek 2012-11-28 05:08:34 EST

*** This bug has been marked as a duplicate of bug 878433 ***
Comment 2 Vratislav Podzimek 2012-11-28 07:36:03 EST
It turns out this could be a different issue.
Comment 3 Vratislav Podzimek 2012-11-28 07:46:53 EST
Could you please reproduce this and at the end of the installation switch to tty2 and get the contents of the following files:
/etc/vconsole.conf
/etc/X11/xorg.conf.d/00-anaconda.conf
?

You can use e.g. fpaste of scp for this.
Comment 4 Vratislav Podzimek 2012-11-29 07:06:36 EST
I've just tested installation with French keyboard layout. Configuration files from comment #3 are written correctly, but the prompt for LUKS password doesn't use 'fr' as keymap. After 3 incorrect attempts I get dropped to dracut shell, where 'us' keymap is active. 'cat /etc/vconsole.conf' contains just:

UNICODE="1"

Harald, is there anything else Anaconda can do to set the right keymap in LUKS prompt than writing the two configuration files mentioned in comment #3?
Comment 5 Harald Hoyer 2012-11-29 08:36:46 EST
(In reply to comment #4)
> I've just tested installation with French keyboard layout. Configuration
> files from comment #3 are written correctly, but the prompt for LUKS
> password doesn't use 'fr' as keymap. After 3 incorrect attempts I get
> dropped to dracut shell, where 'us' keymap is active. 'cat
> /etc/vconsole.conf' contains just:
> 
> UNICODE="1"
> 
> Harald, is there anything else Anaconda can do to set the right keymap in
> LUKS prompt than writing the two configuration files mentioned in comment #3?

What does the kernel command line say?
Comment 6 Vratislav Podzimek 2012-11-30 05:43:28 EST
Created attachment 654927 [details]
grub.cfg from the installed system

It looks like this:

linux	/vmlinuz-3.7.0-0.rc7.git1.1.fc19.x86_64 root=/dev/mapper/fedora_office78-root ro rd.luks.uuid=luks-35d03254-9efc-473a-a95f-d71328f74658 rd.md=0 rd.dm=0 rd.lvm.lv=fedora_office78/swap  rd.lvm.lv=fedora_office78/root rhgb quiet
Comment 7 Vratislav Podzimek 2012-11-30 05:48:30 EST
Should 'vconsole.keymap=fr' or something like that be appended?
Comment 8 Harald Hoyer 2012-12-03 07:32:43 EST
(In reply to comment #7)
> Should 'vconsole.keymap=fr' or something like that be appended?

That would be the preferred kernel cmdline.

See man vconsole.conf(5)
Comment 9 Vratislav Podzimek 2012-12-13 08:15:26 EST
Patch pushed to master (Rawhide). Without that patch, LUKS password prompt always uses 'us' layout. I'm proposing this as a F18 NTH. It is not a blocker because it affects only some installations -- with a LUKS password set using an X layout different from 'us' which has matching VConsole keymap correctly provided by systemd-localed (there are not much of them).

It's easy to port the patch for f18-branch (just cherry-picking the commit).
Comment 10 Adam Williamson 2012-12-19 13:51:00 EST
Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . Accepted as NTH at least for the impact on encrypted installs.

Vratislav, is it possible this stuff is somehow related to the remaining complaints in https://bugzilla.redhat.com/show_bug.cgi?id=859867 and https://bugzilla.redhat.com/show_bug.cgi?id=866887 ?
Comment 11 Vratislav Podzimek 2012-12-21 04:34:46 EST
(In reply to comment #10)
> Discussed at 2012-12-19 NTH review meeting:
> http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-
> blocker-review-6.2012-12-19-17.02.log.txt . Accepted as NTH at least for the
> impact on encrypted installs.
> 
> Vratislav, is it possible this stuff is somehow related to the remaining
> complaints in https://bugzilla.redhat.com/show_bug.cgi?id=859867 and
> https://bugzilla.redhat.com/show_bug.cgi?id=866887 ?
I don't think so. This bug is about VConsole settings for the boot process and the complaints in those bugs seem to be about the VConsole in the booted system.
Comment 12 Vratislav Podzimek 2012-12-21 09:31:41 EST
Patch ported to F18-branch and should appear in the next build for F18.
Comment 13 Fedora Update System 2012-12-21 18:33:17 EST
dracut-024-17.git20121220.fc18, anaconda-18.37.7-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.7-1.fc18
Comment 14 Fedora Update System 2012-12-22 16:11:52 EST
Package dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.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-17.git20121220.fc18 anaconda-18.37.8-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.8-1.fc18
then log in and leave karma (feedback).
Comment 15 Chris Lumens 2013-01-02 10:43:51 EST
*** Bug 890537 has been marked as a duplicate of this bug. ***
Comment 16 Fedora Update System 2013-01-02 16:51:05 EST
dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Ricky Burgin 2013-08-06 01:00:32 EDT
This bug is also occurring in the Fedora 19 live image for me, precisely as described in this report.
Comment 18 Ricky Burgin 2013-08-06 01:27:26 EDT
It just occurred to me to try changing the regional settings for the live session. Seemed to do the trick. Very unhelpful and unintuitive though, anaconda should definitely be altered to configure regional settings properly.
Comment 19 Ricky Burgin 2013-08-06 02:17:32 EDT
Another revelation, despite showing in anaconda that there was en-gb input currently enabled, on reboot I have had to input my password as per the en-us layout. The kernel parameter vconsole.keymap shows gb input too.
Comment 20 Vratislav Podzimek 2013-08-12 08:46:28 EDT
In live installs, the installer changes the keyboard configuration only for the newly installed system, not for the installation process. Exactly as the Keyboard spoke's (screen's) header says.

However, if you've configured the 'gb' layout for the installation process and also in the installer for the newly installed system and the LUKS passphrase entry on reboot uses the 'us' layout altough the kernel parameter is set correctly to 'vconsole.keymap=gb', feel free to reopen this bug, assign it to dracut and change summary to reflect that it is a dracut bug.
Comment 21 Adam Williamson 2013-11-21 14:46:21 EST
As per https://bugzilla.redhat.com/show_bug.cgi?id=1033250 , is this really the right fix for the issue? Wouldn't it be better to fix systemd to read the initramfs' copy of /etc/vconsole.conf earlier, if possible? Writing the keymap chosen at install time to the cmdline makes it difficult to change the keymap later.
Comment 22 Vratislav Podzimek 2013-11-25 07:29:58 EST
(In reply to Adam Williamson from comment #21)
> As per https://bugzilla.redhat.com/show_bug.cgi?id=1033250 , is this really
> the right fix for the issue? Wouldn't it be better to fix systemd to read
> the initramfs' copy of /etc/vconsole.conf earlier, if possible? Writing the
> keymap chosen at install time to the cmdline makes it difficult to change
> the keymap later.
Do we even need the vconsole.keymap at all now? It has no effect with the host-only initrd generated by default, right?
Comment 23 Mike FABIAN 2013-11-25 07:39:02 EST
(In reply to Vratislav Podzimek from comment #22)

> Do we even need the vconsole.keymap at all now? It has no effect with the
> host-only initrd generated by default, right?

Unfortunately it has an effect.
Because the keymap found in vconsole.keymap on the kernel command line
overrides the keymap found in etc/vconsole.conf in initrd.

After a

    “localectl set-keymap <new-map>; dracut -f; reboot;”

initrd will have KEYMAP=<new-map> in etc/vconsole.conf
and also the new keymap in usr/lib/kbd/keymaps/.
*Only* the new keymap, the old one will have been removed
by the localectl and dracut calls changing the keymap.

But systemd-vconsole-setup prefers the keymap from the kernel command line.
Thus, loadkeys tries to load the keymap from the kernel command line
which is not available anymore in initrd. Therefore, it fails.
Comment 24 Vratislav Podzimek 2013-11-25 07:56:58 EST
(In reply to Mike FABIAN from comment #23)
> (In reply to Vratislav Podzimek from comment #22)
> 
> > Do we even need the vconsole.keymap at all now? It has no effect with the
> > host-only initrd generated by default, right?
> 
> Unfortunately it has an effect.
Fixing my question: Does it have any positive effect? I mean, with regenerating initrd.img after writing out configuration files, the initrd contains the value we want to set for the first boot after installation.

So I believe we can drop writing out this boot option from anaconda, right?
Comment 25 Mike FABIAN 2013-11-25 08:13:55 EST
(In reply to Vratislav Podzimek from comment #24)

> > Unfortunately it has an effect.
> Fixing my question: Does it have any positive effect? I mean, with
> regenerating initrd.img after writing out configuration files, the initrd
> contains the value we want to set for the first boot after installation.
> 
> So I believe we can drop writing out this boot option from anaconda, right?

Yes, I think that is correct.

I think I should test this by editing the command line in grub ...

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