Whenever I'm trying to start sddm it just sits there with a blinking cursor. It doesn't crash, I can stop it just fine using systemctl stop sddm and start the tty by using systemctl start getty@tty1.
Steps to Reproduce:
1.Run systemctl start sddm as root with version 0.18-r1
A blinking cursor
The SDDM display manager
- I'm using a Gentoo Linux with a 17.1 systemd profile.
- I'm running gentoo-sources-5.3.5 (due to certain drivers required)
- I've optimized my system using -march=znver1
- I am using nvidia-drivers-435.21 with the USE flags "X acpi driver kms multilib uvm and wayland"
- I've set eselect opengl set to nvidia
- I've set eselect opencl set to nvidia
- Whenever I run starts the xorg-server starts just fine and glxinfo | grep direct, it shows direct rendering as yes with the NVIDIA driver.
- When using sddm version 0.15.0 it works fine.
journalctl -xe shows
[date] [time] [hostname] sddm 18221 Initializing...
[date] [time] [hostname] sddm 18221 Starting...
[date] [time] [hostname] sddm 18221 Logind interface found
Nothing else is logged in /var/log. There's even no updated Xorg.0.log.
The same problem here sddm 0.15.0 ok but 0.18 not
- profile 17.1
- nvidia-drivers-435.21 (also downgrade to 390.129 doesn't works)
- openrc-0.41.2 with elogind-241.3
[07:15:23.127] (II) DAEMON: Initializing...
[07:15:23.134] (II) DAEMON: Starting...
[07:15:23.134] (II) DAEMON: Logind interface found
...so nvidia is the common theme. did that start recently? is it the same as bug 693538?
(In reply to Andreas Sturmlechner from comment #2)
> ...so nvidia is the common theme. did that start recently? is it the same as
> bug 693538?
In my case no, I can tell you tomorrow when the problem started.
> is it the same as bug 693538?
I'm not sure if problem is the same, in my case I don't have any black screen but only console prompt. I tried also with sddm-0.17.0-r4 and problem persist, tomorrow I try with 0.16.0-r2
When looking at the description and comments of the other problem it seems to a different problem. Perhaps it's related t best, but definitely different as my session doesn't even start and I have no xorg-server logging at all. All I see are those 3 lines of logging in journalctl.
I'm not using prime either. Just a NVIDIA card with nvidia-drivers.
I tried also sddm 0.16.0-r3 and problem persist, I can't answer to question when sddm stop to works because in sddm.log there is no date.
I might've found the culprit. I've finally got 0.18-r1 working. It seems that later versions of SDDM require CONFIG_DRM to be enabled in the kernel for some reason. It might be a bug or intentional, I'm not sure, but without it SDDM is not starting.
The way I've got it working is the following:
1. Make sure you compile your kernel with: "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) (specifically: CONFIG_DRM and CONFIG_DRM_KMS_HELPER) to enabled, even though https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers suggests otherwise. See: https://download.nvidia.com/XFree86/Linux-x86_64/435.21/README/kms.html for more details. The manual on wiki.gentoo.org seriously needs to be updated, as there's some more outdated and incorrect information.
2. Recompile the kernel and overwite it on the /boot partition and overwrite it (do NOT make a new version, as dracut detects the running kernel differently than nvidia-drivers does, and then it won't work).
3. Re-emerge the nvidia-drivers.
4. Emerge dracut and add add_drivers+="nvidia nvidia_drm nvidia_modeset nvidia_uvm" to dracut.conf.d/nvidia.conf
5. Run plymouth-set-default-theme breeze -R (replace breeze with whatever theme you're using) if you're using plymouth and otherwise just run dracut.
6. Edit /etc/default/grub.conf and append nvidia-drm.modeset=1 to the GRUB_CMDLINE_LINUX before quiet and splash.
After SSDM runs flawlessly.
Marco, can you confirm?
(In reply to Andreas Sturmlechner from comment #8)
> Marco, can you confirm?
I can confirm this only tomorrow
This might be related: https://github.com/systemd/systemd/issues/13773
(In reply to Andreas Sturmlechner from comment #10)
> This might be related: https://github.com/systemd/systemd/issues/13773
I tried to add this rule but nothing change.
(In reply to Andreas Sturmlechner from comment #8)
> Marco, can you confirm?
Now I can confirm that nvaert1986 solution work, I able to start sddm-0.18.1. I enable CONFIG_DRM_KMS_HELPER and added nvidia-drm.modeset=1 to the GRUB_CMDLINE_LINUX.
@nvaert1986 thank you very much!
Created attachment 595906 [details]
My 5.3.10 kernel config, solution does not work
GRUB command line: linux /boot/kernel-current root=PARTUUID=35503609-6c8e-4c14-9a49-bc41f1475b4c rootfstype=ext4 init=/lib/systemd/systemd ro quiet nosplash pci=noaer video=simplefb nvidia-drm.modeset=1
Unfortunately, for me the solution didn't work (kernel 5.3.10, nvidia-drivers 440.31). Fortunately, 'systemctl restart sddm' starts the login manager. My GRUB configuration uses the following line to start the kernel:
linux /boot/kernel-current root=PARTUUID=35503609-6c8e-4c14-9a49-bc41f1475b4c rootfstype=ext4 init=/lib/systemd/systemd ro quiet nosplash pci=noaer video=simplefb nvidia-drm.modeset=1
There must be something else required...
(In reply to Roman S. from comment #13)
> Unfortunately, for me the solution didn't work (kernel 5.3.10,
> nvidia-drivers 440.31). Fortunately, 'systemctl restart sddm' starts the
> login manager. My GRUB configuration uses the following line to start the
> linux /boot/kernel-current
> root=PARTUUID=35503609-6c8e-4c14-9a49-bc41f1475b4c rootfstype=ext4
> init=/lib/systemd/systemd ro quiet nosplash pci=noaer video=simplefb
> There must be something else required...
That's odd, as I'm using 5.3.8 and it's working fine with 435.21 and haven't seen anything related to a change in the video / graphics driver. Assuming you're booting a native UEFI system try removing video=simplefb, as you should be using efifb normally, which you don't have to specify explicitly as it gets detected automatically on my system.
Alternatively try setting the options as modprobe.d module option as it seems you're not loading the kernel setting at boot using a initramfs which the kernel option is meant for (though technically it could still work depending on how the module would interpret it and accept bootloader arguments).
Removed 'video=simplefb' (if I remember correctly, I had some problems with efifb, but what was it exactly... I don't remember now, I probably set this option some 5 years ago), added 'options nvidia-drm modeset=1' to one of the files in etc/modprobe.d (tried also 'options nvidia_drm modeset=1') - but my results are still the same.
(In reply to Roman S. from comment #15)
> Removed 'video=simplefb' (if I remember correctly, I had some problems with
> efifb, but what was it exactly... I don't remember now, I probably set this
> option some 5 years ago), added 'options nvidia-drm modeset=1' to one of the
> files in etc/modprobe.d (tried also 'options nvidia_drm modeset=1') - but my
> results are still the same.
You need to set it in your GRUB_CMD thing in the grub configuration file, that's the only way it works as far as I've found out.
I've updated to the 5.3.11-gentoo kernel yesterday, re-emerged the nvidia-drivers and it's still working without an initramfs, but with the option set in my GRUB_CMDLINE_LINUX.
I have the same problem with x11-misc/sddm-0.18.1-r1 after migrating to elogind yesterday (from consolekit).
sddm doesn't start.
If I downgrade sddm to x11-misc/sddm-0.15.0 it works.
I have :
$ grep CONFIG_DRM /usr/src/linux/.config | grep -v "^#"
$ cat /proc/cmdline
BOOT_IMAGE=/boot/kernel-4.19.97-gentoo root=/dev/sdb1 ro resume=/dev/sdb2 nvidia-drm.modeset=1
sddm.log tells :
[13:06:45.942] (II) DAEMON: Initializing...
[13:06:45.948] (II) DAEMON: Starting...
[13:06:45.949] (II) DAEMON: Logind interface found
(In reply to Christophe PEREZ from comment #17)
> I have the same problem with x11-misc/sddm-0.18.1-r1 after migrating to
> elogind yesterday (from consolekit).
Solved for me. I just had to manually (and add it in /etc/conf.d/modules) load nvidia-drm
I've been using this method for a while with several nvidia-driver versions and with sddm-0.18.1-r1 and sddm-0.18.1-r3 for a while now. I'm considering this issue resolved.