Tumbleweed randomly boots with SDDM after restart (using SSD)

Hi! My problem is, that when I restart (or boot) my laptop, more often than not, at the moment when I expect SDDM to appear, a black screen pops-up with an underscore (or underline _ ) and that’s it. When I enter tty, I can login, restart my computer and after 3-4 tries SDDM finally shows. The only thing that I do in tty is just login, ask for root and then reboot. I am suspecting maybe that something doesn’t start in time (due to SSD) and sometimes I am just lucky. How can I solve this?

Thank you!

I see the underscore character (top left of screen) but SDDM always appears around 6-8secs later… it just seems slow to start.

Yes, but in my case due to the SSD, SDDM shows just a moment later (second or less) or not at all (more often than SDDM).

AFAIK this is being worked on. Nothing to do with SSD, but with sddm starting too fast. Again AFAIK the fix is already in the Frameworks5 repo.

Seroiusly…do you have any references to the bug reports or sth similar?

I think Knurpht means this:
But the patch mentioned there is already in Tumbleweed…

Then there are also those bug reports against Leap 42.1 Milestone2, which might not apply to Tumbleweed:
https://bugzilla.opensuse.org/show_bug.cgi?id=944659 (which seems not to be related to SDDM at all)

As I mentioned in the first one, there’s only one such problem I experienced myself: SDDM hangs with a black screen if Autologin is turned on and the configured session (in /etc/sddm.conf) does not exist (the default is hardcoded to Plasma5 in openSUSE).
I filed an upstream bug report about this: https://github.com/sddm/sddm/issues/497
But that can’t really be your problem, as this should happen every time, not randomly…

One suggestion:
Try to install sddm 0.12.0 from http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Factory/, or wait for the next snapshot (to be released in the next days) which should have it too.
Maybe that one works better for you?

Of course, a workaround would also be to use another display manager. Good options would probably be kdm (still in Tumbleweed :wink: ) or lightdm.
You can set the one to use in /etc/sysconfig/displaymanager.

We have a(n almost new) Lenovo, where I see this issue 497. Grabbed ssdm from Frameworks5 and the issue’s gone. The nasty thing is that I cannot find anything in the log files / journalctl.

Of course, a workaround would also be to use another display manager. Good options would probably be kdm (still in Tumbleweed :wink: ) or lightdm.
You can set the one to use in /etc/sysconfig/displaymanager.

Well, the mentioned “issue 497” is still present in the KDE:Frameworks5 version, and in latest upstream git AFAICT.
That would also be easily workarounded by setting an existing session in /etc/sddm.conf or systemsettings5’s sddm module, and is really only a problem if you try to use sddm in a minimal (or GNOME e.g.) installation without Plasma5 installed…

So your problem seems not to have been that, but as upgrading helped, it might help the OP too, I suppose.

Thanks for that, it works now. I upgraded the SDDM to 0.12.0 (with Frameworks5 repo) and locked updates for this package for now and when the new version comes in the official tumbleweed repo, I will remove the F5 repo.

Ok, good to hear! :slight_smile:

As mentioned, 0.12.0 should be in the next snapshot, which unfortunately has been delayed too long now for other reasons…