LUKS unlock screen always uses en-US keyboard layout

[rugk]

Workaround:

Option 1

Add vconsole.keymap=fr (with your language code instead of fr) to the kernel command line using rpm-ostree kargs --editor.

Option 2

Run:

rpm-ostree initramfs-etc --track=/etc/vconsole.conf

and reboot.

For the second option, you do not have to manually specify the keymap to use but this will make updates apply slightly slower.

---

Original issue text

Despite of what anaconda says in it's installer, actually the LUKS unlock screen seems to ignore my keyboard layout selected at installation time at all (in contrast to Fedora Workstation) and just use some default en_US (I guess).

This is a serious issue, as it affects the first-time user experience of many Silverblue users and may actually lock users out and leave a very bad experience when they try Silverblue for the first time.
Also, obviously, AFAIK once you've installed your system like that, it's hard to change afterwards.

[aruiz]

I actually saw this happening on a RHEL8 install.

[rugk]

Well, then report it there? It's another project, after all?

[cgwalters]

xref https://discussion.fedoraproject.org/t/bug-dm-crypt-password-saved-in-qwerty/1204 in particular this.

[cgwalters]

In general with server-side initramfs by default (as rpm-ostree does) all client-side changes need to either be reflected instead in the kernel commandline - or my ideal here would be to generate an "overlay" initramfs. This came up in another thread; I think most bootloaders support multiple.
(Alternatively, rpm-ostree could learn how to concatenate such an overlay into one initramfs, avoiding the full rpm-ostree initramfs --enable slowness)

The thread claims even rpm-ostree initramfs --enable isn't picking up the vconsole.conf modifications, which seems like a bug in rpm-ostree (or dracut).

[jwrdegoede]

Since silverblue is using a server-side generated, generic initrd, there is no /etc/vconsole.conf in the initrd (as that is only included in a host-only initrd). As mentioned one solution would be to set the keymap on the kernel commandline using vconsole.keymap=..., see man vconsole.conf

[cgwalters]

And to elaborate on the above, to change the kernel command line you should use rpm-ostree kargs.

[jwrdegoede]

I've been thinking about this some more. Also because of: https://bugzilla.redhat.com/show_bug.cgi?id=1405539, which is part of: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues

I believe that specifying the keymap on the kernel commandline is probably the right thing to do for both regular fedora and silverblue. But if we do this I wonder if runtime keymap changes will still work (rather then only work after reboot) as systemd-vconsole-setup gives higher prio to the kernel commandline then the configfile.

I've started a discussion about this on the systemd-devel mailinglist:
https://lists.freedesktop.org/archives/systemd-devel/2019-July/043176.html

[jwrdegoede]

So the initial discussion (from Jul 30) on the systemd list ended with the conclusion that passing "rd.vconsole.keymap=foo" on the kernel-commandline should work.

Now the question is how do we get that on the kernel commandline when changing the layout. I've started a new discussion about having systemd-localed somehow update the commandline for this on the sytemd-devel mailinglist:
https://lists.freedesktop.org/archives/systemd-devel/2019-September/043465.html

One option which is being suggested there is to not use the kernel cmdline but instead use an extra initrd with just /etc/vconsole.conf in there, which overwrites the /etc/vconsole.conf in the main initrd.

For silverblue this would require some place to write this initrd too; in theory this can be a single initrd shared between all the kernels and we could provide an empty one in the initial install.

The kernel-cmdline plan would mean either updating the grubenv, which we already do for boot fail detection; or doing a read/write/modify of all the /boot/loader/entries/*.conf BLS files to append or update the option there.

From a regular Fedora pov, all of the above would work. @cgwalters you wrote above that from a silverblue pov you would prefer an overlay initramfs for this? Is that still the case?

[cgwalters]

or doing a read/write/modify of all the /boot/loader/entries/*.conf BLS files to append or update the option there.

I don't think we want to change all entries; just the new one. As a general rule, rpm-ostree prefers to keep your "deployment" immutable, and create new deployments for changes. This ensures you always have a rollback to your previous working state.

Also particularly for rpm-ostree, remember that each deployment has its own /etc, and hence you can also revert from the bootloader to previous /etc changes as well.

(All of this is a great illustration of how fundamental of a change ostree is to the operating system, and requires careful thinking about how things that operate on top work to achieve its goals)

@cgwalters you wrote above that from a silverblue pov you would prefer an overlay initramfs for this?

Yeah that's probably the simplest model. It would meld nicely actually with the general philosophy of rpm-ostree that we prefer layering over overrides. Something like rpm-ostree initramfs --enable-layered or something, and in that model we just scrape any config files from /etc and don't even run dracut?

[patrakov]

Won't layering completely defeat the purpose of signatures in the secure boot scenario?

[jwrdegoede]

Won't layering completely defeat the purpose of signatures in the secure boot scenario?

Yes and no, we need to figure out how to sign "local data" anyways since we really should also be signing the kernel commandline too...

[jwrdegoede]

Ok, so there seems to be consensus that the best way to handle this is using an overlay initramfs. So my plan for regular Fedora for this is as follows:

1. Have a /boot/initramfs-config.img which for now will just contain /etc/vconsole.conf (chances are this will get more files added over time)
2. Modify mkbls from /usr/lib/kernel/install.d/20-grub.install to add an initrd line for this image to the generated bls .conf file if the image is present
3. Add a new update-config-initramfs command to the install-kernel script, which generates /boot/initramfs-config.img
4. Make systemd-localed call update-config-initramfs on locale (and keymap) setting changes

Would this also work for silverblue (with perhaps some work on the SB side) ?

[cgwalters]

All changes to the kernel and initramfs must go through rpm-ostree.

[cgwalters]

The main ugly thing I think in this is that what we really want to do is have a mechanism that lets us know precisely when we need to create an overlay. I suppose to start we could go with just a list of files in /etc that are relevant maintained in...dracut?

Then it'd be pretty easy to add rpm-ostree initramfs --cond-enable-overlay as well as auto-detect this situation at upgrade time, and do 1-3. Then the implementation of 4) would just be a DBus call too.

One pattern I've been thinking about supporting is where we try to define interfaces that work on yum-based as well as rpm-ostree based systems. For rpm-ostree we can wrap/replace.

[jwrdegoede]

The idea for regular Fedora at least would be that the tooling making changes to files under /etc which need to be part of the config overlay initrd would trigger the re-generation from the tooling.

E.g. systemd-localed would call some external helper to regenerate the initrd when the keymap gets changed through localectl (or other users of the localed DBUS API).

Note that we are currently still discussing the localed integration on the systemd-devel list and how we are going to do this is not entirely clear yet. It seems that Lennart does not like the config overlay initrd idea.

It would be useful if you can subscribe to systemd-devel and follow the discussion there directly; and comment if it is heading in a direction which is troublesome for rpm-ostree:
https://lists.freedesktop.org/archives/systemd-devel/2019-September/043465.html

[cgwalters]

Per the thread...I think what we really want to encourage for LUKS is binding to the TPM, so there's no prompt. But anyways, since the solutions in that thread require new bootloader support, we can't rely on it anytime soon.

(Further, requiring bootloader changes runs straight into ostreedev/ostree#1873 )

So in coreos/rpm-ostree#1930 we're going to add rpm-ostree support for overlay initramfs.

[cgwalters]

Closing this in favor of coreos/rpm-ostree#1930 since it isn't just a Silverblue issue - it affects all rpm-ostree using systems, including Fedora CoreOS, Fedora IoT etc.

[cgwalters]

Hm, I would close if I had permissions, which I apparently don't.

[rugk]

ok okay, do it for you 😄

[cgwalters]

See coreos/rpm-ostree#2170

[piotrcki]

Hello,

I still have this issue today. After the initial install process, the prompt is set up to QWERTY despite another keyboard layout choice during the installation.

Although it can be solved through rpm-ostree initramfs --enable, this is still a big issue because.

1. The first unlock is still a pain.
2. It is not obvious that unlock fails because of the keyboard layout.
3. Not everyone knows what an initramfs is, and this knowledge should not be expected from users.

Because of 1. and 3., coreos/rpm-ostree#2170 doesn't seem to be the right fix (even if it's good to have it) and I suggest to re-open this ticket.

[travier]

Maybe this could be redirected to Anaconda where the setup could happen during the installation process.

[cgwalters]

Yeah, this needs to be an Anaconda bug now.

[miabbott]

This issue should be displayed on https://fedoraproject.org/silverblue/download/ , this would have saved me some time !

Or at least mention it in https://docs.fedoraproject.org/en-US/fedora-silverblue/installation/#known-limitations

Care to submit a PR with your suggestion?

https://github.com/fedora-silverblue/silverblue-docs

[hadess]

I ran into this today, and the problem seems to be compounded by the fact that the target that systemd relies on to read the password will only run a few times before going into a failure state and never asking for a password again. This is visible in the debug output, but the spinner in graphical mode just spins forever.

[travier]

I know it does not fixes the issue but we now have the following to help with it:

• https://discussion.fedoraproject.org/t/keyboard-layout-is-always-english-when-unlocking-encrypted-drives-on-silverblue-kinoite-sericea/81095
• https://docs.fedoraproject.org/en-US/fedora-silverblue/installation/#known-limitations

[travier]

Another (maybe easier) option is to add arguments to the kernel command line to set the keymap. For example from https://www.freedesktop.org/software/systemd/man/latest/vconsole.conf.html:

... vconsole.keymap=fr

[jbethune]

Since silverblue is using a server-side generated, generic initrd, there is no /etc/vconsole.conf in the initrd (as that is only included in a host-only initrd). As mentioned one solution would be to set the keymap on the kernel commandline using vconsole.keymap=..., see man vconsole.conf

Just an idea: Would it be possible to store the keyboard layout choice in a file that lies on the unencrypted /boot partition? I assume that the data from /boot is not stored in the immutable distro image.

[travier]

This is tracked in https://gitlab.com/fedora/ostree/sig/-/issues/6

[travier]

rhinstaller/anaconda#5952 should land in Fedora 42.

[yodatak]

Any way to backport this for silverblue only installation ? Its realy a long anonying issue and prevent so many people to use silverblue based distro when non US

[travier]

Unfortunately that is going to be difficult. F41 is close to being released and this would have to land in Anaconda there.

[travier]

Fedora 41 is GO. This will be for Fedora 42. Please help us test that in Rawhide.

[jkonecny12]

You can only build your own ISO. Sorry for providing the fix so late.

[travier]

Thanks for making the fix in the first place!

[travier]

This is now tracked in https://gitlab.com/fedora/ostree/sig/-/issues/6 and expected to land in Fedora 42. Please help us test that in Rawhide. Closing this one.