Bug 875567
Summary: | anaconda doesnt set keyboard layout for LUKS password at reboot | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jan Teichmann <jan.teichmann> | ||||
Component: | anaconda | Assignee: | Vratislav Podzimek <vpodzime> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 18 | CC: | abj0000, awilliam, germano.massullo, g.kaviyarasu, harald, jonathan, mfabian, ricky, sbueno, vanmeeuwen+fedora | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | AcceptedNTH | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-01-02 21:51:02 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: | 752665 | ||||||
Attachments: |
|
Description
Jan Teichmann
2012-11-12 02:32:33 UTC
*** This bug has been marked as a duplicate of bug 878433 *** It turns out this could be a different issue. 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. 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? (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? 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
Should 'vconsole.keymap=fr' or something like that be appended? (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) 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). 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 ? (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. Patch ported to F18-branch and should appear in the next build for F18. 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 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). *** Bug 890537 has been marked as a duplicate of this bug. *** 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. This bug is also occurring in the Fedora 19 live image for me, precisely as described in this report. 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. 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. 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. 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. (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? (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. (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? (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 ... |