Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDDM 0.16 isn't started automatically by systemd #905

Closed
grayk79 opened this issue Oct 11, 2017 · 41 comments
Closed

SDDM 0.16 isn't started automatically by systemd #905

grayk79 opened this issue Oct 11, 2017 · 41 comments

Comments

@grayk79
Copy link

grayk79 commented Oct 11, 2017

systemctl enable sddm does link successfully but on the next system restart nothing happens. The last thing seen is how the video driver is loaded successfully and that's all. Loading sddm from a tty with systemctl start sddm does work like it should. The logs are empty, no sign of an error. And systemctl status does list sddm as loaded for some reason. Only downgrading to sddm 0.15 helped to get the system booted up automatically like it always has had and should. For now I have blacklisted sddm from upgrading

OS: Arch Linux x64
Xorg: 1.19.4
Qt: 5.9.2
Plasma: 5.11
Video driver: AMDGPU

@farseerfc
Copy link
Contributor

farseerfc commented Oct 11, 2017

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

@cchurchill82
Copy link

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

@Dar13
Copy link

Dar13 commented Oct 13, 2017

Is this the official solution or just a workaround?

@BobbyBabes
Copy link

BobbyBabes commented Oct 13, 2017

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.

@Scimmia22
Copy link

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.

@DeX77
Copy link

DeX77 commented Oct 16, 2017

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

@farseerfc
Copy link
Contributor

farseerfc commented Oct 17, 2017

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.

@Musikolo
Copy link

Musikolo commented Oct 20, 2017

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

@angel6700
Copy link

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"

@TheEdward162
Copy link

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

@majewsky
Copy link
Contributor

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.

@sgon00
Copy link

sgon00 commented Nov 2, 2017

+1

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

@jonathonf
Copy link

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?

@antonio-rojas
Copy link

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

@BobbyBabes
Copy link

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.

sddm-0 16 0_hangs-boot-process

@elvisangelaccio
Copy link

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.

@BobbyBabes
Copy link

BobbyBabes commented Nov 8, 2017

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

@elvisangelaccio
Copy link

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

@BobbyBabes
Copy link

BobbyBabes commented Nov 8, 2017

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

@h4nn35
Copy link
Contributor

h4nn35 commented Nov 9, 2017

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

@antonio-rojas
Copy link

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

@BobbyBabes
Copy link

BobbyBabes commented Nov 11, 2017

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

@Strit
Copy link

Strit commented Nov 13, 2017

Running

sudo systemd-sysusers sddm.conf

made sddm start for me.

@NuLogicSystems
Copy link

NuLogicSystems commented Nov 13, 2017

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

@BobbyBabes
Copy link

BobbyBabes commented Nov 13, 2017

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

@NuLogicSystems
Copy link

NuLogicSystems commented Nov 13, 2017

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

@h4nn35
Copy link
Contributor

h4nn35 commented Nov 14, 2017

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

@BobbyBabes
Copy link

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

@NuLogicSystems
Copy link

NuLogicSystems commented Nov 14, 2017

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

@BobbyBabes
Copy link

@NuLogicSystems He wrote :

It's worth a shot.

@NuLogicSystems
Copy link

NuLogicSystems commented Nov 14, 2017

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.

@h4nn35
Copy link
Contributor

h4nn35 commented Nov 14, 2017

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

@sanosis
Copy link

sanosis commented Nov 20, 2017

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

@grayk79
Copy link
Author

grayk79 commented Nov 30, 2017

@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

@Gibbz
Copy link

Gibbz commented Dec 2, 2017

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

@antonio-rojas
Copy link

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

@BobbyBabes
Copy link

BobbyBabes commented Dec 3, 2017

@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

@oskarkook
Copy link

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

@Musikolo
Copy link

Musikolo commented Dec 3, 2017

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

Thank you!

@grayk79
Copy link
Author

grayk79 commented Dec 3, 2017

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

@angel6700
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests