Bug 1592859

Summary: english keyboard layout used for encryption passphrase after update
Product: [Fedora] Fedora Reporter: Kevin Raymond <kraymond>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: anaconda-maint-list, dracut-maint-list, harald, jonathan, kellin, kraymond, vanmeeuwen+fedora, vponcova, wwoods, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-28 21:50:35 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:
Attachments:
Description Flags
output results
none
Keyboard setting in the installer none

Description Kevin Raymond 2018-06-19 13:23:48 UTC
Description of problem:
Installed Fedora from a live usb key,
setting keyboard layout as needed
the Installer warn about non default keyboard layout (bepo, dvorak like)
I agree with the risks.. "You won't be able to change it afterward" Ok, let's apply, I can always fill another key slot.

Reboot is great, I can unlock the disk.
However, after kernel updates, I can't unlock my disks (luks encrypted).
Only the original kernel grub entry works with by current layout...

I had the exact same issue years ago (Fedora 18), BZ-881624

Version-Release number of selected component (if applicable):
Fresh install from the F28 live usb Desktop image


How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
I have just used cryptsetup and brutforced my current passphrase.. It works with  an english default layout... Which is not the one I set during the installation (anaconda) phase.

Comment 1 Harald Hoyer 2018-07-05 13:16:22 UTC
what is the contents of your /etc/vconsole.conf ??

Also, what is the output of:

# lsinitrd -f /etc/vconsole.conf

Comment 2 Kevin Raymond 2018-07-09 07:58:18 UTC
yo mean under dracut? Once fully booted, I have the following:

$ cat /etc/vconsole.conf
KEYMAP=fr-bepo
FONT=eurlatgr

# lsinitrd -f /etc/vconsole.conf
KEYMAP=fr-bepo
FONT=eurlatgr

Comment 3 Harald Hoyer 2018-07-09 12:15:19 UTC
What is your kernel command line?

# cat /proc/cmdline

Comment 4 Kevin Raymond 2018-07-09 12:38:43 UTC
$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.16.16-300.fc28.x86_64 root=/dev/mapper/luks-3da1446d-45f6-4442-8eb6-a91a407a6a22 ro resume=/dev/mapper/luks-e0edfe73-ef48-42ce-a289-6d455bfee05d rd.luks.uuid=luks-3da1446d-45f6-4442-8eb6-a91a407a6a22 rd.luks.uuid=luks-e0edfe73-ef48-42ce-a289-6d455bfee05d rhgb quiet LANG=fr_FR.UTF-8

$ cat /etc/locale.conf 
LANG="fr_FR.UTF-8"

Checking the grub entries, I only have the "LANG=fr_FR.UTF-8" kernel option added but for the "rescue" entry. I forgot if the only working one (i.e. using the fr-bepo layout is the first one, or the "rescue" one).
If needed I will reboot and check that, please tell me then if you need any dracut command results (I really hate rebooting this desktop)

Comment 5 Harald Hoyer 2018-07-12 05:57:14 UTC
double checking to be sure. What is the output of:

$ lsinitrd | grep fr-bepo
$ lsinitrd | grep vconsole
$ lsinitrd | grep loadkeys

Comment 6 Kevin Raymond 2018-07-12 08:10:04 UTC
Created attachment 1458283 [details]
output results

See attachement.

Comment 7 Harald Hoyer 2018-07-12 12:28:28 UTC
You might have forgotten to additionally switch the installer to the keyboard layout after setting up your keyboard.

It can be easily forgotten.

See attachement

Comment 8 Harald Hoyer 2018-07-12 12:29:12 UTC
Created attachment 1458388 [details]
Keyboard setting in the installer

Comment 9 Kevin Raymond 2018-07-12 12:52:55 UTC
Hum, you're probably right.
I kinda tested the new Anaconda.

I used to login, change keyboard layout, logout/in and restart the install process under the right keyboard layout.

I remember this time not having to logout/in, the whole install process has been done using the fr-bepo layout (the password prompt screen might have use the not expected one).
There might be improvement on this (changing keyboard layout or user locale without login out).

What really interest me is why the first grub entry use a different layout (kernel locale cmdline?). The expected layout works with the first used grub entry after the fresh install, all entries added later on use the standard US layout.

Ok I got it.. I have to type my luks password under bepo but my original one converted in US. That is, Typing "qwerty" instead of "bépo ". Which is exactly what you told me (wrong layout during the anaconda stage/password prompt).

I am sure to have used the bepo layout at anaconda stage (I don't have standard keyboard, and just can't use traditional layout, I am too slow).

Could there be a layout switch between the anaconda installer and the luks password prompt? That might be really surprising.

Thanks for the investigation

Comment 10 Harald Hoyer 2018-07-12 13:13:04 UTC
Reassigning this bug to anaconda. This is really really error prone!

The user can switch the desktop to the correct keyboard layout, but the installer uses "US" unless the user clicks the easy missed keyboard selection button.

Comment 11 Ben Cotton 2019-05-02 21:19:27 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Ben Cotton 2019-05-28 21:50:35 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.