Mailinglist Archive: opensuse-bugs (4233 mails)

< Previous Next >
[Bug 1020327] [Build 20170116] openQA test fails in consoletest_finish
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Thu, 26 Jan 2017 10:01:14 +0000
  • Message-id: <>

--- Comment #31 from Fabian Vogt <fvogt@xxxxxxxx> ---
(In reply to Franck Bui from comment #30)
(In reply to Fabian Vogt from comment #29)
So, I'm back after some further analysis on this.

Thanks a lot for investigating deeper in this.

The second one is 0001-let-it-become-a-real-daemon.patch which totally
breaks console locking. With broken console locking you cannot guarantee for
anything anymore and systemd-vconsole-setup breaks the console that plymouth
uses, which ultimately led to the crash in plymouth's terminal keyboard

Is the crash in plymouth's driver fixable ?

As it is "just" an assert, the error could just be ignored.
However, I consider simultaneous access to the VT as undefined behaviour as it
causes all kind of weird issues. Just ignoring this would for instance allow
systemd-vconsole-setup to switch the keyboard layout *while* entering the
decryption password or changing the fontmap while displaying a text splash etc.

With the broken patch removed, will systemd-vconsole-setup fail when opening
the vtconsole if it has been locked by plymouth ?

I don't know, a quick test with plymouth running on tty1 showed that it returns

The patch is AFAICS wrong as the reason it got introduced was a
misconfiguration of systemd services (bsc#892526). Removal of this patch
means however that systemd-vconsole-setup cannot configure the console while
plymouth is running (which it never did with RemainAfterExit=true before
v232) so we likely need the Wants= and After= for
systemd-vconsole-setup.service in plymouth-start.service to not bring back
console font/keymap issues.

Well I don't see any need to keep systemd-vconsole-setup.service but the
vtconsole stuff is an obscure area to me so I may miss some useful use cases.

If we agree on the fact that this service is unneeded I can open an issue
upstream and ask to remove the service completely. If upstream doesn't agree
then we could at least ask for the correctness of setting


AFAIK upstream rewrote the service (and binary) completely, so that may require
some retesting with the newest version (which they'll probably demand anyway).

Franck's idea of removing the Wants= from plymouth-start.service worked
because systemd-vconsole-setup.service didn't get pulled in from anything
else and so never ran at all. However, issue #1 prevented it from working
altogether in openQA.

Yeah I realized that this morning.

Now with 0001-let-it-become-a-real-daemon.patch removed, everything will
work just fine *if* we make sure that plymouth gets stopped when needed
(e.g. by YaST firstboot, X and other display servers).

Result of this is in
Please review and test!

I will give it a test.

Make sure to get at least rev 17, I did some changes in the patch to avoid DRM
initialization delays.

Thanks !

You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >