Description of problem:
I installed Fedora 24 selecting the Italian language and the Italian keymap. I encrypted the partitions of the new system, choosing Fedor@ as password.
The encryption passphrase entered during installation does not work on boot of the installed system. That's because the layout is the standard one (US) and not the one I chose during the installation (IT).
The compose is "Fedora_24_Alpha_1.1", and I've hit the issue with both Workstation and KDE ISOs.
The component is just a guess, I don't know if the problem is related to Anaconda.
Version-Release number of relevant components:
Steps to Reproduce:
1. Boot the installer.
2. On the Welcome screen, choose a non-English European language, such as Italian, and click Continue.
3. Click INSTALLATION DESTINATION, and check Encrypt my data.
4. Choose the following passphrase (the "@" character is located on a different position on Italian keyboards): Fedor@
5. Use the same password for "root" nor for another user account.
6. Complete the installation, making sensible choices when Anaconda requires the user's interaction.
7. Boot the installed system.
1. The encryption keymap is the standard one (US).
2. The layout actually changes during the boot, in the following steps. For instance, gnome-initial-setup and sddm know that the user chose the Italian language.
1. The encryption keymap should be the one chosen by the user.
I'm testing with qemu-kvm, but I don't think it's relevant, since I'm pretty sure things were working as expected in the past.
Proposed as a Blocker for 24-final by Fedora user juliuxpigface using the blocker tracking app because:
this bug seems to violate the "2.4.2 Keyboard layout configuration" for Fedora 24 Final.
"If a particular keyboard layout has been configured for the system, that keyboard layout must be used:
- when unlocking encrypted storage volumes during boot"
anaconda is setting KEYMAP="it" in /etc/vconsole.conf in both the root filesystem and the initrd.
I'm not sure about this one - I vote for further testing.
Discussed at today's blocker review meeting . Voted as AcceptedBlocker (Final) - as described, this is a clear violation of "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When unlocking encrypted storage volumes during boot"
For the record, https://bugzilla.redhat.com/show_bug.cgi?id=681250 was mentioned in the blocker review discussion, but this does not appear to be a case of that. Italian is not a 'switched' layout, just a Latin QWERTY variant, so it should indeed be used when entering the encryption passphrase.
I've installed a qemu-kvm guest from "Fedora-Workstation-netinst-x86_64-24-20160407.n.2.iso" and I can't reproduce the issue anymore.
It seems fixed, but I'll test with lives as soon as possible (in order to see what happens there).
Ok... This is interesting...
These days, I've been testing the compose 20160419. The issue is always reproducible with the Workstation Live, but it's not with the Workstation Netinstall.
I used the same password (Fedor@) and the very same layout (Italian).
There is something different with the Live, which triggers the issue (or does not set the keymap correctly).
*** Bug 1332296 has been marked as a duplicate of this bug. ***
I confirm this, exactly as Giulio describes it, with today's F24 Workstation live. The 'us' keymap is definitely active when decrypting the disk; once decryption is complete and you reach a tty, 'it' is definitely active.
I get the graphical decryption prompt, in case it makes any difference.
Thinking about it, surely this stage must be handled by dracut? Since it's the root partition that's encrypted, nothing on it can be used (obviously) for the decryption process. On that note, I notice that /boot/initramfs-4.5.4-300.fc24 contains no /etc/vconsole.conf in my affected install. Let's see if I can reproduce Giulio's success with the netinst image, and see if there's a /etc/vconsole.conf in the initramfs in that case...
yep, bingo. Indeed it works for me with the netinst, and indeed the initramfs for that install contains a /etc/vconsole.conf . So I think that's the difference: /etc/vconsole.conf is not winding up in the initramfs after a live install, it does after a traditional install. I don't know what the cause of that is, and this may have to get reassigned to dracut or something, but it's definitely not systemd's fault.
Could somebody who reproduced this please attach logs?
Created attachment 1159893 [details]
I tried this with Czech keyboard layout, US was used during decryption but cz in gdm. You can find tar of the whole /var/log/anaconda attached.
Petr, one of cz or cz-qwerty layouts is a dual layout (together with us), so in that case having a default us layout in plymouth would not be a bug. (Adam, do you remember how to recognize whether it's a single or a dual layout?). I think it would be best to attach logs for the reported problem - "it" layout. It seems we would need logs from both live and netinst install, to compare why there's no /etc/vconsole.conf initramfs in one of those cases.
Created attachment 1161196 [details]
IT layout: /var/log/anaconda/* (from Workstation-Live)
I'm attaching files from /var/log/anaconda. They are coming from an installation of "Fedora-Workstation-Live-x86_64-24-20160524.n.0.iso" on qemu-kvm, where the bug is fully reproducible.
I'm also preparing another guest from today's netinst. I'll upload those other logs as soon as possible.
Created attachment 1161198 [details]
IT layout: /tmp/* (from Workstation-netinst)
I'm attaching relevant files from /tmp/.
They are coming from a session of "Fedora-Workstation-netinst-x86_64-24-20160524.n.0.iso" on qemu-kvm, after the installation of a new guest.
As noted before, this is the case where the bug is not reproducible.
Just a guess..Does there any packages get pulled by netinstall during the process, which are not available to in live?
No, I don't think so. We already know basically what's going on: /etc/vconsole.conf from the installed system does not make it into the initramfs in live installs. It's most likely some kind of ordering issue in terms of when that file gets written vs. when the initramfs gets created, or a difference in the settings for dracut, or something along those lines.
Created attachment 1164236 [details]
ks-script-_gzecil4.log extracted from anaconda.tar
Created attachment 1164237 [details]
packaging.log extracted from anaconda.tar
Created attachment 1164238 [details]
dnf.log extracted from anaconda.tar
Created attachment 1164239 [details]
ks-script-33lfaiop.log extracted from anaconda.tar
Created attachment 1164240 [details]
anaconda.log extracted from anaconda.tar
Created attachment 1164241 [details]
dnf.rpm.log extracted from anaconda.tar
Created attachment 1164242 [details]
storage.log extracted from anaconda.tar
Created attachment 1164243 [details]
journal.log extracted from anaconda.tar
Created attachment 1164244 [details]
ks-script-1wm1931c.log extracted from anaconda.tar
Created attachment 1164245 [details]
program.log extracted from anaconda.tar
Created attachment 1164284 [details]
anaconda.log from French install of Fedora-Workstation-Live-x86_64-24-20160531.n.0.iso
bcl said the other attached logs were not from live installs, so here's mine. I installed in French, with encrypted root, and verified that there's a /mnt/sysimage/etc/vconsole.conf but no etc/vconsole.conf in the initramfs in /mnt/sysimage/boot .
Created attachment 1164285 [details]
*** This bug has been marked as a duplicate of bug 1331834 ***