Keyboard layout does not persist in installer

[ohreally]

Qubes OS version:

R4.0-rc3

Affected TemplateVMs:

N/A

---

Steps to reproduce the behavior:

Start the installer. Set the keyboard layout to French. Do or do not delete the original (US) layout; this does not make a difference.

Expected behavior:

Keyboard layout is and stays French.

Actual behavior:

When creating a user account (in the installer), the keyboard layout changes back to the original (US) layout, with no way of correcting this. This results in the password being set using the US layout. However, after reboot, on login, the keyboard layout is back to FR, which makes it extremely difficult to guess one's own password.

[kototama]

It is a duplicated of #3234

[kototama]

It is a duplicated of #3234

[ohreally]

This issue may be related to #3234, but it is certainly not a duplicate.

This issue is about the keyboard layout switching back to US when a user is created in the installer, which means the user password is set with the wrong keyboard layout, while #3234 speaks about the password for disk encryption being set with the wrong keyboard layout.

I did not have a problem with the disk encryption password (if I had, I would never have discovered that I had a problem with the user password).

[ohreally]

This issue may be related to #3234, but it is certainly not a duplicate.

This issue is about the keyboard layout switching back to US when a user is created in the installer, which means the user password is set with the wrong keyboard layout, while #3234 speaks about the password for disk encryption being set with the wrong keyboard layout.

I did not have a problem with the disk encryption password (if I had, I would never have discovered that I had a problem with the user password).

[kototama]

I see your point. I misread your issue.

[kototama]

I see your point. I misread your issue.

[marmarek]

@ohreally so, for disk passphrase prompt (both in installer, and later on system start), the layout is correctly set to FR? Or it is just the same and you don't really know which one?

[marmarek]

@ohreally so, for disk passphrase prompt (both in installer, and later on system start), the layout is correctly set to FR? Or it is just the same and you don't really know which one?

[ohreally]

I'm not entirely sure which one.
But...

1. After installation, I could decrypt my disk, but I could not login (I have 'special' characters in both passphrases).
2. I have replaced my keyboard since, with a US international one, and this forced me to reinstall, because I could no longer decrypt my disk.

So I'd say my disk encryption password was (correctly) set using the French layout, while my user password was (incorrectly) set using the US layout.

[ohreally]

I'm not entirely sure which one.
But...

1. After installation, I could decrypt my disk, but I could not login (I have 'special' characters in both passphrases).
2. I have replaced my keyboard since, with a US international one, and this forced me to reinstall, because I could no longer decrypt my disk.

So I'd say my disk encryption password was (correctly) set using the French layout, while my user password was (incorrectly) set using the US layout.

[marmarek]

I can confirm this, and have a test case here: https://openqa.qubes-os.org/tests/529
There is also video available. Keyboard layout is changed between ntfsprogs (738/1016) and libreport (741/1016) packages.

[marmarek]

I can confirm this, and have a test case here: https://openqa.qubes-os.org/tests/529
There is also video available. Keyboard layout is changed between ntfsprogs (738/1016) and libreport (741/1016) packages.

[marmarek]

Copying @Aekez comment #4013 (comment):

Regarding language randomly switching, I think I might have found three clues (at least I can cause it to reproduce the switch back to us keyboard language roughly 50% of the time with one of them, the first clue below). Also all 3 clues seems related to each others, and seem to happen in some other Linux distros' as well.

• First clue seems that it is tied to xorg and keyboard being disconnected / connected. I found the Xorg log at /var/log/Xorg.0.log indeed includes the keyboard language changes as said in comment nr. 82 in the link below . See the comment nr. 82 here https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1246272. This comment also gave me the idea to check it on my own Qubes laptop. Sure enough, correcting the wrong resolution (xorg resolution bug) and changing it back to a proper resolution on my HDMI screen (connected with USB-C port), causes my laptops USB keyboard to change language. However the odd part is that the laptops keyboard stays the same, so there are effectively two keyboard languages at the same time, one for each keyboard. Running setxkbmap then gets both laptop and external USB keyboard back to the same language. Only tested in dom0. There is a second bug here, which causes the resolution to not fit in 1920x1080 pixels, where I need to change down to 1680x1050 resolution (not all temporary resolutions work), and then back to 1920x1080 again, in order to get the proper 1920x1080 resolutions. This is where I can cause the USB keyboard to change language, which happens when I fix the resolution bug caused by removing and re-inserting the USB-C dongle that holds both the USB keyboard and the HDMI TV screen. Interestingly, the USB keyboard only reverts back to US keyboard language once I correct the resolution bug, and not before that.
  • I don't get resolution bugs if I use HDMI directly in the HDMI port, rather than the USB-C port, however, I have not yet tested if it makes a difference. I'm not sure if the keyboard bug is tied to USB-C or the resolution bug itself, but it seems Xorg related at least?

• The second clue is that different language settings seems to cause conflicts when different apps are running. This is also speculated in the comment nr. 69 in the same link up above.This also seems tied to the third clue, or maybe even the first clue as well.

• The third clue seems to be that it goes bad after switching system languages for the first time post-system-install (causing mixed language settings). Generally I can relate to this too, but I haven't checked it enough times to see if its true. But I get the feeling that staying with whatever language that was picked during the Qubes installer, will keep working normal after installing. But the moment one changes language settings after the system has been installed, it seems like it causes the keyboard bugs. Maybe there are lingering keyboard language settings that causes a reset back to US?

This isn't anything concrete, but I hope it can be useful.

[marmarek]

Copying @Aekez comment #4013 (comment):

Regarding language randomly switching, I think I might have found three clues (at least I can cause it to reproduce the switch back to us keyboard language roughly 50% of the time with one of them, the first clue below). Also all 3 clues seems related to each others, and seem to happen in some other Linux distros' as well.

• First clue seems that it is tied to xorg and keyboard being disconnected / connected. I found the Xorg log at /var/log/Xorg.0.log indeed includes the keyboard language changes as said in comment nr. 82 in the link below . See the comment nr. 82 here https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1246272. This comment also gave me the idea to check it on my own Qubes laptop. Sure enough, correcting the wrong resolution (xorg resolution bug) and changing it back to a proper resolution on my HDMI screen (connected with USB-C port), causes my laptops USB keyboard to change language. However the odd part is that the laptops keyboard stays the same, so there are effectively two keyboard languages at the same time, one for each keyboard. Running setxkbmap then gets both laptop and external USB keyboard back to the same language. Only tested in dom0. There is a second bug here, which causes the resolution to not fit in 1920x1080 pixels, where I need to change down to 1680x1050 resolution (not all temporary resolutions work), and then back to 1920x1080 again, in order to get the proper 1920x1080 resolutions. This is where I can cause the USB keyboard to change language, which happens when I fix the resolution bug caused by removing and re-inserting the USB-C dongle that holds both the USB keyboard and the HDMI TV screen. Interestingly, the USB keyboard only reverts back to US keyboard language once I correct the resolution bug, and not before that.
  • I don't get resolution bugs if I use HDMI directly in the HDMI port, rather than the USB-C port, however, I have not yet tested if it makes a difference. I'm not sure if the keyboard bug is tied to USB-C or the resolution bug itself, but it seems Xorg related at least?

• The second clue is that different language settings seems to cause conflicts when different apps are running. This is also speculated in the comment nr. 69 in the same link up above.This also seems tied to the third clue, or maybe even the first clue as well.

• The third clue seems to be that it goes bad after switching system languages for the first time post-system-install (causing mixed language settings). Generally I can relate to this too, but I haven't checked it enough times to see if its true. But I get the feeling that staying with whatever language that was picked during the Qubes installer, will keep working normal after installing. But the moment one changes language settings after the system has been installed, it seems like it causes the keyboard bugs. Maybe there are lingering keyboard language settings that causes a reset back to US?

This isn't anything concrete, but I hope it can be useful.

[marmarek]

I can confirm that during installation (at least) udevadm trigger switches back to US even if Polish keyboard layout was selected (and US removed). DISPLAY=:1 setxkbmap pl switches to Polish keyboard layout, but again udevadm trigger revert it.
This is properly indicated in right top corner of the installation screen.

So, at least we can trigger the problem without going through full installation each time.

[marmarek]

I can confirm that during installation (at least) udevadm trigger switches back to US even if Polish keyboard layout was selected (and US removed). DISPLAY=:1 setxkbmap pl switches to Polish keyboard layout, but again udevadm trigger revert it.
This is properly indicated in right top corner of the installation screen.

So, at least we can trigger the problem without going through full installation each time.

[marmarek]

According to strace, the only thing that touches Xorg is udev, and it doesn't send anything about keyboard layout. So it isn't anything else processing udev events and re-configuring X server. It's X server itself.
For me it looks like when (re-)adding input devices, X server ignores current layout (for example visible in _XKB_RULES_NAMES property on the root window) and goes after fresh configuration. Since there is no layout specified on Xorg command line (-xkblayout option) nor config file (XkbLayout option), it fallback to hardcoded default - us.

BTW localectl tool creates /etc/X11/xorg.conf.d/00-keyboard.conf to mitigate this problem, but a) the file isn't present at that installation phase b) it is created in installed system only, not installer itself c) even if properly created also in installer, it looks like there is no way to reload Xorg configuration without restarting it.

[marmarek]

According to strace, the only thing that touches Xorg is udev, and it doesn't send anything about keyboard layout. So it isn't anything else processing udev events and re-configuring X server. It's X server itself.
For me it looks like when (re-)adding input devices, X server ignores current layout (for example visible in _XKB_RULES_NAMES property on the root window) and goes after fresh configuration. Since there is no layout specified on Xorg command line (-xkblayout option) nor config file (XkbLayout option), it fallback to hardcoded default - us.

BTW localectl tool creates /etc/X11/xorg.conf.d/00-keyboard.conf to mitigate this problem, but a) the file isn't present at that installation phase b) it is created in installed system only, not installer itself c) even if properly created also in installer, it looks like there is no way to reload Xorg configuration without restarting it.

[marmarek]

Looks similar to this Xorg bug: https://bugs.freedesktop.org/show_bug.cgi?id=71168

[marmarek]

Looks similar to this Xorg bug: https://bugs.freedesktop.org/show_bug.cgi?id=71168

[marmarek]

Further finding from analyzing Xorg source code:

1. New keyboard device gets its layout from xkb_layout option and fallback to the default layout if not set.
2. Default layout is only updated when adding new keyboard, based on that keyboard layout. Especially, changing keyboard layout at runtime (setxkbmap etc) does not change default layout, only layouts of individual keyboard devices. There is nothing else modifying XkbLayoutDflt variable, and there are very few calls to XkbSetRulesDflts, all looks related to adding new device or loading initial config file.

So, it looks like the only way to change default layout at runtime, is to add new keyboard with desired xkb_layout option set. How to do that? There is a third finding:

3. When adding new keyboard via udev event, its xkb_layout (and others) options are initialized based on udev properties.

And indeed, adding an udev rule that set xkblayout propery on a keyboard device, made the keyboard layout survive udevadm trigger! And now udevadm trigger switches to that layout, even if changed to a different one using setxkbmap or localectl.

[marmarek]

Further finding from analyzing Xorg source code:

1. New keyboard device gets its layout from xkb_layout option and fallback to the default layout if not set.
2. Default layout is only updated when adding new keyboard, based on that keyboard layout. Especially, changing keyboard layout at runtime (setxkbmap etc) does not change default layout, only layouts of individual keyboard devices. There is nothing else modifying XkbLayoutDflt variable, and there are very few calls to XkbSetRulesDflts, all looks related to adding new device or loading initial config file.

So, it looks like the only way to change default layout at runtime, is to add new keyboard with desired xkb_layout option set. How to do that? There is a third finding:

3. When adding new keyboard via udev event, its xkb_layout (and others) options are initialized based on udev properties.

And indeed, adding an udev rule that set xkblayout propery on a keyboard device, made the keyboard layout survive udevadm trigger! And now udevadm trigger switches to that layout, even if changed to a different one using setxkbmap or localectl.

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update