Hide Forgot
Description of problem: When selecting a keyboard language/input in anaconda, it still defaults to en-us (I selected en-gb), a problem when inputting a passphrase containing symbols for LUKS. When changing the region/input settings on the live image, it appears to take effect in anaconda, however on reboot it defaults back to en-us (because I happen to know both layouts and tried both). Version-Release number of selected component (if applicable): 029-2.fc19 How reproducible: Always, for en-gb and probably other inputs aside from en-us and matching layouts. Steps to Reproduce: 1. Run F19 live CD/usb, go to install 2. Attempt to enable en-gb keyboard layout whatever way you can think of. Install LUKS system and use characters which change position between en-us and en-gb layouts. 3. Reboot and attempt LUKS passphrase at boot Actual results: Could not decrypt volumes using expected passphrase in expected key positions. Expected results: To be able to type my passphrase in properly in the keyboard layout I selected. Additional info: Appears to be related to a previous bug which was closed: https://bugzilla.redhat.com/show_bug.cgi?id=875567
Thanks for your report. > Install LUKS system and use characters which change position between en-us and en-gb layouts. Could you provide an example of one such character and the two keys? There are a lot of keys on a keyboard ... :-)
Hi Steve, Thanks for responding, and sorry for not being more specific. For example on a typical UK keyboard layout the '@' key is swapped with '"' on a US (and some other) keyboards. There are other differences too. For reference: US Keyboard: http://www.goodtyping.com/teclatUSok.png UK Keyboard: http://www.bristol.ac.uk/it-services/learning/documentation/keyboard-1/keyboard-r1-6.gif Particularly the keys to the right side of the alphabetic keys and the shifted keys on the horizontal numeric keys above. You will see that '£' is introduced and '#' is moved too.
Thanks, Ricky. And thanks for the links. With a US keyboard and the English (UK) layout: '"' -> '@' '@' -> '"' '#' -> '£' '\' -> '#' Tested with the F19 DVD. The DVD lets you test the keyboard layout by typing in a text box on the right side of the Keyboard Layout dialog. The Live image has that text box disabled, so the DVD may be a better choice when you need to work with more than one keyboard layout. Have you tried the DVD? $ qemu-kvm -m 4096 -hda f19-test-3.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on
Steve, I investigated a little further. Firstly anaconda doesn't seem to change keyboard layouts properly on the live CD, you must change the settings in Fedora itself through the UI as you would on a typical Fedora installation, *then* run anaconda. But even if I do that, and even if LUKS is installed and kernel params are passed to have LUKS start with en_gb keyboard support, when LUKS asks for the passphrase, it takes input in the en_us format. That is how it appears to be happening for me. I have not tried the DVD, but it is most definitely happening for the live CD. Unfortunately, I was provisioning a desktop for a friend and this prevented me from doing it at the time and so he's now on a different distro that handled keyboard input and LUKS properly. Right now I have no free systems that I'd be happy testing F19 out on, so I'm afraid I can't test the DVD image to see if it does the same. Regardless, should this not be looked into?
Thanks for the additional info. Could you post the output of the following? $ localectl $ cat /proc/cmdline Using the F19 DVD, I installed with the English (UK) keyboard layout and a LUKS passphrase containing the '#' character. The passphrase successfully unlocked the LUKS devices upon rebooting from the installer. Upon login, the keyboard is configured with the English (UK) layout (the keymap follows Comment 3). [joeblow@localhost ~]$ localectl System Locale: LANG=en_US.UTF-8 VC Keymap: uk X11 Layout: gb,us X11 Variant: , [joeblow@localhost ~]$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.9.5-301.fc19.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.luks.uuid=luks-a5337f59-028e-4a93-84a6-e28243986926 rd.md=0 rd.dm=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root vconsole.keymap=uk rhgb quiet Tested with: $ qemu-kvm -m 4096 -hda f19-test-3.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on
I'm afraid I not near a computer that could do this right now. Could you try doing testing with the live CD and see if you can reproduce the issue?
(In reply to Ricky Burgin from comment #6) > I'm afraid I not near a computer that could do this right now. Could you try > doing testing with the live CD and see if you can reproduce the issue? There is no hurry. The anaconda developers have a lot of bugs to work on ...
Reproduced with the F19 Live image. You have to configure the keyboard layout in the Live environment, not in the installer. The rationale for this has never been clear to me, but that is what I have read. The proximate cause appears to be that the kernel command-line is being configured with: vconsole.keymap=us instead of: vconsole.keymap=uk (Comment 5) [joeblow@localhost ~]$ localectl System Locale: LANG=en_GB.UTF-8 VC Keymap: us X11 Layout: us,gb X11 Variant: , X11 Options: grp:alt_shift_toggle [joeblow@localhost ~]$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.9.5-301.fc19.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 vconsole.keymap=us vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rd.luks.uuid=luks-f94de295-ec33-4b52-a387-d98d46b40a1c rhgb quiet Tested with: $ qemu-kvm -m 4096 -hda f19-test-4.img -cdrom ~/xfr/fedora/F19/Fedora-Live-Desktop-x86_64-19-1.iso -vga std -boot menu=on
/etc/default/grub also has the incorrect configuration: vconsole.keymap=us I tried changing that to "vconsole.keymap=uk" and running: # grub2-mkconfig -o /boot/grub2/grub.cfg After rebooting, I still could not unlock the LUKS devices assuming the English (UK) keyboard layout. I needed to assume the English (US) layout. $ cat f19-live-etc-default-grub-1.txt GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 vconsole.keymap=us $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rd.luks.uuid=luks-f94de295-ec33-4b52-a387-d98d46b40a1c rhgb quiet" GRUB_DISABLE_RECOVERY="true"
After running all of these, I can unlock the LUKS devices assuming an English (UK) keyboard layout: $ sudo localectl set-keymap uk $ sudo localectl set-x11-keymap gb,us $ sudo dracut -f # initramfs has /etc/vconsole.conf per $ sudo lsinitrd $ reboot For the record, the DVD results were essential to telling me what those config. options should be. (Comment 5) A remaining problem is that in gnome-terminal, the keyboard layout is still English (US). The keyboard layout in a console, however, is English (UK).
Proposed Alpha blocker under this criterion: "In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s)." https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
Discussed at 2013-08-28 blocker review meeting [1]. This doesn't seem like an alpha blocker with the existing workarounds but we want to make sure those workarounds actually _work_ before rejecting. Will revisit at the next blocker review meeting. If anyone can test all available combinations (DVD, Live, setting keymap only in GNOME, setting keymap in GNOME and in Anaconda) and workarounds (adjusting kernel boot line, using localectl, anything else) and report what works and what does not, it would be very welcome. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-08-28/
Well, the simplest workaround is to do what Ricky did: Assume a US keyboard map and enter your LUKS passphrase.
Although I note that I ended up not using Fedora for that specific machine due to the passphrase needing to contain characters that differ between en_US and other keyboards like en_GB and me likely forgetting it's set to en_US input at some point.
Thanks for clarifying that. I was wondering what you decided to do. The other workaround is to try to get everything put back in the right place: Comment 10.
(In reply to Kamil Páral from comment #12) ... > If anyone can test all available combinations (DVD, Live, setting keymap > only in GNOME, setting keymap in GNOME and in Anaconda) and workarounds > (adjusting kernel boot line, using localectl, anything else) and report what > works and what does not, it would be very welcome. This is not a problem with the DVD: Comment 5.
I think the problem here lies in a bit cryptic way keyboard configuration on live installation works. The Keyboard spoke on live installation [1] says, that the configuration only applies to the installed system and a desktop's tool should be used to configure keyboard for the installation process. The main reason for that is that there is no unified way of communication with those tools and thus the installer has no way to find out what the user has configured via those tools on various desktop environments the live installation may run in. But, for the same reason, the keyboard configuration set in the installer for the installed system is the one that is applied to the installed system. So to get both the installation with the 'gb' layout and the installed system with the 'gb' layout, it is necessary to set 'gb' layout in both the installer and the desktop's tool. Steve, could you please test whether that works or not? [1] http://media.if-not-true-then-false.com/2013/07/07-Fedora-19-Schrodingers-Cat-select-keyboard-layout.png
This also applies to Fedora 20 Alpha TC1, changing version. It's also what we have accepted the bug as a blocker for. It seems it have been nominated for Fedora _20_ blocker by mistake, because the original reporter speaks about Fedora 19, but the bug is still present in F20 according to Lukas Brabec's testing. He will provide more information soon.
Tested F20 Alpha TC1 Live Desktop 1. Boot live iso 2. In system setting set UK (swapped @ and ") or CZ layout (swapped y and z) 3. Check (or set) same layout in Anaconda 4. Set passphrase for disc encryption using swapped chars 5. Install & reboot 6. In grub, kernel line contains proper layout option 7. Despite that Plymouth uses US layout, password typed 'as with US layout' is accepted Using characters that are not on classic US layout will probably result in undecryptable disc.
(In reply to Lukas Brabec from comment #19) > 6. In grub, kernel line contains proper layout option e.g. vconsole.keymap=cz-lat2 or vconsole.keymap=uk Reassigning to plymouth, this is not an anaconda problem.
(In reply to Kamil Páral from comment #20) > (In reply to Lukas Brabec from comment #19) > > 6. In grub, kernel line contains proper layout option > e.g. vconsole.keymap=cz-lat2 or vconsole.keymap=uk > > Reassigning to plymouth, this is not an anaconda problem. plymouth does not set the keyboard. It's systemd in the initramfs. Anaconda should have written /etc/vconsole.conf and /etc/locale.conf before doing the yum transaction, where in %posttrans the initramfs gets created. What is the contents of vconsole.conf in the initramfs? What keymaps are included in the initramfs? # lsinitrd -f /etc/vconsole.conf KEYMAP="de-latin1-nodeadkeys" UNICODE="1" FONT="latarcyrheb-sun16" # lsinitrd -f /etc/locale.conf LC_ALL="C" LANG="de_DE.UTF-8" # lsinitrd | grep keymaps drwxr-xr-x 4 root root 0 Aug 28 09:08 usr/lib/kbd/keymaps drwxr-xr-x 4 root root 0 Aug 28 09:08 usr/lib/kbd/keymaps/i386 drwxr-xr-x 2 root root 0 Aug 28 09:08 usr/lib/kbd/keymaps/i386/include -rw-r--r-- 1 root root 278 May 23 16:44 usr/lib/kbd/keymaps/i386/include/compose.inc -rw-r--r-- 1 root root 253 May 23 16:44 usr/lib/kbd/keymaps/i386/include/euro2.map -rw-r--r-- 1 root root 4353 May 23 16:44 usr/lib/kbd/keymaps/i386/include/linux-keys-bare.inc -rw-r--r-- 1 root root 746 May 23 16:44 usr/lib/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc -rw-r--r-- 1 root root 456 May 23 16:44 usr/lib/kbd/keymaps/i386/include/qwertz-layout.inc drwxr-xr-x 2 root root 0 Aug 28 09:08 usr/lib/kbd/keymaps/i386/qwertz -rw-r--r-- 1 root root 2359 May 23 16:44 usr/lib/kbd/keymaps/i386/qwertz/de-latin1.map -rw-r--r-- 1 root root 493 May 23 16:44 usr/lib/kbd/keymaps/i386/qwertz/de-latin1-nodeadkeys.map drwxr-xr-x 2 root root 0 Aug 28 09:08 usr/lib/kbd/keymaps/include -rw-r--r-- 1 root root 517 May 23 16:44 usr/lib/kbd/keymaps/include/compose.8859_7 -rw-r--r-- 1 root root 23 May 23 16:44 usr/lib/kbd/keymaps/include/compose.8859_8 -rw-r--r-- 1 root root 6030 May 23 16:44 usr/lib/kbd/keymaps/include/compose.latin -rw-r--r-- 1 root root 3889 May 23 16:44 usr/lib/kbd/keymaps/include/compose.latin1 -rw-r--r-- 1 root root 3465 May 23 16:44 usr/lib/kbd/keymaps/include/compose.latin2 -rw-r--r-- 1 root root 2037 May 23 16:44 usr/lib/kbd/keymaps/include/compose.latin3 -rw-r--r-- 1 root root 2897 May 23 16:44 usr/lib/kbd/keymaps/include/compose.latin4
(In reply to Harald Hoyer from comment #21) > Anaconda should have written /etc/vconsole.conf and /etc/locale.conf before > doing the yum transaction, where in %posttrans the initramfs gets created. Or in case of a LiveCD, after copying the root image to disk, it should set /etc/vconsole.conf and /etc/locale.conf correctly and then call dracut to create the initramfs.
On system with CZ layout set during installation from Live CD # lsinitrd -f /etc/vconsole.conf KEYMAP="us" UNICODE="1" FONT="latarcyrheb-sun16" # lsinitrd -f /etc/locale.conf LC_ALL="C" LANG="en_US.UTF-8" # lsinitrd | grep keymaps drwxr-xr-x 4 root root 0 Aug 29 06:40 usr/lib/kbd/keymaps drwxr-xr-x 3 root root 0 Aug 29 06:40 usr/lib/kbd/keymaps/i386 drwxr-xr-x 2 root root 0 Aug 29 06:40 usr/lib/kbd/keymaps/i386/qwerty -rw-r--r-- 1 root root 122299 Aug 3 21:32 usr/lib/kbd/keymaps/i386/qwerty/us.map drwxr-xr-x 2 root root 0 Aug 29 06:40 usr/lib/kbd/keymaps/xkb -rw-r--r-- 1 root root 3619 Aug 3 21:32 usr/lib/kbd/keymaps/xkb/us.map.gz
(In reply to Lukas Brabec from comment #23) > On system with CZ layout set during installation from Live CD > > # lsinitrd -f /etc/vconsole.conf > KEYMAP="us" > UNICODE="1" > FONT="latarcyrheb-sun16" > > # lsinitrd -f /etc/locale.conf > LC_ALL="C" > LANG="en_US.UTF-8" > > # lsinitrd | grep keymaps > drwxr-xr-x 4 root root 0 Aug 29 06:40 usr/lib/kbd/keymaps > drwxr-xr-x 3 root root 0 Aug 29 06:40 > usr/lib/kbd/keymaps/i386 > drwxr-xr-x 2 root root 0 Aug 29 06:40 > usr/lib/kbd/keymaps/i386/qwerty > -rw-r--r-- 1 root root 122299 Aug 3 21:32 > usr/lib/kbd/keymaps/i386/qwerty/us.map > drwxr-xr-x 2 root root 0 Aug 29 06:40 > usr/lib/kbd/keymaps/xkb > -rw-r--r-- 1 root root 3619 Aug 3 21:32 > usr/lib/kbd/keymaps/xkb/us.map.gz so, dracut was run in hostonly mode on a system where it found these vconsole.conf and locale.conf configurations.
Thanks, Harald. It seems that Anaconda fails to populate the config files properly before creating initramfs. I guess that vconsole kernel cmdline option has preference before /etc/vconsole.conf in initramfs, but it doesn't really help when the very keymap file is missing...
One easy way out for the LiveCD would be to call dracut with --no-hostonly to disable the hostonly mode for the initial initramfs image.
(In reply to Harald Hoyer from comment #26) > One easy way out for the LiveCD would be to call dracut with --no-hostonly > to disable the hostonly mode for the initial initramfs image. But once the installed system receives a kernel update, we would end up in the same situation, wouldn't we?
(In reply to Kamil Páral from comment #27) > (In reply to Harald Hoyer from comment #26) > > One easy way out for the LiveCD would be to call dracut with --no-hostonly > > to disable the hostonly mode for the initial initramfs image. > > But once the installed system receives a kernel update, we would end up in > the same situation, wouldn't we? not, if /etc/vconsole.conf and /etc/locale.conf are correctly setup in the installed real root filesystem
(In reply to Kamil Páral from comment #27) > (In reply to Harald Hoyer from comment #26) > > One easy way out for the LiveCD would be to call dracut with --no-hostonly > > to disable the hostonly mode for the initial initramfs image. > > But once the installed system receives a kernel update, we would end up in > the same situation, wouldn't we? The installed files in /etc have the correct configuration (Comment 8): $ localectl If the problem is with the initramfs, it may be possible to login with the expected keyboard map by booting the rescue kernel. The rescue initramfs does not have /etc/vconsole.conf, so systemd will use the installed /etc/vconsole.conf: $ sudo lsinitrd /boot/initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img /etc/vconsole.conf $ sudo lsinitrd /boot/initramfs-3.10.9-200.fc19.x86_64.img /etc/vconsole.conf KEYMAP="us" UNICODE="1" FONT="latarcyrheb-sun16" $
(In reply to Vratislav Podzimek from comment #17) > ... > The main reason for that is that there is no unified way of communication with > those tools and thus the installer has no way to find out what the user has > configured via those tools on various desktop environments the live > installation may run in. ... systemd is running on the Live image. More specifically, systemd-localed is running, so the installer on the Live image can indeed find out the locale configuration of the host: $ localectl
(In reply to Steve Tyler from comment #30) > (In reply to Vratislav Podzimek from comment #17) > > ... > ... More specifically, systemd-localed is > running, so the installer on the Live image can indeed find out the locale > configuration of the host: > $ localectl The localed API is documented here: http://www.freedesktop.org/wiki/Software/systemd/localed/
Well, apparently anaconda know what to write to vconsole.conf and locale.conf. The installer either did: 1. start dracut from within the LiveCD root with unmodified vconsole.conf and locale.conf or 2. start dracut from within the installation root _before_ it modified vconsole.conf and locale.conf
I think it's nonsense to generate initrd twice in every installation just for the initrd to be 1MB (size of all keymaps together) smaller. The difference in the boot time is too small to balance the non-working boot option. --hostonly means that the initrd is generated for the particular host, the HW that exists in the host. But not for one particular *configuration* of the host. This really is not a good trade off. Anaconda, logically, configures the system once all packages are installed. And I really don't want to put keyboard configuration (or language, network, ... as well?) somewhere else just to fix the dracut's issue with a boot option not working properly.
*** Bug 984757 has been marked as a duplicate of this bug. ***
Discussed at 2013-09-04 blocker review meeting [1]. This is accepted as an Alpha blocker, because it violates the following F20 alpha release criterion for systems with a non-us keyboard and encrypted disks: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." [2] Also "In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s)." [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-09-04/ [2] https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
Patch posted to anaconda-patches. But I'm not sure it will get applied.
[master] Problematic patch I'm not sure we want to apply https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/005701.html The problem here is that dracut is trying to shadow config files from the host environment in initramfs. This patch shows the workarounds that are needed to keep the two in sync. We already removed /etc/adjtime and /etc/localtime from initramfs, because of similar problems: Bug 981617 - please take /etc/adjtime out of the initramfs so it doesn't override the existing file system version Harald: Why do we need /etc/vconsole.conf in initramfs?
(In reply to Steve Tyler from comment #37) > Harald: Why do we need /etc/vconsole.conf in initramfs? Some people complained about packaging all possible keyboard files and fonts in the initramfs. So either we only package those present in /etc/vconsole.conf or we package all fonts and keyboard layouts.
(In reply to Steve Tyler from comment #37) > [master] Problematic patch I'm not sure we want to apply > https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/ > 005701.html > I don't understand why you want to regenerate the initramfs? Just populate /etc/vconsole.conf and /etc/locale.conf before the yum transaction!
(In reply to Harald Hoyer from comment #38) > (In reply to Steve Tyler from comment #37) > > Harald: Why do we need /etc/vconsole.conf in initramfs? > > Some people complained about packaging all possible keyboard files and fonts > in the initramfs. > > So either we only package those present in /etc/vconsole.conf or we package > all fonts and keyboard layouts. That's not what I was asking. Why do we need any of those file at all in initramfs? Why can't they all be found on the host file system? ISTM, shadowing config files in initramfs is always going to cause problems.[1] Comment 39 is for Vratislav ... [1] Revert "base: setup correct system time and time zone in initrd" author Harald Hoyer <harald> 2013-07-31 13:55:13 (GMT) This reverts commit 77364fd6bb01ea184db73b1a5ad05da984752293. Too many problems with adjtime in the initramfs https://bugzilla.redhat.com/show_bug.cgi?id=981617 http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=d27cd4dfdd51c7f5178c5f4cb8f5bf4668228995
(In reply to Steve Tyler from comment #40) > (In reply to Harald Hoyer from comment #38) > > (In reply to Steve Tyler from comment #37) > > > Harald: Why do we need /etc/vconsole.conf in initramfs? > > > > Some people complained about packaging all possible keyboard files and fonts > > in the initramfs. > > > > So either we only package those present in /etc/vconsole.conf or we package > > all fonts and keyboard layouts. > > That's not what I was asking. Why do we need any of those file at all in > initramfs? Why can't they all be found on the host file system? > > ISTM, shadowing config files in initramfs is always going to cause > problems.[1] Well, you can't access the root filesystem, if it is encrypted without typing a password, which needs proper keyboard layout and unicode setting, therefore you need the keymaps and unicode (according to the language) set.
(In reply to Harald Hoyer from comment #41) > (In reply to Steve Tyler from comment #40) > > (In reply to Harald Hoyer from comment #38) > > > (In reply to Steve Tyler from comment #37) > > > > Harald: Why do we need /etc/vconsole.conf in initramfs? > > > > > > Some people complained about packaging all possible keyboard files and fonts > > > in the initramfs. > > > > > > So either we only package those present in /etc/vconsole.conf or we package > > > all fonts and keyboard layouts. > > > > That's not what I was asking. Why do we need any of those file at all in > > initramfs? Why can't they all be found on the host file system? > > > > ISTM, shadowing config files in initramfs is always going to cause > > problems.[1] > > Well, you can't access the root filesystem, if it is encrypted without > typing a password, which needs proper keyboard layout and unicode setting, > therefore you need the keymaps and unicode (according to the language) set. Same goes for /etc/mdadm.conf and /etc/crypttab and /etc/lvm.conf. We can't just express everything on the kernel command line. Only the simple case works here. And you can't access these files, because you need them to assemble the root file system, which holds these files.
Well, you are stuck between a rock and a hard place ... :-) IIUC, none of the files in question need to be encrypted, so why should they ever be encrypted? And putting the keyboard layout on the kernel command-line is just a variant of shadowing config files in initramfs. It has the same problem -- a change on the host does not get reflected in the kernel command-line without someone explicitly rebuilding the kernel command-line.
(In reply to Steve Tyler from comment #43) > Well, you are stuck between a rock and a hard place ... :-) > > IIUC, none of the files in question need to be encrypted, so why should they > ever be encrypted? > > And putting the keyboard layout on the kernel command-line is just a variant > of shadowing config files in initramfs. It has the same problem -- a change > on the host does not get reflected in the kernel command-line without > someone explicitly rebuilding the kernel command-line. Come on! Really? We nowadays encrypt the whole block device, the root filesystem lives on..
You didn't answer my question. What on the root file system really needs to be encrypted? /etc/shadow, /etc/passwd and what else? Encrypting the whole file system may be simple, but it doesn't work if there are files on it required for unlocking it. /boot is never encrypted, though. Right?
(In reply to Harald Hoyer from comment #39) > (In reply to Steve Tyler from comment #37) > > [master] Problematic patch I'm not sure we want to apply > > https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/ > > 005701.html > > > > I don't understand why you want to regenerate the initramfs? > Just populate /etc/vconsole.conf and /etc/locale.conf before the yum > transaction! Because I don't want to introduce hacks and exceptions to the installer code. And more important, I don't want to do that again next time when there appears to be another file that needs to be written out before the initrd is generated.
(In reply to Vratislav Podzimek from comment #46) > (In reply to Harald Hoyer from comment #39) > > (In reply to Steve Tyler from comment #37) > > > [master] Problematic patch I'm not sure we want to apply > > > https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/ > > > 005701.html > > > > > > > I don't understand why you want to regenerate the initramfs? > > Just populate /etc/vconsole.conf and /etc/locale.conf before the yum > > transaction! > Because I don't want to introduce hacks and exceptions to the installer > code. And more important, I don't want to do that again next time when there > appears to be another file that needs to be written out before the initrd is > generated. ok, fine with me
(In reply to Harald Hoyer from comment #39) > I don't understand why you want to regenerate the initramfs? > Just populate /etc/vconsole.conf and /etc/locale.conf before the yum > transaction! The yum transaction installs the whole system, so Vratislav would have to keep a separate copy of those config files in anaconda source code and check periodically whether the config file wasn't changed (new options, different defaults) in the corresponding packages. That's not manageable in the long run. The clean solution here is to regenerate initrd after installation, but it adds installation time. (In reply to Steve Tyler from comment #45) > /boot is never encrypted, though. Right? If you propose to copy those config files to /boot, it has some benefits and some drawbacks, but it's such a major change that it should be part of a different discussion, not this bug report. Feel free to use fedora-devel@ for that. One more thing, please don't confuse Bugzilla with a discussion forum. If you have some interesting idea how to fix things, provide a well written proposal a single comment. If you want to have a sentence-by-sentence discussion with someone, use IRC or mailing list for that. We want to keep the Bugzilla reports clear. There are many people (more than just the 19 subscribed) who need to read this, QA and devel.
anaconda-20.13-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.13-1.fc20
Package anaconda-20.13-1.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 anaconda-20.13-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16296/anaconda-20.13-1.fc20 then log in and leave karma (feedback).
anaconda-20.14-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.14-1.fc20
anaconda-20.15-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.15-1.fc20
It works with anaconda-20.15-1.fc20. I used czech keyboard layout during installation and setting password. The same layout was used during boot.
anaconda-20.16-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.16-1.fc20
anaconda-20.17-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.17-1.fc20
anaconda-20.17-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This bug still seems to be valid as of Beta TC4. It is probably another symptom of anaconda not re-generating initramfs to reflect the install time configuration, which I think there's another bug report for, but can't find right now.
Proposing as a Beta blocker, Alpha criterion https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_installed_system_boot_behavior : "...In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s)." violated in the case that the passphrase was entered using a non-US keymap and contains characters that differ vs. a US keymap.
My test: install from TC4 DVD, pick English (Canada) as locale, go to Keyboard spoke, add English (UK) layout, move it to the top of the list, verify it is active using the test box, go to disk partitioning, check 'Encrypt my data' (or whatever it's called), enter passphrase correcthorse" (using the UK key for ", shift-2, noting that the keyboard layout indicator shows "gb"), complete the install, boot the installed system, at passphrase entry, type correcthorse" using the same " key as used during install, see passphrase entry dialog come up again, type correcthorse" using the US key for ", see that it works.
(In reply to Adam Williamson from comment #57) > This bug still seems to be valid as of Beta TC4. It is probably another > symptom of anaconda not re-generating initramfs to reflect the install time > configuration, which I think there's another bug report for, but can't find > right now. The fix for this bug *was* re-generating initramfs after package installation. Could you please attach logs from the installation (especially the anaconda.log and program.log)?
Well it's 100% reproducible with the detailed steps above, but if you want me to do it over, sure, I guess.
Hum. Tested with TC5 and it works. Seems odd. I'll verify it again later, as I can't see anything in TC5 which ought to change this...
*** Bug 971189 has been marked as a duplicate of this bug. ***