That may be… but… I’d not used “yast2 keyboard”, this occurred immediately after a zypper dup on two TW machines. Also, the timestamp on “vconsole.conf” wasn’t recent, so that configuration file hadn’t been altered by anything during the zypper dup, nor was there a vconsole.conf.rpmnew file… The jury’s out, I’ll wait on the outcome of the bug report.
Becoming more confusing … I’ve just looked at a Leap 15.1 system, that has “KEYMAP=gb” and no “uk.map.gz” … so perhaps “something” did alter “/etc/vconsole.conf” (without changing the timestamp ??) :?
Anyone with a pre 20200309 TW and using the “en_GB.UTF-8” locale able to provide the following would be appreciated
localectl
cat /etc/vconsole.conf
ls /usr/share/kbd/keymaps/xkb/uk.map.gz
Perhaps legacy folders were turned off? /usr/share/kbd/keymaps/legacy/i386/qwerty/uk.map.gz
Looking at the change log for “kbd” there is this: “kbd-1.15.5-loadkeys-search-path.patch.” That patch kbd/kbd-1.15.5-loadkeys-search-path.patch at master · OpenMandrivaAssociation/kbd · GitHub (oddly from Jan 2017) sets the search path to include “keymaps/legacy”
What I really need to know, and from my own TW machines can’t find out, is what “KEYMAP=” was set to prior to the 20200309 dup…
Maybe I should just accept it works with “KEYMAP=gb” … Although I’m very intrigued now as to the actual cause of the problem…
I do not have a running TW at hand , but my test machine, currently running as a Leap-15.2 production server, has a TW partition that I can mount.
sysman@kirsten:~> cat /mnt/etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20200201"
...
sysman@kirsten:~>
sysman@kirsten:~> cat /mnt/etc/vconsole.conf
KEYMAP=uk
FONT=eurlatgr.psfu
FONT_MAP=
FONT_UNIMAP=
sysman@kirsten:~>
sysman@kirsten:~> lh /mnt/usr/share/kbd/keymaps/
total 0
drwxr-xr-x 1 root root 18 Jan 21 00:29 .
drwxr-xr-x 1 root root 88 Jan 21 00:29 ..
drwxr-xr-x 1 root root 60 Jan 24 09:48 legacy
drwxr-xr-x 1 root root 12K Jan 24 09:49 xkb
sysman@kirsten:~> find /mnt/usr/share/kbd/keymaps/ -iname "uk*"
/mnt/usr/share/kbd/keymaps/legacy/i386/qwerty/uk.map.gz
sysman@kirsten:~> find /usr/share/kbd/keymaps/ -iname "uk*" #this is Leap-15.2 20200309
/usr/share/kbd/keymaps/legacy/i386/qwerty/uk.map.gz
sysman@kirsten:~>
sysman@kirsten:~> gunzip /usr/share/kbd/keymaps/legacy/i386/qwerty/uk.map.gz
sysman@kirsten:~> head /usr/share/kbd/keymaps/legacy/i386/qwerty/uk.map
# uk.map
# From bam@wcl-l.bham.ac.uk Fri May 2 20:20:59 1997
# reduced number of keymaps, adapted to alt_is_meta - aeb
#
# old: shift keycode 41 = asciitilde
# bam: shift keycode 41 = notsign
#
keymaps 0-2,4-6,8,9,12
alt_is_meta
include "qwerty-layout"
sysman@kirsten:~>
As far as I can tel withl Leap-15.1 using YaST to set the Keyboard layout to “English (UK)” writes “KEYMAP=gb” into /etc/vconsole.conf. The same action in Leap15.2 Beta writes vKEYMAP=uk**, which is long deprecated.
A “uk” keymap should really be for Ukranian keyboards if it follows the languge codes, or maybe the prefer their country code of “ua”.
Whatever this is definately a bug in the current 15.2 and TW.
**
OK, thanks for taking the time to do that.
This is more confusing as it goes on…
So, your “20200201” TW did have “KEYMAP=uk” and “/usr/share/kbd/keymaps/legacy/i386/qwerty/uk.map.gz” was present. I’ll assume that mine (prior to 20200309) had likewise. That would explain why the datestamp on “vconsole.conf” was unchanged, I assume the file wasn’t altered by the 20200309 dup, and the problem of “Failed to start Setup Virtual Console” wasn’t occurring then (pre 20200309), so the search path must have included “legacy”… (I confess I’d not searched for “uk.map.gz”, rather foolishly assuming as it wasn’t at “/usr/share/kbd/keymaps/xkb/” then it was absent.)
I’ll let this one go now, before my brain starts to hurt. Hopefully the answer will come from the bug report. I was going to add another comment indicating it also affected Leap 15.2, but I see you’ve already done that.
I have the same problem with Pl02 keymap (legacy)
Well changing font in /etc/vconsole.conf from PL02 to pl and mkinitrd solved the issue but yast shows that I’m using English keyboard now. Changing in yast to Poland result in PL02 again /etc/vconsole.conf so the problem still exist
I think kbd-2.2.0 is broken (either as in “does things that can trip you up” or as in “actually broken”), because I have dm-crypted my swap partition and it asks me for the password on boot. With kbd-2.2.0, it complains that it “could not open de-latin1” (or de, or whatever you configure) and defaults to US keyboard mapping, making entering the password correctly difficult.
I forcefully downgraded to kbd-2.0.4 again (downloaded the Leap-15.1 rpms (EDIT: Leap-15.2 rpms, apparently), rpm --force -iUvh …) and locked the packages. Everything works again.
Should I file a bug report?
This is the only way to have bugs fixed. Someone needs to report bug.
+1 …
Used “yast2 keyboard”, duped and got the following:
erlangen:~ # journalctl --grep vconsole
-- Logs begin at Sun 2020-03-29 16:41:11 CEST, end at Thu 2020-04-02 09:56:54 CEST. --
-- Reboot --
Mar 30 19:12:19 erlangen systemd[1]: systemd-vconsole-setup.service: Succeeded.
Mar 30 19:12:35 erlangen display-manager[1774]: /etc/vconsole.conf available
Apr 01 10:23:27 erlangen systemd[1]: systemd-vconsole-setup.service: Succeeded.
-- Reboot --
-- Reboot --
Apr 02 08:13:46 erlangen systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE
Apr 02 08:13:46 erlangen systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'.
Apr 02 08:13:46 erlangen systemd-udevd[362]: vtcon0: Process '/usr/lib/systemd/systemd-vconsole-setup' failed with exit code 1.
Apr 02 08:13:46 erlangen systemd-udevd[351]: vtcon1: Process '/usr/lib/systemd/systemd-vconsole-setup' failed with exit code 1.
Apr 02 08:14:03 erlangen display-manager[4703]: /etc/vconsole.conf available
erlangen:~ # cat /etc/vconsole.conf
KEYMAP=de-latin1-nodeadkeys
FONT=eurlatgr.psfu
FONT_MAP=
FONT_UNIMAP=
erlangen:~ #
Beware of the villain! 