Bug 1350107 - SDDM Login screen blank - sddm-helper exit with 6, when using breeze sddm theme
Summary: SDDM Login screen blank - sddm-helper exit with 6, when using breeze sddm theme
Status: CLOSED DUPLICATE of bug 1370222
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-workspace   
(Show other bugs)
Version: 25
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-25 16:04 UTC by Gerald Cox
Modified: 2017-02-19 13:13 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-30 12:57:28 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Diff of good Xorg.0.log vs bad one (9.53 KB, patch)
2016-12-16 23:25 UTC, Matthew Cline
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Github sddm sddm issues 756 None None None 2017-01-29 19:55 UTC
KDE Software Compilation 364835 None None None 2016-06-27 23:33 UTC

Description Gerald Cox 2016-06-25 16:04:33 UTC
Description of problem:
After upgrade to F24, am not able to login normally.  When booting, at the time the SDDM login screen appears, I receive a blank screen.

Version-Release number of selected component (if applicable):
sddm-0.13.0-7.fc24.x86_64


How reproducible:
Boot system

Steps to Reproduce:
1. Boot system
2.
3.

Actual results:
Receive blank screen instead of SDDM login prompt


Expected results:  Receive SDDM login screen


Additional info:
If I login using single user mode, then issue an init 5, everything works fine.
Also, if I ssh into the system and enter systemctl restart sddm.service
everything starts ok.

Upon failure a systemctl status sddm.service shows:
● sddm.service - Simple Desktop Display Manager
   Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2016-06-25 12:40:22 BRT; 2min 44s ago
     Docs: man:sddm(1)
           man:sddm.conf(5)
 Main PID: 857 (sddm)
    Tasks: 3 (limit: 512)
   CGroup: /system.slice/sddm.service
           ├─857 /usr/bin/sddm
           └─909 /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{da20086e-70cd-4024-8f94-20299aaac458} -background none -noreset -displayfd 17 vt1

Jun 25 12:40:22 localhost.localdomain systemd[1]: Started Simple Desktop Display Manager.
Jun 25 12:40:28 localhost.localdomain sddm-helper[1037]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
Jun 25 12:40:36 asphodel sddm[857]: Auth: sddm-helper exited with 6

After restart is shows:

● sddm.service - Simple Desktop Display Manager
   Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2016-06-25 12:43:55 BRT; 12min ago
     Docs: man:sddm(1)
           man:sddm.conf(5)
 Main PID: 1229 (sddm)
    Tasks: 3 (limit: 512)
   CGroup: /system.slice/sddm.service
           ├─1229 /usr/bin/sddm
           └─1232 /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{96bebe09-fbba-41a8-9220-1d85c0158fc8} -b

Jun 25 12:43:55 asphodel systemd[1]: Started Simple Desktop Display Manager.
Jun 25 12:43:56 asphodel sddm-helper[1235]: pam_unix(sddm-greeter:session): session opened for user sddm by (ui
Jun 25 12:44:22 asphodel sddm-helper[1289]: pam_kwallet5(sddm:auth): (null): pam_sm_authenticate
Jun 25 12:44:22 asphodel sddm-helper[1289]: pam_kwallet(sddm:auth): (null): pam_sm_authenticate
Jun 25 12:44:22 asphodel sddm[1229]: Oops, secure memory pool already initialized
Jun 25 12:44:22 asphodel sddm-helper[1289]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
Jun 25 12:44:22 asphodel sddm-helper[1289]: pam_kwallet(sddm:setcred): pam_kwallet: pam_sm_setcred

Comment 1 Gerald Cox 2016-06-26 14:23:11 UTC
Opened upstream bug here:
https://github.com/sddm/sddm/issues/651

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1350107

This just started happening to me on a Lenovo ideapad 500 when I upgraded to F24. I read through the comments on #412 and also the Gentoo downstream bugs. If I put in the sddm.timer with a value of 30 I can get it to work. Adding sddm to video group doesn't apply because Fedora has pam and systemd. Apparently SDDM needs something that is not available when it starts, hence the delay helps - but not all users are going to (or should have to) trudge through Google and a bunch of bug reports to find the work around. They're just going to give up. I'll help in anyway I can to get this resolved.
Thanks!

Comment 2 Gerald Cox 2016-06-26 14:34:43 UTC
Also, instead of using a timer, wouldn't it be better to just find out whatever it is waiting for and add that to the After in the systemd service file?

Comment 3 Rex Dieter 2016-06-26 14:59:25 UTC
I assume the purpose of the timer is to simply delay sddm startup?  (if so, I would suspect that's more a workaround rather than a proper fix).

Comment 4 Rex Dieter 2016-06-26 15:22:49 UTC
Another possible culprit that similarly affected kdm startup in the past:  journald

kdm had a default startup timeout of ~30 seconds (iirc), and merging journals on boot can sometimes slow things quite a bit.  This is one reason why I personally often limit journal sizes far beyond their defaults, using config parameters such as:
SystemMaxUse=50M
and/or
Storage=volatile

Comment 5 Gerald Cox 2016-06-26 15:24:14 UTC
(In reply to Rex Dieter from comment #3)
> I assume the purpose of the timer is to simply delay sddm startup?  (if so,
> I would suspect that's more a workaround rather than a proper fix).

Yes, that is my understanding.(In reply to Rex Dieter from comment #4)
> Another possible culprit that similarly affected kdm startup in the past: 
> journald
> 
> kdm had a default startup timeout of ~30 seconds (iirc), and merging
> journals on boot can sometimes slow things quite a bit.  This is one reason
> why I personally often limit journal sizes far beyond their defaults, using
> config parameters such as:
> SystemMaxUse=50M
> and/or
> Storage=volatile

I'll look into that.

Comment 6 Gerald Cox 2016-06-26 15:27:02 UTC
Just posted this upstream also:
Jun 26 12:13:33 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sddm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 26 12:13:40 asphodel audit[962]: USER_AUTH pid=962 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_permit acct="sddm" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success'
Jun 26 12:13:40 asphodel audit[962]: USER_ACCT pid=962 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_permit acct="sddm" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success'
Jun 26 12:13:40 asphodel audit[962]: CRED_ACQ pid=962 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_permit acct="sddm" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success'
Jun 26 12:13:40 asphodel audit[966]: USER_ACCT pid=966 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="sddm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 26 12:13:40 asphodel audit[966]: USER_START pid=966 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_selinux,pam_selinux,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="sddm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jun 26 12:13:40 asphodel sddm-helper[962]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
Jun 26 12:13:40 asphodel audit[962]: USER_START pid=962 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_unix,pam_systemd acct="sddm" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=:0 res=success'
Jun 26 12:13:40 asphodel systemd[966]: pam_unix(systemd-user:session): session opened for user sddm by (uid=0)
Jun 26 12:13:40 asphodel systemd[1]: Created slice User Slice of sddm.
Jun 26 12:13:40 asphodel systemd-logind[678]: New session c1 of user sddm.
Jun 26 12:13:40 asphodel systemd[1]: Started Session c1 of user sddm.
Jun 26 12:13:41 asphodel audit[990]: ANOM_ABEND auid=4294967295 uid=992 gid=988 ses=4294967295 pid=990 comm="sddm-greeter" exe="/usr/bin/sddm-greeter" sig=6
Jun 26 12:13:41 asphodel sddm-greeter[990]: QXcbConnection: Could not connect to display :0
Jun 26 12:13:41 asphodel abrt-hook-ccpp[1026]: Process 990 (sddm-greeter) of user 992 killed by SIGABRT - dumping core
Jun 26 12:13:50 asphodel sddm[767]: Auth: sddm-helper exited with 6
Jun 26 12:13:50 asphodel systemd[975]: pam_unix(systemd-user:session): session closed for user sddm
Jun 26 12:13:50 asphodel systemd[1]: Removed slice User Slice of sddm.
~

Comment 7 Gerald Cox 2016-06-26 16:03:35 UTC
(In reply to Rex Dieter from comment #4)
> Another possible culprit that similarly affected kdm startup in the past: 
> journald
> 
> kdm had a default startup timeout of ~30 seconds (iirc), and merging
> journals on boot can sometimes slow things quite a bit.  This is one reason
> why I personally often limit journal sizes far beyond their defaults, using
> config parameters such as:
> SystemMaxUse=50M
> and/or
> Storage=volatile

I went ahead and implemented, but unfortunately didn't help...

Comment 8 Rex Dieter 2016-06-26 16:15:06 UTC
Jun 26 12:13:41 asphodel sddm-greeter[990]: QXcbConnection: Could not connect to display :0


OK, so the real question here is... why is X refusing the connection?

Comment 9 Gerald Cox 2016-06-26 22:10:24 UTC
(In reply to Rex Dieter from comment #8)
> Jun 26 12:13:41 asphodel sddm-greeter[990]: QXcbConnection: Could not
> connect to display :0
> 
> 
> OK, so the real question here is... why is X refusing the connection?

Yes... and if you have any ideas of additional information I can provide to narrow it down, let me know.

Comment 10 Gerald Cox 2016-06-26 22:12:29 UTC
(In reply to Gerald Cox from comment #9)
> (In reply to Rex Dieter from comment #8)
> > Jun 26 12:13:41 asphodel sddm-greeter[990]: QXcbConnection: Could not
> > connect to display :0
> > 
> > 
> > OK, so the real question here is... why is X refusing the connection?
> 
> Yes... and if you have any ideas of additional information I can provide to
> narrow it down, let me know.

but it appears for whatever reason, sddm is requesting before x is ready... at least that is what I'm guessing because the sddm.timer circumvention is a functioning workaround.

Comment 11 Gerald Cox 2016-06-27 14:54:39 UTC
Thought it might be helpful to instructions for the temporary workaround.  If anyone discovers a better way please post.

From root:
Create the file:  /usr/lib/systemd/system/sddm.timer

Contents are as follows:

[Unit]
Description=Start sddm service fixed time after boot

[Timer]
OnStartupSec=30
Unit=sddm.service

[Install]
WantedBy=multi-user.target


Please note:  you may need to modify the OnStartupSec value.  I used 30 seconds, however the example in the Gentoo bug I took this from used 20 seconds.  That wasn't long enough for me.

Then issue the following commands:
systemctl disable sddm.service
systemctl enable sddm.timer

To remove the workaround, simply enter:
systemctl disable sddm.timer
systemctl enable sddm.service

Comment 12 Gerald Cox 2016-06-27 18:55:06 UTC
I'm using the breeze theme.  What I found was that the other themes worked fine.  I then did a compare between the 01-breeze-fedora theme and the breeze theme.  What I found was that the permissions on the file:

/usr/share/sddm/themes/breeze/components/artwork/background.png
/usr/share/sddm/themes/01-breeze-fedora/components/artwork/background.png

were different.  In the 01-breeze-fedora version it was 777, in the breeze version (which has the issue) it is 644.  Apparently, that is the issue.

I changed the permissions for:
/usr/share/sddm/themes/breeze/components/artwork/background.png
to 777

and it now is working correctly.  The sddm-timer is no longer needed.

Comment 13 Gerald Cox 2016-06-28 16:32:03 UTC
(In reply to Gerald Cox from comment #12)
Oops, forgot to change to plasma-workspace...

Comment 14 Rex Dieter 2016-06-28 16:43:22 UTC
The permissions thing *really* seems like a red-hearing to me.  In fact, I'd expect the correct permission should be 644

Comment 15 Rex Dieter 2016-06-28 16:44:20 UTC
Adjusting summary

Comment 16 Gerald Cox 2016-06-28 18:08:49 UTC
(In reply to Rex Dieter from comment #14)
> The permissions thing *really* seems like a red-hearing to me.  In fact, I'd
> expect the correct permission should be 644

You're right... I put another file there with 644 permissions and it is working.  There apparently is something goofy with that file.  Could you please send me what you think should be the correct background.png file for the breeze theme.  Maybe the copy I have got corrupted somehow or maybe there is an issue with the upstream png.  Either attach here or send to gbcox@bzb.us

and I'll see if that copy works.

Comment 17 Gerald Cox 2016-06-28 18:41:37 UTC
Nevermind, pulled it from koji - it's the same file... if I run it through gimp and save as a png, the filesize goes down and it works.  If I use the version from the source, it doesn't.  Any ideas?

Comment 18 Gerald Cox 2016-06-28 18:43:40 UTC
FYI... I ran it through md5sum and it checks out OK...

Comment 19 Gerald Cox 2016-06-28 18:43:51 UTC
FYI... I ran it through md5sum and it checks out OK...

Comment 20 Gerald Cox 2016-06-29 13:05:52 UTC
After the latest round of updates, neither the 01-fedora-breeze or the breeze themes work.  So to borrow a phrase you used, the background.png was a red herring.  The other themes, such as maui - which I switched to, work fine.

Comment 21 Gerald Cox 2016-06-30 14:12:54 UTC
I didn't putting in an arbitrary timer, which always executed.  It hid what was happening, so I created the script below.  
It will create a file sddm_workaround.log and tell you if the service was not available at the time of execution and/or if it needed to be restarted.  It will also tell you how many times it needed to try.  You can also modify the script to do additional debugging.

To enable, from root:
crontab -e
@reboot /home/your_home_directory_here/sddm_workaround.sh

The add the following to your home directory as sddm_workaround.sh; remember to set permissions to executable.

#! /bin/bash

count=0
count_file="/home/your_home_directory_here/sddm_workaround.log"
dt=$(date)

printf "%s $dt Starting...\n" >> $count_file

until systemctl status sddm.service | grep "active (running) since" --quiet
do
        let "count++"
        printf "%s $dt Waiting for service to start:  $count\n" >> $count_file
        sleep 1
done

count=0

while systemctl status sddm.service | grep "sddm-helper exited with" --quiet
do
        let "count++"
        printf "%s $dt Attempting service start:  $count\n" >> $count_file
        systemctl reload-or-restart sddm.service
        sleep 1
done

printf "%s $dt Exiting...\n" >> $count_file

exit

Comment 22 Bruce Petrie 2016-12-09 05:18:50 UTC
I have a Dell Inspiron 531S running F24 4.8.11-200.fc24.x86_64 that exhibits the original poster's issue including the journalctl sddm-helper error 6 with a blank login screen. 

This system has been doing this for each new update over the past two months or so until a new version of the sddm packages is pushed out (I think with about 90% confidence). sddm will then work correctly until a new kernel and a bunch of rpms are pushed out. Then sddm starts failing again.

I can make sddm correctly present the login screen every time with no sddm-helper error 6 by editing /etc/sddm.conf and simply uncomment the current theme line reading "Current=01-breeze-fedora". If the line is commented out, sddm-helper will fail again. Repeatable every time.

# ls -al /usr/share/sddm/themes/
total 20
drwxr-xr-x. 5 root root 4096 Jun 14 10:41 .
drwxr-xr-x. 7 root root 4096 Jun 14 10:39 ..
drwxr-xr-x. 3 root root 4096 Dec  8 10:57 01-breeze-fedora
drwxr-xr-x. 2 root root 4096 Jun 14 10:39 02-fedora
drwxr-xr-x. 3 root root 4096 Dec  8 10:57 breeze

None of the workarounds discussed in previous posts are needed. I found this bugzilla bug today along with other entries on sddm github. Simply uncomment the current theme line and the problem goes away!

$ rpm -qa sddm\*
sddm-kcm-5.8.4-1.fc24.x86_64
sddm-0.13.0-7.fc24.x86_64
sddm-breeze-5.8.4-1.fc24.noarch

If RH needs other info/logs, I can provide them.

Comment 23 info@kobaltwit.be 2016-12-10 09:10:33 UTC
I've hit this problem yesterday when doing a fresh install of Fedora 25 on an aging computer for a customer.

I started from the KDE Live image. After the install I could successfully reboot without any issues. I then installed all updates and from then on the same issue as described here appeared, including the sddm-helper error 6.

I have only found this bug today. When I return to the customer I'll test the above suggestions and report my findings.

I chose to add this comment to indicate
- the issue also happens with Fedora 25, not only 24
- it will happen from a clean install

Final remark, at home I have 3 fast machines upgraded to F25 (all running from sdd drives) and none of them exhibits this behaviour. So this does add possible evidence for a timing issue.

Comment 24 Matthew Cline 2016-12-16 23:25 UTC
Created attachment 1232784 [details]
Diff of good Xorg.0.log vs bad one

This was happening to me under F24, but is still happening under F25. Also, the problem is intermittent, so further evidence that this is a timing issue.

Also, I diffed the Xorg.0.log from when the bug happened (BAD) vs when it didn't happen (GOOD), and the BAD log is missing some of the EDID info and modeline info that the GOOD log had.  The diff of the logs is attached.

Comment 25 Gerald Cox 2017-01-29 19:52:40 UTC
Updating to F25.  I've installed on another laptop and same thing... black screen.  This is a pervasive issue:
https://bbs.archlinux.org/viewtopic.php?id=220562

This doesn't occur on my desktop system, but does on laptops (now two, different brands).  Good quote from the archlinux link:

"This solution is far from ideal and appears to be an ongoing problem with SDDM which shows no signs of being resolved. I have also reported this problem upstream at the SDDM GitHub site."

Right now on the effected machines I've switched back to KDM.

Comment 26 Fedora Update System 2017-01-29 21:37:04 UTC
sddm-0.14.0-7.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fbb17b6755

Comment 27 Rex Dieter 2017-01-29 21:40:20 UTC
Just in case, try setting in /etc/sddm.conf

[General]
# Enable Qt's automatic high-DPI scaling
EnableHiDPI=false


Otherwise, it's more likely to be:
https://github.com/sddm/sddm/issues/733

and a dup of bug #1370222

Comment 28 Gerald Cox 2017-01-30 01:27:19 UTC
Thanks for the tip Rex...

Tried the EnableHiDPI on both machines, no effect.

Read 1370222 and tried disconnecting the network cable when booting.  That worked on the newer laptop.  

One the older one, same result... black screen.  Appears while 1370222 might catch some of the problems... something else is happening.  As I mentioned, on both machines GDM and KDM work perfectly fine.  Just having the issue with SDDM.

Comment 29 Rex Dieter 2017-01-30 12:56:38 UTC
sounds like you're still hitting the xauth issue then (or something else new and not-yet-understood).

Comment 30 Rex Dieter 2017-01-30 12:57:28 UTC
tentatively marking as dup of bug #1370222

*** This bug has been marked as a duplicate of bug 1370222 ***

Comment 31 Gerald Cox 2017-02-19 13:13:36 UTC
Can confirm that changing /etc/hostname to match dhcp entry resolved issue.


Note You need to log in before you can comment on or make changes to this bug.