Fedora Account System
Red Hat Associate
Red Hat Customer
after asking on systemd-devel i got "This looks like dracut didn't package the file correctly into the initrd. Please file a bug against dracut" and so here we are all the other errors at the bottom are a direct result of this one and that config works for years on at least 35 fedora setups until i upgrade to F32 -------------------------------------- [root@rawhide ~]# systemctl status systemd-vconsole-setup.service ● systemd-vconsole-setup.service - Setup Virtual Console Loaded: loaded (/usr/lib/systemd/system/systemd-vconsole-setup.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2020-06-27 20:45:53 CEST; 51s ago Docs: man:systemd-vconsole-setup.service(8) man:vconsole.conf(5) Main PID: 209 (code=exited, status=1/FAILURE) CPU: 28ms Jun 27 20:45:54 rawhide.vmware.local systemd-vconsole-setup[214]: cannot open file de-latin1-nodeadkeys -------------------------------------- the file is obviously there and in fact is *used* for the VT because i have the correct keyboard layout and german umlauts and when i remove "KEYMAP=de-latin1-nodeadkeys" from "/etc/vconsole.conf" i end with a english keyboard and enter my password is virtually impossible [root@rawhide ~]# lsinitrd | grep de-latin1-nodeadkey -rw-r--r-- 1 root root 493 Feb 10 11:26 usr/lib/kbd/keymaps/legacy/i386/qwertz/de-latin1-nodeadkeys.map -------------------------------------- [root@rawhide ~]# cat /etc/vconsole.conf FONT=latarcyrheb-sun16 KEYMAP=de-latin1-nodeadkeys -------------------------------------- [root@rawhide ~]# cat /etc/default/grub GRUB_TIMEOUT=1 GRUB_DISTRIBUTOR="Fedora" GRUB_SAVEDEFAULT=false GRUB_TERMINAL_OUTPUT="console" GRUB_GFXPAYLOAD_LINUX="text" GRUB_CMDLINE_LINUX="nosmp edd=off audit=0 rd.plymouth=0 plymouth.enable=0 zswap.enabled=0 net.ifnames=0 biosdevname=0 nodmraid raid=noautodetect nomodeset selinux=0 noswapaccount nousb usbcore.nousb noisapnp noresume hibernate=no kaslr thermal.off=1 nmi_watchdog=0 pcie_aspm=off consoleblank=0 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 vconsole.font=latarcyrheb-sun16 vconsole.keymap=de-latin1-nodeadkeys locale.LANG=C.UTF-8" GRUB_DISABLE_RECOVERY=true GRUB_DISABLE_SUBMENU=true GRUB_DISABLE_OS_PROBER=true GRUB_ENABLE_BLSCFG=true -------------------------------------- [root@rawhide ~]# system-errors.sh [Sat Jun 27 20:45:52 2020] systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE [Sat Jun 27 20:45:52 2020] systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'. [Sat Jun 27 20:45:52 2020] systemd[1]: Failed to start Setup Virtual Console. [Sat Jun 27 20:45:52 2020] systemd[1]: Dependency failed for dracut ask for additional cmdline parameters. [Sat Jun 27 20:45:52 2020] systemd[1]: dracut-cmdline-ask.service: Job dracut-cmdline-ask.service/start failed with result 'dependency'. Jun 27 20:45:54 rawhide systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE Jun 27 20:45:54 rawhide systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'. Jun 27 20:45:54 rawhide systemd[1]: Failed to start Setup Virtual Console. Jun 27 20:45:54 rawhide systemd[1]: Dependency failed for dracut ask for additional cmdline parameters. Jun 27 20:45:54 rawhide systemd[1]: dracut-cmdline-ask.service: Job dracut-cmdline-ask.service/start failed with result 'dependency'. Jun 27 20:45:54 rawhide systemd-vconsole-setup[209]: /usr/bin/loadkeys failed with exit status 1. Jun 27 20:45:54 rawhide systemd-vconsole-setup[269]: /usr/bin/loadkeys failed with exit status 1. Jun 27 20:45:54 rawhide systemd-udevd[261]: vtcon0: Process '/usr/lib/systemd/systemd-vconsole-setup' failed with exit code 1. --------------------------------------
ping - this is a showstopper for upgrade to F32
[root@rawhide ~]# rpm -qa | grep kbd kbd-misc-2.2.0-1.fc32.noarch kbd-legacy-2.2.0-1.fc32.noarch kbd-2.2.0-1.fc32.x86_64
switvhing from "de-latin1-nodeadkeys" to "de-nodeadkeys" seems to workaround that issue, still annoying after that many years and given that the file exists and was visible in lsinitrd
jesus christ may you guys make sure one and for all what is the right property for a german keyboard? for a decade "de-latin1-nodeadkeys", with F32 you need to change to "de-nodeadkeys" and now with F33 this is missing completly in the initrd and after switch back to "de-latin1-nodeadkeys" as befoore Fedora 32 it's working again -------------------------------------------- Fedora 31: de-latin1-nodeadkeys Fedora 32: de-nodeadkeys Fedora 33: de-latin1-nodeadkeys -------------------------------------------- [root@rawhide ~]# systemctl status systemd-vconsole-setup.service ● systemd-vconsole-setup.service - Setup Virtual Console Loaded: loaded (/usr/lib/systemd/system/systemd-vconsole-setup.service; static) Active: failed (Result: exit-code) since Tue 2020-08-25 22:47:48 CEST; 20s ago Docs: man:systemd-vconsole-setup.service(8) man:vconsole.conf(5) Main PID: 210 (code=exited, status=1/FAILURE) CPU: 26ms Aug 25 22:47:49 rawhide.vmware.local systemd-vconsole-setup[216]: loadkeys: Unable to open file: de-nodeadkeys: No such file or directory --------------------------------------------
Hmm, I'm not sure why this wouldn't work. If I have the appropriate package installed, it seems to work fine. And the contents of the packages don't seem to have changed: $ for i in kbd-legacy*.rpm;do echo $i; rpm -qpl $i |grep de-latin1-no;done kbd-legacy-2.0.4-14.fc31.noarch.rpm /lib/kbd/keymaps/legacy/i386/qwertz/de-latin1-nodeadkeys.map.gz /lib/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz kbd-legacy-2.2.0-1.fc32.noarch.rpm /lib/kbd/keymaps/legacy/i386/qwertz/de-latin1-nodeadkeys.map.gz /lib/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz kbd-legacy-2.2.0-3.fc33.noarch.rpm /usr/lib/kbd/keymaps/legacy/i386/qwertz/de-latin1-nodeadkeys.map.gz /usr/lib/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz kbd-legacy-2.3.0-4.fc34.noarch.rpm /usr/lib/kbd/keymaps/legacy/i386/qwertz/de-latin1-nodeadkeys.map.gz /usr/lib/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz kbd-legacy-2.4.0-2.fc34.noarch.rpm /usr/lib/kbd/keymaps/legacy/i386/qwertz/de-latin1-nodeadkeys.map.gz /usr/lib/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz $ for i in kbd-misc*.rpm;do echo $i; rpm -qpl $i |grep de-nodead;done kbd-misc-2.0.4-14.fc31.noarch.rpm /lib/kbd/keymaps/xkb/de-nodeadkeys.map.gz kbd-misc-2.2.0-1.fc32.noarch.rpm /lib/kbd/keymaps/xkb/de-nodeadkeys.map.gz kbd-misc-2.2.0-3.fc33.noarch.rpm /usr/lib/kbd/keymaps/xkb/de-nodeadkeys.map.gz kbd-misc-2.3.0-4.fc34.noarch.rpm /usr/lib/kbd/keymaps/xkb/de-nodeadkeys.map.gz kbd-misc-2.4.0-2.fc34.noarch.rpm /usr/lib/kbd/keymaps/xkb/de-nodeadkeys.map.gz I'll reassign it to kbd for get more feedback. But I don't see anything relevant to make this issue appear and then disappear.
in the meantime Fedora 33 seems to be happy again with "KEYMAP=de-nodeadkeys", i forgot about this issue and updated some machines last week to F33
This could be related to [1] and [2]. kbd-legacy (de-latin1-nodeadkeys) is no more installed as a dependency of kbd. Usage of xkb converted keymap from kbd-misc (de-nodeadkeys) is preffered ([1]). But some languages need kbd-legacy installed anyway, that's done by Anaconda now ([2]). I think Adam has more detailed knowledge of this, adding him to CC. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1891811 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1919483
Well, I think several different things must have happened here. The oddest thing is that apparently de-nodeadkeys disappeared for Harald during F33 at some point, I'm not sure why that would've happened unless he hit a transient bug where we were wiping the wrong layouts from the package during pre-release phase (this was never in stable IIRC). I would expect that layout should always be present. Since kbd-legacy was set to not be installed by default except for switched languages in F34 it's expected that a fresh German install won't have de-latin1-nodeadkeys, I guess. On *upgrade* it should still be there if it was there before, as kbd-legacy should be included in the upgrade.
It seems that there's a bunch of history here that we won't figure out. I'll close this as dup of #1933873, which seems to have the same cause. *** This bug has been marked as a duplicate of bug 1933873 ***