[Fedora-i18n-bugs] [Bug 1405539] Changing the default keyboard layout changes also disk decryption in plymouth, but only after next kernel update (initramfs rebuild), long afterwards
https://bugzilla.redhat.com/show_bug.cgi?id=1405539
Hans de Goede <hdegoede(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hdegoede(a)redhat.com
--- Comment #50 from Hans de Goede <hdegoede(a)redhat.com> ---
So this is somewhat related to bug 1059485 where I just added the following
comment:
"I'm not convinced regenerating the initrd is a good idea, we do kernel-updates
often enough that users will pick-up the new plymouth soon enough and if the
new plymouth contains some bug breaking the boot, then regenerating the initrd
means we've just broken the users system in a way which is quite hard to
recover from."
This is different though, because we are not changing plymouth at the same
time, except if the user has also installed a plymouth updated and not rebooted
since ...
I think we may need some way to boot a backup initrd and maybe then we can
consider regenerating the initrd.
Hmm, thinking more about this, plymouth uses the console keymap for input, and
the initrd by default has all keymaps, so all that is necessary is updating the
kernel commandline, which controls the keymap in the initrd I think, or at
least it should ...
With the upcoming BLS support for F30, the kernel options are coming from the
grubenv, so updating them is much easier (does not require regenerating
grub.cfg). But I wonder if the kernel commandline approach works, since things
starting to work after the next kernel update suggests that somehow the keymap
does get coded inside the initrd ?
Either way I'm tempted to call this "not a bug" from the plymouth pov,
since
plymouth just uses / consumes the installed console keymap for keyboard input,
even when the display is graphical.
--
You are receiving this mail because:
You are on the CC list for the bug.