From: Nils Holland <nholland@tisys.org>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] systemd-vconsole-setup: Suddenly fails after system rebuild
Date: Tue, 5 Dec 2017 10:43:03 +0100 [thread overview]
Message-ID: <20171205094302.GA2698@tisys.org> (raw)
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
reply other threads:[~2017-12-05 9:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171205094302.GA2698@tisys.org \
--to=nholland@tisys.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox