Bug 1084629 - System hangs in boot after upgrade to Tumbleweed 20180307
System hangs in boot after upgrade to Tumbleweed 20180307
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Upgrade Problems
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Fabian Vogt
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-09 09:59 UTC by Freek de Kruijf
Modified: 2018-11-21 10:23 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Freek de Kruijf 2018-03-09 09:59:21 UTC
I upgraded Tumbleweed to 20180307 after the previous version. After the reboot the system hangs quite early in the boot process and shows a black screen. I solved the situation by using a system on another partition to clear "rm -rf /var/lib/sddm/.cache", the mentioned folder on the Tumbleweed system partition.
Comment 1 Marius Kittler 2018-03-27 09:20:27 UTC
So this is clearly an SDDM issue then.

I'm also recently experiencing a similar (maybe the same) issue. In my case SDDM also just hangs leaving me with a black screen. Maybe it is just very slow.

When I switch to another tty I can restart SDDM via `systemctl restart display-manager` which sometimes helps. If not, I currently just stop the hanging display manager and start the X/Plasma session myself using `startx`. This always works - so the X server can not be the problem.

I made another observation: When opening the SDDM configuration in systemsettings5 it takes very very long to load (but it finally shows up).

Unfortunately the journal of SDDM or the systemsettings5 output do not contain any useful information like error messages.

Maybe it helps to remove the cache here, too. The slowly loading systemsettings5 keeps loading slow, also with the cache removed. I'll try to restart later to check whether it at least helps for SDDM itself.
Comment 2 Fabian Vogt 2018-05-11 09:57:22 UTC
(In reply to Marius Kittler from comment #1)
> So this is clearly an SDDM issue then.

Or Mesa, or Qt, or graphics driver, or X...

Does this issue still exist?

> I'm also recently experiencing a similar (maybe the same) issue. In my case
> SDDM also just hangs leaving me with a black screen. Maybe it is just very
> slow.
> 
> When I switch to another tty I can restart SDDM via `systemctl restart
> display-manager` which sometimes helps. If not, I currently just stop the
> hanging display manager and start the X/Plasma session myself using
> `startx`. This always works - so the X server can not be the problem.
> 
> I made another observation: When opening the SDDM configuration in
> systemsettings5 it takes very very long to load (but it finally shows up).

That's interesting. It opens near instantly for me.
It might be QML related, what happens with LIBGL_ALWAYS_SOFTWARE=1 kcmshell5 kcm_sddm?

> 
> Unfortunately the journal of SDDM or the systemsettings5 output do not
> contain any useful information like error messages.
> 
> Maybe it helps to remove the cache here, too. The slowly loading
> systemsettings5 keeps loading slow, also with the cache removed. I'll try to
> restart later to check whether it at least helps for SDDM itself.
Comment 3 Marius Kittler 2018-05-11 13:09:56 UTC
> Or Mesa, or Qt, or graphics driver, or X...

I excluded other components in the graphical stack because these were/are working fine, eg. in Plasma session.

> Does this issue still exist?

At least not in my case. I was able to fix the issue by getting rid of NIS. Apparently it was searching for users via NIS which took sometimes very long.

However, I would still consider this a usability issue in SDDM. It doesn't tell you what it does - not even via the journalctl log - and just leaves you with a black screen. There's no loading indication or a way to abort/skip. But this is likely something for the SDDM upstream issue tracker.
Comment 4 Fabian Vogt 2018-05-11 13:34:57 UTC
(In reply to Marius Kittler from comment #3)
> > Or Mesa, or Qt, or graphics driver, or X...
> 
> I excluded other components in the graphical stack because these were/are
> working fine, eg. in Plasma session.
> 
> > Does this issue still exist?
> 
> At least not in my case. I was able to fix the issue by getting rid of NIS.
> Apparently it was searching for users via NIS which took sometimes very long.

That bug got fixed several weeks ago, you can enable it again.

> However, I would still consider this a usability issue in SDDM. It doesn't
> tell you what it does - not even via the journalctl log - and just leaves
> you with a black screen. There's no loading indication or a way to
> abort/skip. But this is likely something for the SDDM upstream issue tracker.
Comment 5 Freek de Kruijf 2018-11-21 10:23:04 UTC
Seems to be fixed.