Overview
Request 477768 accepted
- Call "plymouth quit --retain-splash" instead of "plymouth_quit" in the displaymanager script to hide the text mode login prompt during boot (the dedicated sddm.service does the same).
- Also, don't call xdm_reload_files, that just re-generates the xdm config files according to the sysconfig values and only makes sense for xdm.
Request History
wolfi323 created request
- Call "plymouth quit --retain-splash" instead of "plymouth_quit" in the displaymanager script to hide the text mode login prompt during boot (the dedicated sddm.service does the same).
- Also, don't call xdm_reload_files, that just re-generates the xdm config files according to the sysconfig values and only makes sense for xdm.
Vogtinator declined request
The plymouth_quit behaviour should be changed in /usr/lib/X11/display-manager directly, as I don't see a reason to change this only for sddm.
wolfi323 reopened request
Are you sure?
That's tailor-made for xdm, and no other displaymanager script uses it.
(except lightdm, but they probably just copied it as well)
Vogtinator accepted request
+1 for me. Fabian, what do you think?
Yes, the other scripts can than use it as well. IMO this is not sddm-specific and should be integrated into the general function
Well, there may be good reasons why xdm doesn't do it. Maybe we should file a bug report against Xorg to ask?
The other scripts (kdm and gdm at least) do not even quit plymouth at all though. Those DM's handle a running plymouth themselves.
Yes, a bug report is a good idea. Maybe it's eve na good idea to do it the same way in sddm, as there is still a short window between X startup and plymouth shutdown using this script
Yes, but sddm should be able to deal with it.
From the changelog: Mon May 25 17:39:12 UTC 2015 - hrvoje.senjan@gmail.com
I did test this on 3 systems (intel, radeon and vmware), did work fine. And I tested it also with the plymouth_quit removed at all, sddm tried to restart itself all the time...
As I see it, sddm does wait for plymouth to quit, and restarts itself after a timeout. So there should not be a race condition. (unless plymouth fails to quit, but then we would have problems now too)
That change only applies for sddm.service, which is not used by default, is it? That would also explain your sddm restart loop with plymouth_quit removed.
Yes. But the same "short window" you mentioned should apply there I think.
No. That was with the displaymanager script, when I removed that plymouth quit stuff at all. The point was that sddm apparently will wait for plymouth to quit, and restart itself if it doesn't after a (possible) timeout.
The only reference to plymouth in sddm is in sddm.service itself. There is a patch that adds ExecStartPre=-@CMAKE_INSTALL_FULL_BINDIR@/plymouth quit --retain-splash though, maybe that needs to be removed now
Well, it might not reference plymouth directly, it might just check if it can access the VT... ;-)
If that's upstream now (haven't checked), then we can remove that patch I suppose. But that's unrelated to this change.
Or do you mean our patch?
The change is a patch only we have and probably not required anymore
That's unrelated to the displaymanager script though.
Quitting plymouth is definitely still needed, with the 0.14.0 in KF5 at least.
Yes, but currently sddm.service does it two ways, once via plymouth-quit-wait.service and once with the ExecStartPre.
I'm not sure if we have plymouth-quit-wait.service enabled in Tumbleweed or not. It isn't in Leap 42.2.
But again, that's unrelated to display-manager.service and this change.
I heard that xdm will be dropped in the near future anyway, leaving us with sddm.service only, so it should be fixed some time.
Will you report the plymouth_quit bug or shall I?
I think you mean that display-manager.service will be dropped, right? ;-)
I will file a bug report tomorrow.
But I still think we should do this change.
The whole xdm! display-manager.service is part of xdm, yes.
I think we can wait until a proper fix is available for plymouth, but the xdm_reload_conf change can go in right now.
Really? Well. But in what time scale?
And why not the other thing too? If xdm is going to go, there's no need to wait for a plymouth fix either, is it?
Sorrym I'm just not understanding your reasoning here, TBH.
It just came up as an idea some days/weeks ago and I agree that using the XDM stuff to just launch a different display manager in the end is a bit weird.
If plymouth_quit is really only used here, sure.
So, is it ok to go in?
Once there's a bug report for XDM to fix it properly (so it won't get lost), yes. I won't accept the :LTS request yet, I'll want to see how it behaves in factory first as plymouth related changes can often cause quite severe issues (maybe this leaves the VT in a mode sddm does not like on some monitors or drivers, etc...)
Ok: https://bugzilla.opensuse.org/show_bug.cgi?id=1028717
I gave xdm a try today, and it started up fine with --retain-splash.
Btw, the sddm.service patch is still necessary (on 42.2 at least). I tried without and sddm failed to start, i.e. I experienced the endless restart loop again (and an unusable system because I wasn't even able to login in text mode because of that). The reason is that plymouth-quit.service has a "Conflicts=graphical.target" I think, it is being run when booting to text mode. OTOH, it doesn't use --retain-splash either (would probably not be a good idea in text mode I suppose).
So, the reason for not using --retain-splash in plymouth_quit is that it will also hide the textmode login prompt in case the DM (or X) fails to start. Unfortunately, this is also the case with sddm.
I guess it's better to revert this change then for now. I will do a SR later today (I don't think there's a need to go into panic mode now, as that only happens if things fail anyway).
Btw, this also applies to the dedicated sddm.service. Though even after removing the --retain-splash there, the text mode login prompt is still missing in the case that X fails to start (you can only see kernel message that may have happened during boot).
Indeed, this needs to be fixed as well, as we use tty7 and not tty1:
Conflicts=getty@tty1.service
PS, I found this patch from Mandriva: https://github.com/OpenMandrivaAssociation/sddm/blob/master/sddm-0.14.0-add-suport-to-plymouth-smooth-transition.patch
I think I will give this a try then, to improve the user experience...
I don't like that patch, it contains obvious bugs, which are never a good sign:
+Conflicts=getty@tty1.service plymouth-quit.service +After=getty@tty1.service plymouth-quit.service
Ok, I can/will leave that out. It only affects the sddm.service anyway, not display-manager.
Any other objections? I haven't tried it at all yet, but the rest does look sane to me on a first look.
I'm not sure how it fixes the issue that --retain-splash conflicts with text login, but I haven't had a close look yet
As I see it, with that patch we don't need to quit plymouth at all in the displaymanager script. sddm will do that then.
If the sddm greeter fails to start, plymouth will stay running, and the xdm script (which is used as fallback) will quit it. If Xorg fails to start, I suppose the greeter won't be started at all and only "plymouth deactivate" will be run.
But I have to test it first, and this time I will try the failing case too... ;-)
Should read: "If sddm fails to start..."
My tests so far showed this: - the patch improves things in the working case. The splash stays until the login screen shows up, before there was a blank screen for a while (even with --retain-splash). - it doesn't help in the failing case. Now the splash screen stays instead of a blank screen, but that's no improvement either... :-(
But, if I replace "plymouth deactivate" with "plymouth quit", the failing case is also covered.
My tests: - specifying an invalid driver in the xorg.conf: the fallback to text mode works now. - moving libQt5Core5 away: doesn't work in both cases, with the patch or with the standard package, though now the splash screen stays, before a blank screen stays.
And of course the standard boot still works too.
@Vogtinator: Do you happen to know what "plymouth deactivate" does, compared to quit?
But all in all, I do think that this would be the best way to go...
plymouth deactivate tells plymouth to stop displaying the splash screen. Maybe it doesn't release the consoles fully, which would explain the issue.
Ok, thanks for the explanation.
Just to be sure: do you have any further objections?
The current patch looks like this: https://build.opensuse.org/package/rdiff/home:wolfi323:test/sddm?opackage=sddm&oproject=KDE%3AFrameworks5&rev=19
PS: I do need to make it runtime conditional still, plymouth might not be installed...
Should be enough to just test for plymouth in the system command like "hash plymouth && plymouth quit" or something like that.
Yes, but on second thought, the system() call will just fail in case plymouth is not installed and not cause any further problems... But I'll test that as well before I do a submit request.
For me, plymouth behaviour is non-deterministic... I use neither plymouth nor sddm on my machine, so I'll trust your tests, openQA and the resulting bug reports ;-)
OK, but AFAIK you looked more into the plymouth code than I ever did, which is not at all...;-)
Anyway, sddm boots fine with plymouth uninstalled too, so the SR is upcoming.
Ping, it would be good to fix this properly in TW so that there is enough time to test it in TW to submit it to 42.3 as well.
Well, it turned out that the "plymouth deactivate" call is actually essential for a smooth experience. It's called before the greeter is started, replacing it with "quit" makes it essentially the same as calling "plymouth_quit" (without --retain-splash) in the displaymanager script in the first place.
But, I noticed that the problem I mentioned having here (in the case that X fails to start because of a wrong driver in the xorg.conf) is not really caused by plymouth or this change at all. What apparently happens is that sddm doesn't seem to even notice that X fails, and goes into that endless loop again, restarting it (and the greeter) again and again.
The same happens if I deactivate plymouth, and actually even without this change, i.e. with the original script that calls "plymouth_quit". I just didn't notice it because the system did show a text mode login prompt (on VT1) in this case. But the problem can be seen in the logs... (and maybe the CPU usage)
So, there apparently are deeper problems.
I haven't tested yet whether this also happens with 0.13, or is a regression.
In short, I have nothing to submit currently, at least nothing that I'm confident of that it works. I'll try to investigate more though.
The reason why I'm asking is that https://openqa.opensuse.org/tests/379169# looks like it could be caused by this submit request: Plymouth occupies tty1 and no text login is possible. I'm not sure though, especially because the GNOME test looks to have a similiar issue.
Well, I never noticed anything like that here on 42.2. If the sddm greeter shows up, switching back to VT1 always gives me a text mode login prompt.
OTOH, things may be different in current Tumbleweed of course.
I haven't looked at what gdm does exactly, but judging from the kdm patch we use (which apparently is based on gdm originally), it would likely also call "plymouth quit --retain-splash" to quit plymouth, so this may indeed be the reason.
If you prefer, we can revert this change, I'm not really against it.
But if "--retain-splash" is really the cause for the failing tests, GNOME will likely need to disable the smooth transition in gdm as well. (and we probably should disable the kdm patch too...)
Just a thought though: Maybe you noticed anyway, but there is a difference in the two plymouth screen shots. Could it be that the problem is rather that plymouth gets restarted somehow? IIANM, the test calls "systemctl isolate multi-user.target", I do remember having such a problem when "switching runlevels" once years ago... (and if "--retain-splash" would be the reason, I suppose the splash should be there in pictures before as well, but I have to admit I'm not sure what the tests do exactly)
BTW, sddm 0.13 (as shipped in Leap 42.2) does not enter this endless loop I mentioned, because it just crashes if X fails to start... :-/
Ok, I did so for now, even if just to see what happens in TW. If the issue still happens, we can revert the revert :-)
I'm not sure either, some earlier tests fail in a similiar way, but not quite the same. In https://openqa.opensuse.org/tests/373703#step/multi_users_dm/10 there is still a screenshot of the root console which we don't have anymore now...
Yes, 0.13 is extremely sensitive and likely to crash, 0.14 does improve that. With KF 5.32 I'll also copy sddm from KF5 to :LTS, especially because of HiDPI support.