Bug 1066510

Created attachment 747157 [details]
The problem point from openQA screenshot.

I think this is caused by the same reason with 
Bug 1046083 - openQA test fails in first_boot - Plymouth screen stay for a very long time until test timeout
https://bugzilla.suse.com/show_bug.cgi?id=1046083
Also, please refer to my attached screenshot.

The cause reason is explained in comment28 in that bug.
Current progress is in comment32~35 in that bug, Yast team's manager and developer have a little divergence.

Plymouth's behavior is correctly, because the system already hanging there.
or change the test case will be a compromise.

Thanks!

that was the right hint, thanks! Nevertheless there are multiple things wrong here:

1. yast checks whether xorg-x11-server is selected for installation to propose graphical.target. The scripts to terminate plymouth are in the xdm package though. So yast needs to check for xdm instead of xorg-x11-server.
2. the commands that terminate plymouth are in the xdm package. Couldn't this be solved with service files, just like it's done with multi-user.target? That way graphical.target would always work wrt plymouth, even if xdm is not installed.
3. the minimal installation pulls in xorg-x11-server. I guess some misguided supplements triggers this somewhere.

(In reply to Ludwig Nussel from comment #2)
> that was the right hint, thanks! Nevertheless there are multiple things
> wrong here:
> 
> 1. yast checks whether xorg-x11-server is selected for installation to
> propose graphical.target. The scripts to terminate plymouth are in the xdm
> package though. So yast needs to check for xdm instead of xorg-x11-server.
I feel the Yast is better to check "display manager". because display-manager will depend on the graphics server, the graphics server may be xorg-x11-server but also may be Wayland. and I think what we need is a virtual definition, some user may only installed Gdm, Kdm, Lightdm ...


> 2. the commands that terminate plymouth are in the xdm package. Couldn't
> this be solved with service files, just like it's done with
> multi-user.target? That way graphical.target would always work wrt plymouth,
> even if xdm is not installed.

According to my understanding, Gdm and Sddm can work solo without Xdm.
So it will be a little complex. So we may consider 3 directions to stop Plymouth before the screen switch to display manager:
1) is terminate by command scripts, like Xdm
/usr/lib/X11/displaymanagers/xdm

2) is to terminate by systemd: like display-manager.service
/usr/lib/systemd/system/display-manager.service
[Unit]
Conflicts=... plymouth-quit.service ...
After=... plymouth-quit.service ...

3) is be terminated inside the display manager, like Gdm:
https://github.com/GNOME/gdm/blob/master/daemon/gdm-manager.c#L142-#L208

Currently, I found that:
1) Sometimes don't work fine, can't send the signal in time. which caused:
https://bugzilla.suse.com/show_bug.cgi?id=1056937
2) is very engineering and graceful, but 2) is strongly depending on Systemd. Unfortunately, Systemd is a parallel and unguaranteed time daemon, which means plymouth-quit.service is be called and launched after plymouth-quit.service indeed, but there may be a little nap time, screen flashing to black between Plymouth and display-manager. Display manager can't take the screen immediately after Plymouth quit. Frederic and other colleges in release team said they can't tolerate with user experience fall-back.
3) makes system components over-coupling, and bring difficulty on release work. but we depend on it to work for a long time. the behavior is fine. and it's the most smoothly transitioning solution. and we can see the upstream maintainer of Plymouth and Gdm is the same guy, that also explains why it works better than 1) and 2).
So, poring 3) to none gdm display-manager looks like a reluctantly viable option. 

Another point is I don't think the Plymouth exit action has many relationships with this bug: in this case, even the Xdm didn't suppose to be installed in "Text mode".

> 3. the minimal installation pulls in xorg-x11-server. I guess some misguided
> supplements triggers this somewhere.

Regards!

(In reply to Ludwig Nussel from comment #2)
> 
> 2. the commands that terminate plymouth are in the xdm package. Couldn't
> this be solved with service files, just like it's done with
> multi-user.target? That way graphical.target would always work wrt plymouth,
> even if xdm is not installed.

Maybe there's another question: Can Plymouth stop at this moment just like the multi-user scenario?
I'm afraid it can't.
The multi-user target is be terminated by 2), the premise condition of 2) is the target file(display-manager.service||multi-user.service) can be found. 
And If we test to remove Plymouth program, the result is Systemd will still pending there, Plymouth-quit.service will not be launched despite it can work.

(In reply to Zhao Qiang 赵强 from comment #3)
> (In reply to Ludwig Nussel from comment #2)
> > that was the right hint, thanks! Nevertheless there are multiple things
> > wrong here:
> > 
> > 1. yast checks whether xorg-x11-server is selected for installation to
> > propose graphical.target. The scripts to terminate plymouth are in the xdm
> > package though. So yast needs to check for xdm instead of xorg-x11-server.
> I feel the Yast is better to check "display manager". because
> display-manager will depend on the graphics server, the graphics server may
> be xorg-x11-server but also may be Wayland. and I think what we need is a
> virtual definition, some user may only installed Gdm, Kdm, Lightdm ...
> 
> 
> > 2. the commands that terminate plymouth are in the xdm package. Couldn't
> > this be solved with service files, just like it's done with
> > multi-user.target? That way graphical.target would always work wrt plymouth,
> > even if xdm is not installed.
> 
> According to my understanding, Gdm and Sddm can work solo without Xdm.

xdm not only contains xdm but also several support scripts shared with other
displaymanagers.

(In reply to Zhao Qiang 赵强 from comment #4)
> (In reply to Ludwig Nussel from comment #2)
> > 
> > 2. the commands that terminate plymouth are in the xdm package. Couldn't
> > this be solved with service files, just like it's done with
> > multi-user.target? That way graphical.target would always work wrt plymouth,
> > even if xdm is not installed.
> 
> Maybe there's another question: Can Plymouth stop at this moment just like
> the multi-user scenario?
> I'm afraid it can't.
> The multi-user target is be terminated by 2), the premise condition of 2) is
> the target file(display-manager.service||multi-user.service) can be found. 
> And If we test to remove Plymouth program, the result is Systemd will still
> pending there, Plymouth-quit.service will not be launched despite it can
> work.

I can't follow you here. If we put the same files that are atm in
multi-user.target also in graphical.target that woudl do the job, right?
Whether or not this causes flicker remains to be tested in practice I guess.

(In reply to Ludwig Nussel from comment #6)
> (In reply to Zhao Qiang 赵强 from comment #4)
> > (In reply to Ludwig Nussel from comment #2)
> > > 
> 
> I can't follow you here. If we put the same files that are atm in
> multi-user.target also in graphical.target that woudl do the job, right?
> Whether or not this causes flicker remains to be tested in practice I guess.

Sorry I'm not very clear. as 
> If we put the same files that are atm
I suppose this is an abbreviation, but What does the "atm" exactly meaning here?

> multi-user.target also in graphical.target that woudl
Do you mean "would" or "wouldn't"?
:-/

(In reply to Zhao Qiang 赵强 from comment #7)
> (In reply to Ludwig Nussel from comment #6)
> > (In reply to Zhao Qiang 赵强 from comment #4)
> > > (In reply to Ludwig Nussel from comment #2)
> > > > 
> > 
> > I can't follow you here. If we put the same files that are atm in
> > multi-user.target also in graphical.target that woudl do the job, right?
> > Whether or not this causes flicker remains to be tested in practice I guess.
> 
> Sorry I'm not very clear. as 
> > If we put the same files that are atm
> I suppose this is an abbreviation, but What does the "atm" exactly meaning
> here?

At The Moment :-) 

> > multi-user.target also in graphical.target that woudl
> Do you mean "would" or "wouldn't"?
> :-/

Would

(In reply to Ludwig Nussel from comment #6)
> (In reply to Zhao Qiang 赵强 from comment #4)
> > (In reply to Ludwig Nussel from comment #2)
> 
Okay, I understood now.

> I can't follow you here. If we put the same files that are atm in
> multi-user.target also in graphical.target that woudl do the job, right?
First, multi-user.target depending on /usr/lib/systemd/system/plymouth-quit.service to stop Plymouth, this service conflict with graphics.target and will call "plymouth quit" at last,but graphic target don't have this action.
That's the different point. 

So, If we want to port "multi-user" method to "graphics", we will copy the same command to "graphic", but no other files.

So, If the "do the job" here means stop Plymouth in graphics mode: 
Yes, it can be done. and this work already be done inside Gdm for SLE.
but if the "do the job" means to solve this bug: 
I'm afraid it can't. because graphical.target wasn't be installed in this bug's scenario. whatever command we put on the graphics.target list will not be executed.
and you mentioned about Xdm, I think only when it be launched in "multi-user", the stop action can work. but obviously, this is a violation of the design.

> Whether or not this causes flicker remains to be tested in practice I guess.
This problem will not happen in the scenario of the boot to character interface(just like multi-user.target).

Current status is：
1）this bug is caused by the same with 
Bug 1046083 - openQA test fails in first_boot - Plymouth screen stay for a very long time until test timeout

2) Ludwig wants to solve this problem by an error handler from Plymouth side.

3) A "plymouth stop" command can work because openSUSE can automatically switch to TTY1, with this console user can login. It's different from the earlier SLE editions sceinario which will hang on the idle TTY7.

4) Current problem which blocks the work is the "position" to put this action: Every suggested position have side effects, I suppose. Detailed please see these previous comments.
The ideal place is Systemd should provide an error handler machines when it found a service can't be archived, then it will launch my actions to clean the dirty environment or launch another program instead.
but Seems systemd don't provide this.

In the plymouth package we have a patch "stop-graphical.patch" that adds a conflict for plymouth-quit with graphical.target. That code is not upstream. Unfortunately the changes file does not mention any reason for why this patch was added.
So maybe removing those would be sufficient already?

FWIW looking at Fedora, they have a OnFailure=plymouth-quit.service in their displaymanager's service file.

(In reply to Ludwig Nussel from comment #11)
> In the plymouth package we have a patch "stop-graphical.patch" that adds a
> conflict for plymouth-quit with graphical.target. That code is not upstream.
> Unfortunately the changes file does not mention any reason for why this
> patch was added.
> So maybe removing those would be sufficient already?
After my confirming test, this can work smoothly. Thanks for your excellent guide!
This modification has been involved very early in openSUSE 13, in Comment23 of
https://bugzilla.suse.com/show_bug.cgi?id=850531
Frederic explained why he added this conflict.
Because it's impossible to track the original issue of this modification, So I think it's better to involve Frederic's opinions.

> FWIW looking at Fedora, they have a OnFailure=plymouth-quit.service in their
> displaymanager's service file.
Yes, this is a good hint and an elegant fall-back point. 
But in this bug's scenario, openSUSE system hang there because it wait for the uninstalled display-manager.service, so I suppose a fallback action inside this file maybe also can't be excuted. :-/

Frederic:
Do you have any concern if we disable the "stop-graphical.patch" in Plymouth?

1) This bug is Not caused by this patch but it can be solved by disabling this patch as a fallback action. Because in early releases, if we quit Plymouth then the system will hang in tty7 without login prompt, but for the current release, the system will switch to a new TTY automatically.

2) I have tried to disable this patch in many scenarios: boot to multi-user mode, boot to graphics mode, boot to graphics mode without display-manager.service. system all works fine.

3) the original bug for this patch can' be found, I suppose it's maybe about Plymouth quit too early before Gdm start. but I'm lacking the detailed reproduce steps. So I can't make the conclusion.

4) display-manager.service also has a line: 
"Conflicts=get@tty7.service plymouth-quit.service"
Maybe this is already replaced the "stop-graphical.patch" in the normal situation already?

Thanks for your time.

(In reply to Zhao Qiang 赵强 from comment #13)
> Frederic:
> Do you have any concern if we disable the "stop-graphical.patch" in Plymouth?

stop-graphical.patch was written to ensure plymouthd would not be stopped by plymouth-quit when graphical.target was run, but only by gdm/kdm/xdm and therefore to have a flicker-free bootsplash (seamless transition from bootplash to Xorg, mostly with gdm).

> 1) This bug is Not caused by this patch but it can be solved by disabling
> this patch as a fallback action. Because in early releases, if we quit
> Plymouth then the system will hang in tty7 without login prompt, but for the
> current release, the system will switch to a new TTY automatically.
> 
> 2) I have tried to disable this patch in many scenarios: boot to multi-user
> mode, boot to graphics mode, boot to graphics mode without
> display-manager.service. system all works fine.
> 
> 3) the original bug for this patch can' be found, I suppose it's maybe about
> Plymouth quit too early before Gdm start. but I'm lacking the detailed
> reproduce steps. So I can't make the conclusion.
> 
> 4) display-manager.service also has a line: 
> "Conflicts=get@tty7.service plymouth-quit.service"
> Maybe this is already replaced the "stop-graphical.patch" in the normal
> situation already?

It is possible the patch is obsolete these days.

(In reply to Ludwig Nussel from comment #11)
> In the plymouth package we have a patch "stop-graphical.patch" that adds a
> conflict for plymouth-quit with graphical.target. That code is not upstream.
> Unfortunately the changes file does not mention any reason for why this
> patch was added.
> So maybe removing those would be sufficient already?
> 
> FWIW looking at Fedora, they have a OnFailure=plymouth-quit.service in their
> displaymanager's service file.

Thanks!
Request#548021 has been accepted by openSUSE Factory.
https://api.opensuse.org/request/show/548021