http://bugzilla.suse.com/show_bug.cgi?id=1056937 http://bugzilla.suse.com/show_bug.cgi?id=1056937#c1 --- Comment #1 from Zhao Qiang 赵强 --- Do you mean it occasionally fails at the step of: "Installation -> first_boot"? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1056937 http://bugzilla.suse.com/show_bug.cgi?id=1056937#c3 --- Comment #3 from Zhao Qiang 赵强 --- In the latest run of openQA, this case still failed. https://openqa.opensuse.org/tests/493580#step/multi_users_dm/15 so luckily, I can get the virtual machine image to do the further investment. I think this case failed most because "could not sync environment to dbus." Refer to: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/47 If we try to replace "systemctl isolate graphical.target" to "systemctl start graphical.target", everything goes well. it indicates that action "isolate" lost some necessary work which needs to be finished. I suppose we can make some work on Systemd to fix that. You said that "They are still animated while in the X session.", that is caused of Xwindows and Plymouth try to use VT in a race situation. This case works fine in the latest test. and when I run it offline, it also works fine. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1056937 http://bugzilla.suse.com/show_bug.cgi?id=1056937#c5 --- Comment #5 from Fabian Vogt --- (In reply to Zhao Qiang 赵强 from comment #3)

In the latest run of openQA, this case still failed. https://openqa.opensuse.org/tests/493580#step/multi_users_dm/15 so luckily, I can get the virtual machine image to do the further investment.

I think this case failed most because "could not sync environment to dbus." Refer to: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/47 If we try to replace "systemctl isolate graphical.target" to "systemctl start graphical.target", everything goes well. it indicates that action "isolate" lost some necessary work which needs to be finished. I suppose we can make some work on Systemd to fix that.

I debugged this a bit and found:

Starting Show Plymouth Boot Screen... Started Show Plymouth Boot Screen. Starting X Display Manager...

which means systemctl isolate graphical.target does actually start plymouth-start.service for some reason. I can't see it in systemctl list-dependencies though, only under sysinit.target which shouldn't be touched by isolate at all as it's part of both multi-user.target and graphical.target.

You said that "They are still animated while in the X session.", that is caused of Xwindows and Plymouth try to use VT in a race situation. This case works fine in the latest test. and when I run it offline, it also works fine.

Yes, it's likely a race as it does not happen in all cases. It can't happen if plymouth weren't running. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1056937 http://bugzilla.suse.com/show_bug.cgi?id=1056937#c7 --- Comment #7 from Fabian Vogt --- (In reply to Zhao Qiang 赵强 from comment #6)

(In reply to Fabian Vogt from comment #5)

...

(In reply to Zhao Qiang 赵强 from comment #3)

which means systemctl isolate graphical.target does actually start plymouth-start.service for some reason. I can't see it in systemctl list-dependencies though, only under sysinit.target which shouldn't be touched by isolate at all as it's part of both multi-user.target and graphical.target.

Do you mean that "systemctl isolate graphic.target" trigger plymouth start but "systemctl start graphic.target" didn't do that?

I did not try systemctl start graphical.target, but isolate does result in a start of plymouth-start for some reason. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1056937 http://bugzilla.suse.com/show_bug.cgi?id=1056937#c10 --- Comment #10 from Zhao Qiang 赵强 --- (In reply to Fabian Vogt from comment #9)

(In reply to Zhao Qiang 赵强 from comment #8)

...

(In reply to Fabian Vogt from comment #7)

...

(In reply to Zhao Qiang 赵强 from comment #6)

...

(In reply to Fabian Vogt from comment #5)

...

(In reply to Zhao Qiang 赵强 from comment #3)

I did not try systemctl start graphical.target, but isolate does result in a start of plymouth-start for some reason.

Even it makes result in Plymouth be mistaken started, it still can not say that fault *Must* happens inside Plymouth.

It's indeed not necessarily plymouth itself, but likely somewhere in its .service files.

...

Additionally, when I try to disable/remove Plymouth, this problem still can reproduce.

You uninstalled plymouth and it still starts? I would say that is impossible. You probably didn't reboot and the daemon was still running in the background.

Maybe there was some mistake between us: The fact is: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/28 runs the same test case. This time, "Plymouth race with Xorg" problem wasn't reproduced, but "systemctl isolate graphic.target" reproduced. This will prove that "isolate" problem can be produced *separately*. I mean when I disable/remove Plymouth, "isolate" problem is still there. The main target of this case is want to confirm if multi-user target and graphic target can be switched smoothly, So I want to discuss this problem here. Yes! I will say that "race" is indeed a problem, I never deny this fact. but It will be solved after "isolate" problem be fixed. Because "race" problem only can happen after "isolate" scenario. Another reason is in current situation, we can not say "display manager" or Xwindows is beyond of doubled(even we uninstalled Plymouth, X can't switch well) Regards! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1056937 http://bugzilla.suse.com/show_bug.cgi?id=1056937#c12 --- Comment #12 from Fabian Vogt --- The test shows two entirely independent issues: 1) systemctl isolate graphical.target results in a broken DBUS daemon This causes the test to fail and is not relevant here. It's tracked in a different report. 2) Plymouth stays running after isolate graphical.target This is the part of the test that this bug is about. The test run you linked still shows the issue: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/48 It just happened later on that run. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1056937 http://bugzilla.suse.com/show_bug.cgi?id=1056937#c14 --- Comment #14 from Fabian Vogt --- (In reply to Zhao Qiang 赵强 from comment #13)

(In reply to Fabian Vogt from comment #12)

...

The test shows two entirely independent issues:

1) systemctl isolate graphical.target results in a broken DBUS daemon This causes the test to fail and is not relevant here. It's tracked in a different report. Okay, that's very clear. Could you please show me the bug ID? and has this bug been fixed?

boo#1020363 - not fixed yet.

...

2) Plymouth stays running after isolate graphical.target This is the part of the test that this bug is about. The test run you linked still shows the issue: https://openqa.opensuse.org/tests/493580#step/multi_users_dm/48 It just happened later on that run.

All staff in Beijing will leave the office for China's National Day till Oct 8. I will invest on this issue at that time, and then, answer your question.

Ok, thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1056937 http://bugzilla.suse.com/show_bug.cgi?id=1056937#c16 --- Comment #16 from Fabian Vogt --- (In reply to Zhao Qiang 赵强 from comment #15)

KDE and Plymouth share the same frame-buffer device because Sddm lack of Plymouth controlling logic, A reference is GDM's code: https://github.com/GNOME/gdm/blob/master/daemon/gdm-manager.c#L142-#L208

Wrong, it calls plymouth quit in /usr/lib/X11/displaymanagers/sddm The issue is that plymouth is started *after* sddm. -- You are receiving this mail because: You are on the CC list for the bug.