Hi folks, well, I have a weird issue here: Over the weekend, I switched to the new 17.0 profiles, and as part of that process, did an "emerge -e @world" on my ~x86/systemd machine. Took a while, but that was expected, and I was glad to see that afterwards everything was still working fine ... except for one thing:
Strangely, on the newly emerged system, after each boot, I noticed that my desired keymap is no longer set on the virtual consoles. I get an English keymap now, although I have set a German one, as per /etc/vconsole.conf: # cat /etc/vconsole.conf KEYMAP=de-latin1-nodeadkeys FONT=eurlatgr.psfu.gz Now, the settings in this file have not been changed. In fact, no configuration changes have been done along with the world re-emerge. Actually, I can find a trace of something being wrong in the journal: Dec 05 08:44:25 boerne systemd-vconsole-setup[1944]: /usr/bin/setfont failed with error code 65. [...] Dec 05 08:44:26 boerne systemd-vconsole-setup[1944]: Setting source virtual console failed, ignoring remaining ones Dec 05 08:44:26 boerne systemd-udevd[1912]: Process '/lib/systemd/systemd-vconsole-setup' failed with exit code 1. So, /usr/bin/setfont seems to fail. Strange that it obviously didn't do that before the world re-emerge, but it's certainly doing it now. Even more strange, however, is that after login, I can operate setfont manually and it will succeed. In fact, after login I can execute /lib/systemd/systemd-vconsole-setup manually, or do "systemctl start systemd-vconsole-setup.service", and either will complete without error and actually set my keymap and font as desired. My wild guess is that during boot, systemd-vconsole-setup might get called too early by systemd-udevd, when the desired font file is not yet available (probably because still running in initramfs context) or when the virtual console, for whatever reason, is not yet ready. But like I've said, that's just a wild guess, I couldn't really find any proof for that in the journal. Looking at the original systemd-vconsole-setup.service file, things look sane in there, I guess: [Unit] Description=Setup Virtual Console Documentation=man:systemd-vconsole-setup.service(8) man:vconsole.conf(5) DefaultDependencies=no Before=initrd-switch-root.target shutdown.target ConditionPathExists=/dev/tty0 [Service] Type=oneshot ExecStart=/lib/systemd/systemd-vconsole-setup However, as a little test / possible workaround, I decided to create my own systemd unit file that does nothing more but execute /lib/systemd/systemd-vconsole-setup, only at a (hopefully) later stage during the boot process: # cat /etc/systemd/system/vconsole-fix.service [Unit] Description=Fix Virtual Console Before=-.mount ConditionPathExists=/dev/tty0 [Service] Type=oneshot ExecStart=/lib/systemd/systemd-vconsole-setup [Install] WantedBy=multi-user.target And after enabling this unit, things actually work just fine: My keymap is, once again, set up properly on the virtual console right after boot and before I log in or perform any manual steps. Sadly, I'm kind of confused now. I'm really wondering if anyone's ever seen something like that before or otherwise has an explanation for it. I mean, it used to work before, and neither configuration nor package versions have been changed. It's just that everything has been re-build (as PIEs), but I can hardly imagine that this is responsible for the issue. Right now, I'm waiting for a second machine to complete the re-emerge process (might take another while) and am then really curious to see if it suddenly suffers from the same oddity. Other than that, the only idea that I currently have is to keep the workaround deployed and have a look if the issue disappears again by itself just as suddenly as it started, probably with a forthcoming version of systemd or something. Of course, understanding things is always preferrable than just hoping for them to fix themselves, so if someone has a clue, I'd be more than glad to hear about it! :-) Greetings Nils
