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.
what is the contents of your /etc/vconsole.conf ?? Also, what is the output of: # lsinitrd -f /etc/vconsole.conf
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
What is your kernel command line? # cat /proc/cmdline
$ 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)
double checking to be sure. What is the output of: $ lsinitrd | grep fr-bepo $ lsinitrd | grep vconsole $ lsinitrd | grep loadkeys
Created attachment 1458283 [details] output results See attachement.
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
Created attachment 1458388 [details] Keyboard setting in the installer
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
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.
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.
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.