This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 994180 - Boot-time LUKS passphrase input *always* defaults to en-us
Boot-time LUKS passphrase input *always* defaults to en-us
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
20
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
: Reopened
: 971189 984757 (view as bug list)
Depends On: 1000715
Blocks: F20BetaBlocker
  Show dependency treegraph
 
Reported: 2013-08-06 12:30 EDT by Ricky Burgin
Modified: 2013-12-10 00:37 EST (History)
21 users (show)

See Also:
Fixed In Version: anaconda-20.17-1.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-17 20:07:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ricky Burgin 2013-08-06 12:30:58 EDT
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
Comment 1 Steve Tyler 2013-08-23 12:13:59 EDT
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 ... :-)
Comment 2 Ricky Burgin 2013-08-23 12:18:44 EDT
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.
Comment 3 Steve Tyler 2013-08-23 13:14:05 EDT
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
Comment 4 Ricky Burgin 2013-08-23 13:20:03 EDT
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?
Comment 5 Steve Tyler 2013-08-23 14:10:06 EDT
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
Comment 6 Ricky Burgin 2013-08-23 14:12:56 EDT
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?
Comment 7 Steve Tyler 2013-08-23 14:26:09 EDT
(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 ...
Comment 8 Steve Tyler 2013-08-23 15:41:58 EDT
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
Comment 9 Steve Tyler 2013-08-23 16:01:11 EDT
/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"
Comment 10 Steve Tyler 2013-08-23 17:03:23 EDT
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).
Comment 11 Steve Tyler 2013-08-24 11:41:39 EDT
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
Comment 12 Kamil Páral 2013-08-28 12:33:56 EDT
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/
Comment 13 Steve Tyler 2013-08-28 13:09:37 EDT
Well, the simplest workaround is to do what Ricky did: Assume a US keyboard map and enter your LUKS passphrase.
Comment 14 Ricky Burgin 2013-08-28 13:50:39 EDT
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.
Comment 15 Steve Tyler 2013-08-28 14:07:35 EDT
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.
Comment 16 Steve Tyler 2013-08-28 14:35:51 EDT
(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.
Comment 17 Vratislav Podzimek 2013-08-29 04:15:10 EDT
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
Comment 18 Kamil Páral 2013-08-29 05:35:32 EDT
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.
Comment 19 Lukas Brabec 2013-08-29 07:09:52 EDT
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.
Comment 20 Kamil Páral 2013-08-29 07:26:54 EDT
(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.
Comment 21 Harald Hoyer 2013-08-29 08:07:04 EDT
(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
Comment 22 Harald Hoyer 2013-08-29 08:09:04 EDT
(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.
Comment 23 Lukas Brabec 2013-08-29 09:40:35 EDT
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
Comment 24 Harald Hoyer 2013-08-29 09:45:00 EDT
(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.
Comment 25 Kamil Páral 2013-08-29 09:47:16 EDT
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...
Comment 26 Harald Hoyer 2013-08-29 09:50:53 EDT
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.
Comment 27 Kamil Páral 2013-08-29 10:12:39 EDT
(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?
Comment 28 Harald Hoyer 2013-08-29 10:26:07 EDT
(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
Comment 29 Steve Tyler 2013-08-29 10:32:46 EDT
(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"
$
Comment 30 Steve Tyler 2013-08-29 10:58:28 EDT
(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
Comment 31 Steve Tyler 2013-08-29 11:28:35 EDT
(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/
Comment 32 Harald Hoyer 2013-08-29 11:41:02 EDT
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
Comment 33 Vratislav Podzimek 2013-08-30 05:42:06 EDT
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.
Comment 34 David Shea 2013-09-03 11:47:44 EDT
*** Bug 984757 has been marked as a duplicate of this bug. ***
Comment 35 Kamil Páral 2013-09-04 12:51:47 EDT
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
Comment 36 Vratislav Podzimek 2013-09-05 09:33:25 EDT
Patch posted to anaconda-patches. But I'm not sure it will get applied.
Comment 37 Steve Tyler 2013-09-05 10:11:20 EDT
[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?
Comment 38 Harald Hoyer 2013-09-05 10:26:29 EDT
(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.
Comment 39 Harald Hoyer 2013-09-05 10:29:19 EDT
(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!
Comment 40 Steve Tyler 2013-09-05 10:55:20 EDT
(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@redhat.com>	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
Comment 41 Harald Hoyer 2013-09-05 11:07:32 EDT
(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.
Comment 42 Harald Hoyer 2013-09-05 11:11:25 EDT
(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.
Comment 43 Steve Tyler 2013-09-05 11:35:51 EDT
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.
Comment 44 Harald Hoyer 2013-09-05 11:46:37 EDT
(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..
Comment 45 Steve Tyler 2013-09-05 11:57:51 EDT
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?
Comment 46 Vratislav Podzimek 2013-09-06 04:20:29 EDT
(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.
Comment 47 Harald Hoyer 2013-09-06 04:27:44 EDT
(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
Comment 48 Kamil Páral 2013-09-06 05:57:50 EDT
(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.
Comment 49 Fedora Update System 2013-09-09 20:11:25 EDT
anaconda-20.13-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.13-1.fc20
Comment 50 Fedora Update System 2013-09-10 12:24:35 EDT
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).
Comment 51 Fedora Update System 2013-09-10 15:48:41 EDT
anaconda-20.14-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.14-1.fc20
Comment 52 Fedora Update System 2013-09-11 21:03:39 EDT
anaconda-20.15-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.15-1.fc20
Comment 53 Petr Schindler 2013-09-12 09:04:38 EDT
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.
Comment 54 Fedora Update System 2013-09-13 21:05:23 EDT
anaconda-20.16-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.16-1.fc20
Comment 55 Fedora Update System 2013-09-16 13:48:30 EDT
anaconda-20.17-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.17-1.fc20
Comment 56 Fedora Update System 2013-09-18 22:41:15 EDT
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.
Comment 57 Adam Williamson 2013-10-16 16:09:08 EDT
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.
Comment 58 Adam Williamson 2013-10-16 16:12:47 EDT
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.
Comment 59 Adam Williamson 2013-10-16 16:15:42 EDT
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.
Comment 60 Vratislav Podzimek 2013-10-17 04:23:18 EDT
(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)?
Comment 61 Adam Williamson 2013-10-17 13:33:45 EDT
Well it's 100% reproducible with the detailed steps above, but if you want me to do it over, sure, I guess.
Comment 62 Adam Williamson 2013-10-17 20:07:37 EDT
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...
Comment 63 Adam Williamson 2013-12-10 00:37:20 EST
*** Bug 971189 has been marked as a duplicate of this bug. ***

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