Univention Bugzilla – Bug 57077
UCS 5.2 alpha doesn't use german keyboard layout on console during setup and after
Last modified: 2024-02-23 15:00:33 CET
I configured a UCS 5.2 alpha with german locale (location: Bremen), but still a US keyboard was used in Univention system setup. After successful installation, tUCR shows: root@primary80:~# ucr search --brief locale locale/default: de_DE.UTF-8:UTF-8 locale: de_DE.UTF-8:UTF-8 en_US.UTF-8:UTF-8 And locale is german when I'm connected via SSH, but on the console it's still US (No german special characters and y <-> z), even after reboot.
keyboard layout != [locale](https://en.wikipedia.org/wiki/Locale_(computer_software)) the 1st is a property of the HW you are sitting in front of, the later is a per process property of the software you are using somewhere on the world. 1st is patches/console-setup/ucs_5.2-0/1.221/0001-Bug-35496-d-i-Save-keyboard-setting.patch 2nd is patches/localechooser/ucs_5.2-0/2.103/0002-Bug-35492-Limit-languages-to-de-en.patch but they are only relevant while D-I is running; if you use the KVM image this is probably: umc/python/setup/__init__.py: 163 # Don't set in debian installer mode 164 if ucr.is_true('system/setup/boot/installer'): 165 return True Please specify how you installed 5.2, e.g. from ISO or using our internal KVM images.
ucs-kt-get image 5.2-0+2024-02-20 as used in our jenkins tests.
Even stranger: 1. Primary on console: * y & z swapped * / only reachable via shift-6 * no äöü * but Ö reachable via shift-. and Ä via shift-# and shift-2 * could not find / and - root@primary80:~# ucr search --brief keyboard xorg/keyboard/options/XkbLayout: de xorg/keyboard/options/XkbModel: pc105 xorg/keyboard/options/XkbOptions: xorg/keyboard/options/XkbVariant: 2. Backup on console: * y & z Ok, as on german keyboard * but no äöü * shift-2 generates " as expected * could not find / and - root@backup81:~# ucr search --brief keyboard xorg/keyboard/options/XkbLayout: de xorg/keyboard/options/XkbModel: pc105 xorg/keyboard/options/XkbOptions: xorg/keyboard/options/XkbVariant: In both cases ssh terminals are not affected, german keyboard works there. dpkg-reconfigure console-setup and setupcon didn't help.
(In reply to Arvid Requate from comment #2) > ucs-kt-get image 5.2-0+2024-02-20 as used in our jenkins tests. $ tar xfO /mnt/omar/vmwares/kvm/single/Others/5.2-0+2024-02-20_generic-unsafe_amd64.tar.gz 5.2-0+2024-02-20_generic-unsafe_amd64.xml | grep -o 'keymap="[^"]*"' keymap="en-us" But your notebook probably does not have/use the US layout, but DE. Either (temporarily) switch your local layout or re-configure the VM; and use a VNC viewer supporting [QEMU Extended Key Events](https://vncdotool.readthedocs.io/en/0.8.0/rfbproto.html#qemu-extended-key-event-message)! Read https://github.com/sibson/vncdotool/issues/269#issuecomment-1696847993 (In reply to Arvid Requate from comment #3) > In both cases ssh terminals are not affected, German keyboard works there. Again: ssh works on the TTY layer which is *not* affected by any keyboard configuration on of the remote host! Arvid → Kbd[KeyCode] → KB-Cfg¹[KeySym] → ssh[Char] → sshd → console[Char] Arvid → Kbd[KeyCode] → KB-Cfg¹[KeySym] → VNC-Cli → RFB[KeySym] → VNC-Srv@qemu² → keymap-rev-map[KeyCode] → USB-Kbd[KeyCode] → KB-Cfg@VM³[KeySym] → console[Char] Arvid → Kbd[KeyCode] → KB-Cfg¹[KeySym] → VNC-Cli+ → RFB+[KeySym+KeyCode] → VNC-Srv@qemu → USB-Kbd[KeyCode] → KB-Cfg@VM³[KeySym] → console[Char]
PS: UCS switched its main language from German to [US-]English a long time (UCS-3.x?) Our KVM images were the last provisioned with German; this was changed some time ago as we nowadays have several colleges, which do not speak German at all.
Ok, but those templates exist to let the user run system setup. I ran system setup, selected all things german and the result is a system that is not german on the console. So we have an issue in UCS.
(In reply to Arvid Requate from comment #6) > So we have an issue in UCS. No: plain VNC is known broken, use at least a VNC client supporting "Qemu Extended Key Events"! UVMM/NoVNC is known broken, use any GTK-VNC-based viewer, e.g. `gvncviewer` or `virt-viewer` (This is like connecting a "French keyboard" to your notebook and complaining that Linux does not automatically switch the keyboard layout to the correct format.)
No, it's like connecting a french keyboard *and* then telling UCS via system setup that I want to use french keyboard. And then getting something else instead on the console. Assume I'm a customer calling support for that.
(In reply to Arvid Requate from comment #8) > No, it's like connecting a french keyboard > *and* then telling UCS via system setup that > I want to use french keyboard. > > And then getting something else instead on the console. Again no: If your local keyboard setting does not match the Qemu setting, it is like connecting a *known broken keyboard* and complaining, that some keys behave strange. It is a (virtual HW) problem of VNC and Qemu, *not* UCS.
Ok, I accept your analysis, great. Now can you tell me why I don't have that issue with UCS 5.0-6?