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!

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?

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).

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

(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.

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.
~

(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...

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?

(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.

(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.

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

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.

(In reply to Gerald Cox from comment #12)
Oops, forgot to change to plasma-workspace...

The permissions thing *really* seems like a red-hearing to me.  In fact, I'd expect the correct permission should be 644

Adjusting summary

(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

and I'll see if that copy works.

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?

FYI... I ran it through md5sum and it checks out OK...

FYI... I ran it through md5sum and it checks out OK...

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.

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

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.

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.

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.

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.

sddm-0.14.0-7.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fbb17b6755

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

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.

sounds like you're still hitting the xauth issue then (or something else new and not-yet-understood).

tentatively marking as dup of bug #1370222

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

Can confirm that changing /etc/hostname to match dhcp entry resolved issue.