| 1 |
Hi folks, |
| 2 |
|
| 3 |
well, I have a weird issue here: Over the weekend, I switched to the |
| 4 |
new 17.0 profiles, and as part of that process, did an "emerge -e |
| 5 |
@world" on my ~x86/systemd machine. Took a while, but that was |
| 6 |
expected, and I was glad to see that afterwards everything was still |
| 7 |
working fine ... except for one thing: |
| 8 |
|
| 9 |
Strangely, on the newly emerged system, after each boot, I noticed |
| 10 |
that my desired keymap is no longer set on the virtual consoles. I get |
| 11 |
an English keymap now, although I have set a German one, as per |
| 12 |
/etc/vconsole.conf: |
| 13 |
|
| 14 |
# cat /etc/vconsole.conf |
| 15 |
KEYMAP=de-latin1-nodeadkeys |
| 16 |
FONT=eurlatgr.psfu.gz |
| 17 |
|
| 18 |
Now, the settings in this file have not been changed. In fact, no |
| 19 |
configuration changes have been done along with the world re-emerge. |
| 20 |
|
| 21 |
Actually, I can find a trace of something being wrong in the journal: |
| 22 |
|
| 23 |
Dec 05 08:44:25 boerne systemd-vconsole-setup[1944]: /usr/bin/setfont failed with error code 65. |
| 24 |
[...] |
| 25 |
Dec 05 08:44:26 boerne systemd-vconsole-setup[1944]: Setting source virtual console failed, ignoring remaining ones |
| 26 |
Dec 05 08:44:26 boerne systemd-udevd[1912]: Process '/lib/systemd/systemd-vconsole-setup' failed with exit code 1. |
| 27 |
|
| 28 |
So, /usr/bin/setfont seems to fail. Strange that it obviously didn't |
| 29 |
do that before the world re-emerge, but it's certainly doing it now. |
| 30 |
Even more strange, however, is that after login, I can operate setfont |
| 31 |
manually and it will succeed. |
| 32 |
|
| 33 |
In fact, after login I can execute /lib/systemd/systemd-vconsole-setup |
| 34 |
manually, or do "systemctl start systemd-vconsole-setup.service", and |
| 35 |
either will complete without error and actually set my keymap and font |
| 36 |
as desired. |
| 37 |
|
| 38 |
My wild guess is that during boot, systemd-vconsole-setup might get |
| 39 |
called too early by systemd-udevd, when the desired font file is not |
| 40 |
yet available (probably because still running in initramfs context) |
| 41 |
or when the virtual console, for whatever reason, is not yet ready. |
| 42 |
But like I've said, that's just a wild guess, I couldn't really find |
| 43 |
any proof for that in the journal. |
| 44 |
|
| 45 |
Looking at the original systemd-vconsole-setup.service file, things |
| 46 |
look sane in there, I guess: |
| 47 |
|
| 48 |
[Unit] |
| 49 |
Description=Setup Virtual Console |
| 50 |
Documentation=man:systemd-vconsole-setup.service(8) man:vconsole.conf(5) |
| 51 |
DefaultDependencies=no |
| 52 |
Before=initrd-switch-root.target shutdown.target |
| 53 |
ConditionPathExists=/dev/tty0 |
| 54 |
|
| 55 |
[Service] |
| 56 |
Type=oneshot |
| 57 |
ExecStart=/lib/systemd/systemd-vconsole-setup |
| 58 |
|
| 59 |
However, as a little test / possible workaround, I decided to create |
| 60 |
my own systemd unit file that does nothing more but execute |
| 61 |
/lib/systemd/systemd-vconsole-setup, only at a (hopefully) later stage |
| 62 |
during the boot process: |
| 63 |
|
| 64 |
# cat /etc/systemd/system/vconsole-fix.service |
| 65 |
|
| 66 |
[Unit] |
| 67 |
Description=Fix Virtual Console |
| 68 |
Before=-.mount |
| 69 |
ConditionPathExists=/dev/tty0 |
| 70 |
|
| 71 |
[Service] |
| 72 |
Type=oneshot |
| 73 |
ExecStart=/lib/systemd/systemd-vconsole-setup |
| 74 |
|
| 75 |
[Install] |
| 76 |
WantedBy=multi-user.target |
| 77 |
|
| 78 |
And after enabling this unit, things actually work just fine: My |
| 79 |
keymap is, once again, set up properly on the virtual console right |
| 80 |
after boot and before I log in or perform any manual steps. |
| 81 |
|
| 82 |
Sadly, I'm kind of confused now. I'm really wondering if anyone's ever |
| 83 |
seen something like that before or otherwise has an explanation for |
| 84 |
it. I mean, it used to work before, and neither configuration nor |
| 85 |
package versions have been changed. It's just that everything has been |
| 86 |
re-build (as PIEs), but I can hardly imagine that this is responsible |
| 87 |
for the issue. |
| 88 |
|
| 89 |
Right now, I'm waiting for a second machine to complete the re-emerge |
| 90 |
process (might take another while) and am then really curious to see |
| 91 |
if it suddenly suffers from the same oddity. Other than that, the only |
| 92 |
idea that I currently have is to keep the workaround deployed and have |
| 93 |
a look if the issue disappears again by itself just as suddenly as it |
| 94 |
started, probably with a forthcoming version of systemd or something. |
| 95 |
Of course, understanding things is always preferrable than just |
| 96 |
hoping for them to fix themselves, so if someone has a clue, I'd be |
| 97 |
more than glad to hear about it! :-) |
| 98 |
|
| 99 |
Greetings |
| 100 |
Nils |
Archives