Same here, but only happens sometimes.
When this happens, login through tty and restart sddm by systemctl restart sddm or pkill sddm will start sddm normally.

OS: Arch Linux x64
Xorg: xorg-server 1.19.4
Qt: qt5-base 5.9.2
Plasma: 5.11
Video driver: i915 with xorg modesetting

This can be fixed by building your video module (i915, raedon, etc) module into the initramfs.
Link to Arch bug report: https://bugs.archlinux.org/task/55960

Is this the official solution or just a workaround?

sudo nano /etc/mkinitcpio.conf
Modified the modules line to MODULES="amdgpu" # Was : MODULES="".
sudo mkinitcpio -p linux
shutdown -h now

Then powering back on, did the trick for me.

This happens when SDDM tries to start before video is totally initialized. By adding your video module to early userspace, you initialize video earlier and avoid the problem, but it doesn't really fix the root issue. Not sure if the issue is here, in systemd, or in the kernel.

Seems like there was a similar Issue some time ago:

systemd/systemd#2612

I tried adding systemd-vconsole-setup.service to After= but that didn't help

Unfortunately I cannot add i915 to early userspace, because there is another unrelated issue that will cause the backlight adjusting module not loaded properly on my device.

Same issue happens to me on Lenovo T400. Reverting back to sddm-0.15 solves the problem. I haven't tried adding any module in /etc/mkinitcpio.conf though.

OS: ArchLinux x64
Xorg: xorg-server 1.19.5-1
Qt: qt5-base 5.9.2-1
Video driver: i915

Same problem here, with a laptop acer 1410.
But fixed either reverting to sddm 0.15, or
sddm 0.16 + editing mkinitcpio.conf and adding MODULES="i915"

Same problem on Dell Inspiron 7000
Either reverting to version 0.15 or adding "i915" to MODULES fixes the problem

The workaround works for me as well, but I'd still appreciate a solution that does not require that. I usually do not load the video driver in the initrd as the modesetting-induced flickering delays the display of the LUKS passphrase prompt by a few seconds.

+1

OS: Manjaro x64
Xorg: xorg-server 1.19.5-1
Qt: qt5-base 5.9.2-1
Video driver: i915

lightdm.service has:

After=getty@tty1.service systemd-user-sessions.service plymouth-quit.service acpid.service

The only difference there is acpid.service - any use?

Given that this seems to be a regression in 0.16, if would be good if someone affected could bisect it

Linux htpc 4.13.11-1-ARCH #1 SMP PREEMPT Thu Nov 2 10:25:56 CET 2017 x86_64 GNU/Linux
sddm 0.16.0-1
xorg-server 1.19.5-1
qt5-base 5.9.2-1
mesa 17.2.4-1
xf86-video-amdgpu 1.4.0-1

I just gave it a shot on my htpc (old hardware; ignore the USB and amdgpu errors, they are always there).
I postpended acpid.service to the After= line. Same problem. Hangs at : see screenshot.

FWIW, I can reproduce it only on my Intel laptop, but not on my desktop with proprietary Nvidia drivers. Both systems run more or less the same Archlinux packages.

@elvisangelaccio Reproduce with acpid.service added or without, or both ?

@BobbyBabes I didn't add anything, so whatever the default is (without?).

@elvisangelaccio The default is without on Arch. Can’t vouch for other distros.

I tried to bisect the problem and if my bisect worked then commit 2187cd8 is where the issue started.

Does it work if you add systemd-logind.service to the After= line in sddm.service?

@antonio-rojas Just tried. I postpended systemd-logind.service to the After= line in /usr/lib/systemd/system/sddm.service.
Alas, similar result as per my previous attempt with postpending acpid.service. This time with an awful flash though. My heart skipped a beat.

P.S. I'm out for a few hours soon. It's dinner time.

Running

sudo systemd-sysusers sddm.conf

made sddm start for me.

Yes, worked for me as well.
It's seems like systemd isn't updating the db after install/upgrade.
https://www.freedesktop.org/software/systemd/man/sysusers.d.html
https://www.freedesktop.org/software/systemd/man/systemd-sysusers.html

Maybe we need to issue systemd-sysusers specifically during install like the gdm package does:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/gdm.install?h=packages/gdm

It's there since October 8. So I didn't bother issuing the command. :

[bobbybabes@htpc 4.4.12 ~]# ls -lah /usr/lib/sysusers.d
total 240K
drwxr-xr-x   2 root root 4,0K nov  5 20:38 .
drwxr-xr-x 201 root root 192K nov  9 13:04 ..
-rw-r--r--   1 root root 1,1K okt 26 16:06 basic.conf
-rw-r--r--   1 root root   21 sep 15 20:47 ceph.conf
-rw-r--r--   1 root root  206 okt 30 16:24 dbus.conf
-rw-r--r--   1 root root   36 sep 27 20:59 mariadb.conf
-rw-r--r--   1 root root   11 okt  3 06:17 qemu.conf
-rw-r--r--   1 root root   56 okt  8 22:55 sddm.conf
-rw-r--r--   1 root root  505 okt 26 16:06 systemd.conf
-rw-r--r--   1 root root  398 okt 26 16:06 systemd-remote.conf
-rw-r--r--   1 root root   11 okt 19 14:28 util-linux.conf
-rw-r--r--   1 root root   18 okt 18 23:44 virtualbox.conf
[bobbybabes@htpc 4.4.12 ~]# 

This is the content of /usr/lib/sysusers.d/sddm.conf :
u sddm - "Simple Desktop Display Manager" /var/lib/sddm

Yes, but it doesn't seem to be working properly after the upgrade.
However, issuing the systemd-sysusers sddm.conf command manually fixes the issue and sddm is able to load again.

It could possibly have something to do with the way in which sddm.tmpfiles is setting permissions and/or user and group causing the issue as well.

Here is how I'm doing this with spawny:
https://github.com/NuLogicSystems/PKGBUILD/blob/master/anna/spawny.sysusers
https://github.com/NuLogicSystems/PKGBUILD/blob/master/anna/spawny.tmpfiles
Notice that I'm leaving these settings alone in spawny.tmpfiles as 0755 is already the default, and spawny.sysusers will set the user and group.

PS. I updated my previous comment..

This commit ba9ab1d fixes this issue for my setup.
It's worth a shot.

@h4nn35 This wouldn’t have made it into the Arch Linux package yet : Last Updated: 2017-10-11 11:18 UTC. I can’t test until then.

@BobbyBabes Of course not, Arch pulls releases, not development code. That commit was made only 16 hours ago, is the 130th commit since 0.16.0 was released, and was submitted by h4nn35 themself.

@h4nn35 Talk about tooting your own horn. ;)

@NuLogicSystems He wrote :

It's worth a shot.

It seems these other two command were needed for ClickXT over at Manjaro:
sudo systemctl set-default graphical.target
sudo systemctl restart sddm
https://forum.manjaro.org/t/is-sddm-still-screwed/34662/18

@BobbyBabes That why the winking smiley face.

Sorry, that I wasn't clear enough.
What I meant is that you could try to compile sddm with this patch and see if it solves your problem as it did for me. == It's worth a shot. :-)

If sddm works after systemctl restard sddm you can add a delay to sddm:

1. Define your favorite editor if you haven't already (replace vim with your choice):
   export EDITOR=vim
2. Edit unit
   systemctl edit sddm
3. Add to the editor (10s delay):

[Service]
ExecStartPre=/bin/sleep 10

This will create /etc/systemd/system/sddm.service.d/override.conf

@sanosis this is a good workaround for now that doesn't mess with the driver or the kernel. I just hate seeing that there are available updates and I just couldn't take that anymore :D Btw a shorter delay works too, I myself used 1 second and everything works just as expected. But I still hope the bug will get fixed soon

Is there any eta on a fix for this?
It's a bit annoying having to go around fixing this on all my machines.

Arch Linux users please test 0.16.0-3, I've backported the commit from #905 (comment)

@antonio-rojas @h4nn35 @grayk79 Confirming that sddm 0.16.0-3 resolves this issue. Thanks to you and all others who helped.

Changed line MODULES="amdgpu" back to MODULES="". Recreated /etc/mkinitcpio.conf. Recreated /boot/grub/grub.cfg.
At the first boot the screen went completely black and then showed an almost full screen of colourful artefacts. But the boxes booted into sddm. On two subsequent boots, the artefacts were not there anymore.

Linux ladyluck 4.14.3-1-ARCH #1 SMP PREEMPT Thu Nov 30 18:33:13 UTC 2017 x86_64 GNU/Linux
sddm 0.16.0-3
xorg-server 1.19.5-1
qt5-base 5.9.3-1
mesa 17.2.6-1
xf86-video-amdgpu 1.4.0-1

Linux htpc 4.14.3-1-ARCH #1 SMP PREEMPT Thu Nov 30 18:33:13 UTC 2017 x86_64 GNU/Linux
sddm 0.16.0-3
xorg-server 1.19.5-1
qt5-base 5.9.3-1
mesa 17.2.6-1
xf86-video-amdgpu 1.4.0-1

@antonio-rojas seems to fix it for me, thanks

@antonio-rojas, yes, it solves the issue for me too.

Thank you!

Multiple users have reported that the issue is solved(me myself can't test it atm). May I close the thread then?

Before closing I also report that sddm 0.16.0-3 fixes the problem.
Thank you antonio-rojas.