Bug 990083

Summary:	plymouth: On machine updated from 13.1 to TW, plymouth crashes, dropping back to tty1
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Dominique Leuenberger <dimstar>
Component:	Other	Assignee:	Cliff Zhao <qzhao>
Status:	RESOLVED NORESPONSE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	dimstar, fcrozat, sreeves, yfjiang
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Dominique Leuenberger 2016-07-21 20:46:38 UTC

Based on openQA test https://openqa.opensuse.org/tests/226651
(note: this is not new, just finally found time to investigate it a bit)

AS can be seen in the test run, 13.1 is being booted, TW repos put in place and then zypper dup executed (passes without any issues)

upon reboot, the graphical environment (gnome) is actually starting up (this is not visibile on openQA, but is what I found out on a local reproducer of the issue)

* the GNOME Session is being started, auto logged in as expected
* shortly after, the system drops to tty1

=> logging in there is well possible and inspecting running processes shows that the X-session is still up and running; it did not crash!

according to some journal entries, it seems though as plymouth is the one crashing away, which seems to instruct the system to switch to tty1 for some reason.

For verification of this theory I removed plymouth from my test VM (zypper rm plymouth; mkinitrd), rebooted and the GNOME session stays up without dropping to tty1

Comment 1 Dominique Leuenberger 2016-07-21 20:53:15 UTC

For completeness sake to verify the theory I re-installed plymouth; this triggered re-creation of initrd (post script)

upon a reboot, the gnome session again appears and shortly after I'm back ton tty1

Comment 2 Dominique Leuenberger 2016-07-22 07:30:25 UTC

Managed to chase it down a bit more:
* turns out that 13.1's kernel command line contains 'console=ttyS0' - and TW seems not to like that

In my test machine, with plymouth installed again, I can now trigger the fail/success by adding / removing console=ttyS0 on the kernel command line.

Comment 5 Dominique Leuenberger 2016-11-30 08:20:31 UTC

With a NEEDINFO I very much appreciate a question.. otherwise: the info is in the bug incl. how to reproduce it (console=ttyS0 on the kernel command line)

The last openQA run that showed it: https://openqa.opensuse.org/tests/310689

(as this bug had no reaction for nearly half a year, I modified the 13.1 base disk to not have console=ttyS0 in the kernel cmd line - which made the issue no longer show in openQA - but that does not mean it's no longer there)

Comment 6 Cliff Zhao 2017-02-20 07:38:26 UTC

(In reply to Dominique Leuenberger from comment #5)
> With a NEEDINFO I very much appreciate a question.. otherwise: the info is
> in the bug incl. how to reproduce it (console=ttyS0 on the kernel command
> line)

Dear Dominique:
I was busy to deal some L3 bug these days. Thanks for your reminder.

And I tried "console=tty0/console=ttyS0,9600n8" 
This will make kernel messages  appear on the serial port. Messages from the init system and the system logger will appear only on the first serial port. 
Result observation: 
  System pretty have non output now, 
  but plymouth still not crash.
  when i run # coredumpctl list, return is "No coredumps found".
:-(

Comment 7 Cliff Zhao 2017-08-10 11:16:17 UTC

This bug can not be reproduced, and no responded.
We can open it if it happens again in future.