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 doesn't start on after load system #1036

Open
SparrowA opened this issue May 31, 2018 · 15 comments

Comments

@SparrowA
Copy link

@SparrowA SparrowA commented May 31, 2018

After load system sddm doesn't start, only when I go to tty2 and login in sddm'll start automatically.
I used sddm-0.17.0-5 and execute systemctl enable sddm.service

@michaelfranzl

This comment has been minimized.

Copy link

@michaelfranzl michaelfranzl commented Jun 14, 2018

I've got the same issue on Debian Testing, on 2 different laptops: sddm not starting, only the tty1 login is on the screen. Login on tty2 and typing there also starts sddm with a bit of delay.

It doesn't seem to be an issue of sddm though. I installed lightdm, which starts immediately. But then KDE on Wayland would behave the same, not starting. It seems that one of the Wayland components waits for a number of keyboard events. If I keep the Enter key pressed, which generates a lot of keyboard events, it consistently starts sddm / KDE.

@Hoshpak

This comment has been minimized.

Copy link

@Hoshpak Hoshpak commented Jun 15, 2018

I experienced similar issues starting with kernel 4.16.4. Between 4.16.3 and 4.16.4 some CVE regarding the random number generator was fixed which changed the initialization of it. It seems to me that sddm for some reason waits until the random number generator is fully initialized. The pressing of keys on the keyboards generates additional entropy and allows the random number generator to be initialized faster also accelerating the startup of sddm.

I wonder why sddm needs random numbers to start, is it needed for some kind of security feature or an unintentional functionality pulled in by qt?

Edit: This was the commit I found doing bisect on linux-stable:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.16.y&id=cd8d7a5778a4abf76ee8fe8f1bfcf78976029f8d

Edit2: Perhaps it's related to the use of std::random in src/daemon/XorgDisplayServer.cpp and src/daemon/Utils.h. I found the following two articles regarding this topic:

http://www.pcg-random.org/posts/cpps-random_device.html
http://www.pcg-random.org/posts/simple-portable-cpp-seed-entropy.html

I will check that theory later by changing the seeding mechanism and recompiling sddm on one of my affected systems.

@michaelfranzl

This comment has been minimized.

Copy link

@michaelfranzl michaelfranzl commented Jun 15, 2018

@Hoshpak I think you are onto something with the entropy collection. I just confirmed that moving the mouse will also start sddm (after about 3 seconds of moving the mouse).

@Hoshpak

This comment has been minimized.

Copy link

@Hoshpak Hoshpak commented Jun 15, 2018

I patched the two files I mentioned above to use a static initialization value instead of std::random but it din't improve the situation so that doesn't seem to be the cause of the issue. strace shows me a getrandom call during startup of sddm which would explain the issue since getrandom is blocking by default.

However I couldn't find any getrandom calls throughout the sddm code base so it seems that it comes from a library that is used by sddm.

@michaelfranzl

This comment has been minimized.

Copy link

@michaelfranzl michaelfranzl commented Jun 15, 2018

@Hoshpak It might not be a problem with sddm. Try the following: Use lightdm as a display manager. It always starts immediately. But then, a KDE Plasma session (version 5:102 on my Debian Testing) started by lightdm exhibits the same startup delay as sddm, which can be shortened by generating a certain number of keyboard or mouse events (I always hold Ctrl pressed). Because of that, the culprit might be what is common between sddm and KDE (could it be Wayland)?

@Hoshpak

This comment has been minimized.

Copy link

@Hoshpak Hoshpak commented Jun 15, 2018

@michaelfranzl I think we can rule out wayland simply because I'm not using it. My current desktop environment is LXQt which doesn't support wayland yet and sddm also starts with xorg on my computer. The obvious common dependency of both KDE and sddm would be Qt but that in turn depends on other libraries as well. Somewhere in there there seems to be a piece of code that calls getrandom().

@piotr-dobrogost

This comment has been minimized.

Copy link

@piotr-dobrogost piotr-dobrogost commented Jul 9, 2018

Related: issue #652 (SDDM/Plasma 5.x Screen Refresh Issue On Lock->Login) also talks about hanging due to too low entropy.

@shmerl

This comment has been minimized.

Copy link

@shmerl shmerl commented Jul 19, 2018

Installing something like rng-tools5 works around this, since it uses existing TPM or CPU's rdrand feature to increase system entropy.

@fancywriter

This comment has been minimized.

Copy link

@fancywriter fancywriter commented Nov 8, 2018

@Hoshpak, I have exactly the same issue on kernel gentoo-sources-4.19.1. Could it be a bug inside linux kernel? or qt? or sddm itself?

Little interesting funny fact - it wasn't reproduced until I have replaced HDD with SSD. May be the old HDD was noisy enough to create a lot of needed entropy? Anyway, I 100% doubt that display manager need really random number, I am ok with pseudo-random...

fancywriter referenced this issue Nov 8, 2018
A step forward for a display server agnostic sddm.
With Wayland support coming soon we want display server specific code
not scattered all over the place.
@SparrowA

This comment has been minimized.

Copy link
Author

@SparrowA SparrowA commented Nov 19, 2018

I found out how fix it. I have used havegen , and it solve my problem.

@fancywriter

This comment has been minimized.

Copy link

@fancywriter fancywriter commented Nov 19, 2018

@SparrowA this is more workaround than fix, the proper fix is to improve usage of random device to not rely of lack on entropy when it is not needed.

@strohel

This comment has been minimized.

Copy link

@strohel strohel commented Mar 28, 2019

At least on my system, the issue happens if and only if kernel config option RANDOM_TRUST_CPU is unset.

That should be the simplest "solution", other suggested ones seem to be just more complicated ways of filling in the initial source of entropy (kernel itself will use platform-specific instructions like RdRand to source it if RANDOM_TRUST_CPU is set).

See e.g. https://lwn.net/Articles/760584/ for background info. Note that similar problem has also affected some early-boot Python programs: https://lwn.net/Articles/693189/

@equaeghe

This comment has been minimized.

Copy link

@equaeghe equaeghe commented Mar 28, 2019

At least on my system, the issue happens if and only if kernel config option RANDOM_TRUST_CPU is unset.

That should be the simplest "solution", other suggested ones seem to be just more complicated ways of filling in the initial source of entropy (kernel itself will use platform-specific instructions like RdRand to source it if RANDOM_TRUST_CPU is set).

This only works for recent enough CPUs. That kernel option has no effect, e.g., on Sandy Bridge CPUs. The haveged workaround should be universal.

@shmerl

This comment has been minimized.

Copy link

@shmerl shmerl commented Mar 28, 2019

Or you can use rng-tools5 where it works.

@ishitatsuyuki

This comment has been minimized.

Copy link

@ishitatsuyuki ishitatsuyuki commented Oct 23, 2019

From LWN:

Ahmed S. Darwish reported the original problem and tracked it down to the GNOME Display Manager (GDM), which handles graphical logins. It turns out that GDM was calling getrandom() in order to generate the "MIT magic cookie" that is used for authorization by the X Window System.

Related?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.