Bug 16896

Summary: sddm-0.12.0-1.mga6 fails to reach the sddm login screen
Product: Mageia Reporter: Marja Van Waes <marja11>
Component: RPM PackagesAssignee: Florian Hubold <doktor5000>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: Normal CC: doktor5000, mageia
Version: Cauldron   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: sddm-0.12.0-1.mga6 CVE:
Status comment:
Attachments: journalctl -b output

Description Marja Van Waes 2015-10-04 14:18:46 CEST
Created attachment 7086 [details]
journalctl -b output

Until sddm-0.12.0-1.mga6, sddm would always fail to start on this particular laptop, but then start fine after doing 

systemctl restart plymouth-quit.service
systemctl restart dm.service

after updating to sddm-0.12.0-1.mga6, that no longer works. sddm gives an error message and then falls back to a more primitive dm.

I haven't updated my other cauldrons (where sddm used to start fine immediately), yet. Therefore setting this report to UNCONFIRMED for now.
Marja Van Waes 2015-10-04 14:18:55 CEST

Source RPM: (none) => sddm-0.12.0-1.mga6

Comment 1 Sander Lepik 2015-10-04 14:24:28 CEST
Are you useing sddm.service directly or through prefdm.service?

If you are still using prefdm.service then try this:

systemctl disable prefdm
systemctl enable sddm
reboot

CC: (none) => mageia

Comment 2 Florian Hubold 2015-10-04 16:07:15 CEST
(In reply to Marja van Waes from comment #0)
> Until sddm-0.12.0-1.mga6, sddm would always fail to start on this particular
> laptop, but then start fine after doing 
> 
> systemctl restart plymouth-quit.service
> systemctl restart dm.service

Sorry but that sounds like a broken configuration beforehand to me. Maybe you start with a systemd ordering cycle like in bug 16260 but plymouth-quit should not stop the X start. Go for Sander's suggestion first.


Also the boot looks interesting. sddm starts first at
okt 04 13:35:23 cauldron64bit sddm[978]: Initializing...

then your issues with plymouth-wait:

okt 04 13:37:38 cauldron64bit systemd[1]: plymouth-quit-wait.service: Unit entered failed state.
okt 04 13:37:38 cauldron64bit systemd[1]: plymouth-quit-wait.service: Failed with result 'timeout'.
[...]
okt 04 13:37:51 cauldron64bit systemd[1]: Stopping Display Manager...
okt 04 13:39:21 cauldron64bit systemd[1]: prefdm.service: State 'stop-sigterm' timed out. Killing.


and then after quite some time (4 minutes boot time?) again sddm ... ?


okt 04 13:39:37 cauldron64bit sddm[9546]: Initializing...


then it starts successfully and shortly thereafter seems it dies together with the X server:


okt 04 13:40:34 cauldron64bit systemd[1]: Stopping Simple Desktop Display Manager...
okt 04 13:40:34 cauldron64bit sddm[9546]: Signal received: SIGTERM
okt 04 13:40:34 cauldron64bit sddm[9546]: Greeter stopping...
okt 04 13:40:34 cauldron64bit sddm[9546]: Socket server stopping...
okt 04 13:40:34 cauldron64bit sddm[9546]: Socket server stopped.
okt 04 13:40:34 cauldron64bit sddm[9546]: Display server stopping...
okt 04 13:40:34 cauldron64bit sddm-greeter[9557]: The X11 connection broke (error 1). Did the X11 server die?
Florian Hubold 2015-10-04 16:07:36 CEST

Assignee: bugsquad => doktor5000

Comment 3 Marja Van Waes 2015-10-04 17:19:55 CEST
I was _wrong_, the SDDM login screen started fine, after a text message about failing to start the graphical interface.

SDDM just looks very different than before and it having preselected IceWM made me think it was some primitive DM.

(In reply to Sander Lepik from comment #1)
> Are you useing sddm.service directly or through prefdm.service?
> 
> If you are still using prefdm.service then try this:
> 
> systemctl disable prefdm
> systemctl enable sddm
> reboot

That fixed it, thanks:
* no more systemctl restart steps are needed
* no more error about not being able to start the graphical interface is shown
* and sddm now shows "Plasma" preselected, as it should.


@ Florian

Those 4 minutes were minutes in which I messed around in VT, trying different things, looking at logs and such.

Closing this report as invalid, since sddm did start, after all ;-)

Thanks, Sander and Florian, for your help :-)

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => INVALID