1. Forum
  2. Usenet
  3. LINUX.GENTOO.USER

  • [gentoo-user] Login manager occasionally fails to show

    From Markus Gustafsson@21:1/5 to All on Sat Jan 25 22:50:02 2025
    --be39aa23c11a4aec83e5eb43a224bf35
    Content-Type: text/plain
    Content-Transfer-Encoding: 7bit

    Hi!

    I've been running in to a problem on and off for the past year or so: when I boot my computer it won't always show a login screen (SDDM). The screen will remain dark without a signal. If I swap tty with ctrl+alt+F1 it will show me the boot log, with the
    last entry being "starting local" and letting me login through the terminal. I can then reboot and things will start up just fine. Interestingly it does say something about shutting down the display manager when I reboot in such instances...

    I feel like happens if I fail to start my monitor fast enough, but I'm not entirely sure. Could that be related?

    Any ideas?

    Best,
    Markus


    --be39aa23c11a4aec83e5eb43a224bf35
    Content-Type: text/html
    Content-Transfer-Encoding: 7bit

    <!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi!<br></div><div><br></div>I've been running in to a problem on and off for the past year or so: when I boot my computer it
    won't always show a login screen (SDDM). The screen will remain dark without a signal. If I swap tty with ctrl+alt+F1 it will show me the boot log, with the last entry being "starting local" and letting me login through the terminal. I can then reboot
    and things will start up just fine. Interestingly it does say something about shutting down the display manager when I reboot in such instances...<br><br>I feel like happens if I fail to start my monitor fast enough, but I'm not entirely sure. Could that
    be related?<br><br><div id="sig66218808">Any ideas?<br><br>Best,<br>Markus<br><div class="signature"><br></div></div><div><br></div></body></html>
    --be39aa23c11a4aec83e5eb43a224bf35--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Humphrey@21:1/5 to All on Sun Jan 26 12:20:01 2025
    On Saturday 25 January 2025 21:41:01 Greenwich Mean Time Markus Gustafsson wrote:
    Hi!

    I've been running in to a problem on and off for the past year or so: when I boot my computer it won't always show a login screen (SDDM). The screen
    will remain dark without a signal. If I swap tty with ctrl+alt+F1 it will show me the boot log, with the last entry being "starting local" and
    letting me login through the terminal. I can then reboot and things will start up just fine. Interestingly it does say something about shutting down the display manager when I reboot in such instances...

    I feel like happens if I fail to start my monitor fast enough, but I'm not entirely sure. Could that be related?

    You need your monitor on during startup; the system needs to read EDID from it to be able to drive it properly. That could be your problem.

    --
    Regards,
    Peter.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Sun Jan 26 12:33:28 2025
    On Sunday 26 January 2025 11:18:00 Greenwich Mean Time Peter Humphrey wrote:
    On Saturday 25 January 2025 21:41:01 Greenwich Mean Time Markus Gustafsson

    wrote:
    Hi!

    I've been running in to a problem on and off for the past year or so: when I boot my computer it won't always show a login screen (SDDM). The screen will remain dark without a signal. If I swap tty with ctrl+alt+F1 it will show me the boot log, with the last entry being "starting local" and letting me login through the terminal. I can then reboot and things will start up just fine. Interestingly it does say something about shutting
    down the display manager when I reboot in such instances...

    I feel like happens if I fail to start my monitor fast enough, but I'm not entirely sure. Could that be related?

    You need your monitor on during startup; the system needs to read EDID from it to be able to drive it properly. That could be your problem.

    After an SDDM update many months ago I started having SDDM problems similar to the OP. The SDDM display manager GUI would not launch at all - black screen. Or, it would launch, but then it would appear to not take my passwd to login. Or, it would seemingly login, but end up on a black screen with only a mouse cursor and no desktop. The problem was manifesting whether I was launching an X11 or Wayland desktop session. If I dropped into a console and restarted the display-manager service, then SDDM launched and worked normally. Following a reboot the problem of the non-functioning SDDM was present again.

    I tried configuring SDDM to use x11, x11-user and wayland (experimental) with kwin or weston compositor. I tried enabling/disabling TPM in the BIOS/kernel. Nothing made a difference. The logs were not very informative to help troubleshooting.

    This was only happening on one PC which has a new(er), faster CPU. All older and slower CPU PCs exhibited no such behaviour. I suspected the services were starting up too fast and either the haveged service didn't have enough time to generate the needed entropy for SDDM, or SDDM was clashing with some other service in the startup sequence.

    I tried adding some wait directive for the display-manager service, but when that did not work I added in /etc/rc.conf:

    rc_display_manager_after="local"

    to push the display-manager at the end of the queue. Although SDDM now takes
    a second longer than before to come up, at least SDDM starts and I am able to login normally.

    HTH.
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmeWK5gACgkQseqq9sKV ZxkaFA/+Ou6vYbnlPQZkTS9a29/yJjMFsWjClRW2TU6al6y+4UOmyeOPIm6NxFQ1 KgIQXy8I/a1xvtLIa9H8EBCELnCHJbqBuvwWUYBStgFzb8ccScx9SRY+hFx+5M6I VLQNc0HgA5pn3hGkB/YZlRdX2AOFpY0S3d7DBSHdXWTqyHZe0CL7x0pkAAFXQNEB Sageqr9MDu6SSXzheqtZAJZFo0eO2MtUQX24hTn2kbQyXGUum3lfun1Kt5157KnM 2LmIWMLl1x9O0k6lW0LXfMa86/uqbRMBUHaM2ph6naSyumFDA0k7QNGjydM/l22M rcl7iiNjXjs3y21PnO9MX89pSoH1CX0CzdKij+Z3/yqUQ1L7FSEYT/DF5FJgPQAa kJ2rDG8kvRCDy00/QeVBGgMtmAgko3FcefWIGwB4XVdaG/2fXUE6dvIf1qHgsA3Q n6QSgb9ZEiLcvGQesznlT0ys9d32VBt2cR2ZfycdyTGOn/K9X0bBokwm1iX/IcpB 6NKBMFYkeVbqttGTYTA0jknMAh6M5tgWW+8CD+Wr4PfeYG9GKpb4ryenyMDM/neb OAObgVAZNGDpbSiXBcIBp9+aeQECT6Ba3HpvgMx809uw1Fc6TKyi0snM2l3GUfRz suAtmDOY2VvKo8EZQkVk5gZUdX+swuWuRv2zmj7NjmSvu2IUd70=
    =0iE+
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Markus Gustafsson@21:1/5 to Michael on Wed Jan 29 22:30:01 2025
    Thanks for the input. I do indeed have a pretty new CPU as well.

    I did try the rc.conf trick but no luck after trying it once. I'll keep it around for a while and see if I can see an overall improvement.

    Regards,
    Markus

    On Sun, Jan 26, 2025, at 13:33, Michael wrote:
    On Sunday 26 January 2025 11:18:00 Greenwich Mean Time Peter Humphrey wrote:
    On Saturday 25 January 2025 21:41:01 Greenwich Mean Time Markus Gustafsson >>
    wrote:
    Hi!

    I've been running in to a problem on and off for the past year or so: when >> > I boot my computer it won't always show a login screen (SDDM). The screen >> > will remain dark without a signal. If I swap tty with ctrl+alt+F1 it will >> > show me the boot log, with the last entry being "starting local" and
    letting me login through the terminal. I can then reboot and things will >> > start up just fine. Interestingly it does say something about shutting
    down the display manager when I reboot in such instances...

    I feel like happens if I fail to start my monitor fast enough, but I'm not >> > entirely sure. Could that be related?

    You need your monitor on during startup; the system needs to read EDID from >> it to be able to drive it properly. That could be your problem.

    After an SDDM update many months ago I started having SDDM problems similar to
    the OP. The SDDM display manager GUI would not launch at all - black screen. Or, it would launch, but then it would appear to not take my passwd to login. Or, it would seemingly login, but end up on a black screen with only a mouse cursor and no desktop. The problem was manifesting whether I was launching an
    X11 or Wayland desktop session. If I dropped into a console and restarted the
    display-manager service, then SDDM launched and worked normally. Following a reboot the problem of the non-functioning SDDM was present again.

    I tried configuring SDDM to use x11, x11-user and wayland (experimental) with kwin or weston compositor. I tried enabling/disabling TPM in the BIOS/kernel.
    Nothing made a difference. The logs were not very informative to help troubleshooting.

    This was only happening on one PC which has a new(er), faster CPU. All older and slower CPU PCs exhibited no such behaviour. I suspected the services were
    starting up too fast and either the haveged service didn't have enough time to
    generate the needed entropy for SDDM, or SDDM was clashing with some other service in the startup sequence.

    I tried adding some wait directive for the display-manager service, but when that did not work I added in /etc/rc.conf:

    rc_display_manager_after="local"

    to push the display-manager at the end of the queue. Although SDDM now takes a second longer than before to come up, at least SDDM starts and I am able to login normally.

    HTH.
    Attachments:
    * signature.asc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Thu Jan 30 08:06:51 2025
    On Wednesday 29 January 2025 21:19:50 Greenwich Mean Time Markus Gustafsson wrote:
    Thanks for the input. I do indeed have a pretty new CPU as well.

    I did try the rc.conf trick but no luck after trying it once. I'll keep it around for a while and see if I can see an overall improvement.

    Regards,
    Markus

    If your SDDM problem were the same as mine, then my solution would have an immediate and permanent effect. Have you looked at:

    ~/.local/share/sddm/xorg-session.log

    or,

    ~/.local/share/sddm/wayland-session.log

    and

    /var/log/sddm.log

    for any hints pointing to the cause of this?
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmebMxsACgkQseqq9sKV Zxm/WhAAvCedutlDeGzI0QIoMLkO/ne77Fvcr1RAC93hshXoxcPad8FiRWauUtPH GolwDJk6RROvUAvOiRIP8NmR1ebfdfl2mjoXV+0yyXb1jHE8jL0pprUVZJft3SNi IHKN36am1FK9YCEGsWlQXSZ9iy/bp878y28MKmajMiAzxqIJ0smTI0/mc06ZJXtc zRp4DM3i98skkE+SVGLUXIntUjL5CIRztBtZK7owELoPyb0f8LpAygTWrLWezkWt cXWWRgQH3sIi7pJVmPwCnacCw0ciCzlHy5fI4ESto03+8107JsgjZrP+CBhgctlZ iyUAhyYSmsW3xd5MRYRKX2X6T6oOjE6aHhy+G2bsmUdq8MMGysAj209lmCHq5iMT JKPEmQniPAhBaQB/GnNt6WWOwLIXXPMpduEIlp8TsBcKTiwky2ompGhLdW89MY03 8vjurVvdOtKG6Pw7idKiyETcujG25oVL+wwwMUic8QRdkbYuAokiBbHgBIEiZxIb kHJh+hX8du04Sl9Ri5F/h6rZt8UaPAnTB+z6pgazPX8ZMVHKpzg7nKz8KJ7mxtib 1TCvP9JG8LHsWVb0+2aBZL1+C2eEXPFil6Q4eFHhwkzXZ2Ow8GQmeBwDdbmRKyRU Fz/FxNYRIUQyE3PE0FJjOnxTLhhDb3nuYX6n7s2qbpjD3IDOrso=
    =g6Tl
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Markus Gustafsson@21:1/5 to Michael on Sun Feb 2 12:20:01 2025
    This is my /var/log/sddm.log from an unsuccessful upstart:

    [11:57:20.087] (II) DAEMON: Initializing...
    [11:57:20.090] (II) DAEMON: Starting...
    [11:57:20.090] (II) DAEMON: Logind interface found
    [11:57:20.091] (II) DAEMON: Adding new display...
    [11:57:20.091] (II) DAEMON: Loaded empty theme configuration
    [11:57:20.092] (II) DAEMON: Xauthority path: "/run/sddm/xauth_LWFoRx" [11:57:20.092] (II) DAEMON: Using VT 7
    [11:57:20.092] (II) DAEMON: Display server starting...
    [11:57:20.092] (II) DAEMON: Writing cookie to "/run/sddm/xauth_LWFoRx" [11:57:20.092] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt7 -auth /run/sddm/xauth_LWFoRx -noreset -displayfd 16
    [11:57:21.377] (II) DAEMON: Setting default cursor
    [11:57:21.394] (II) DAEMON: Running display setup script "/usr/share/sddm/scripts/Xsetup"
    [11:57:21.395] (II) DAEMON: Display server started.
    [11:57:21.395] (II) DAEMON: Socket server starting...
    [11:57:21.395] (II) DAEMON: Socket server started.
    [11:57:21.395] (II) DAEMON: Loaded empty theme configuration
    [11:57:21.396] (II) DAEMON: Greeter starting...
    [11:57:21.406] (II) HELPER: [PAM] Starting...
    [11:57:21.406] (II) HELPER: [PAM] Authenticating...
    [11:57:21.406] (II) HELPER: [PAM] returning.
    [11:57:21.425] (II) HELPER: Writing cookie to "/tmp/xauth_ocMfUA" [11:57:21.425] (II) HELPER: Starting X11 session: "" "/usr/bin/sddm-greeter-qt6 --socket /tmp/sddm-:0-lMuEWF"
    [11:57:21.426] (II) DAEMON: Greeter session started successfully [11:57:21.468] (II) DAEMON: Message received from greeter: Connect

    I think it looks pretty much the same as for a successful one...

    I peeked into ~/.local/share/sddm/wayland-session.log as well, but I got the impression that this starts getting written later (after having logged in)?

    Regards,
    Markus

    On Thu, Jan 30, 2025, at 09:06, Michael wrote:
    On Wednesday 29 January 2025 21:19:50 Greenwich Mean Time Markus Gustafsson wrote:
    Thanks for the input. I do indeed have a pretty new CPU as well.

    I did try the rc.conf trick but no luck after trying it once. I'll keep it >> around for a while and see if I can see an overall improvement.

    Regards,
    Markus

    If your SDDM problem were the same as mine, then my solution would have an immediate and permanent effect. Have you looked at:

    ~/.local/share/sddm/xorg-session.log

    or,

    ~/.local/share/sddm/wayland-session.log

    and

    /var/log/sddm.log

    for any hints pointing to the cause of this?
    Attachments:
    * signature.asc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Sun Feb 2 13:11:00 2025
    On Sunday 2 February 2025 11:09:09 Greenwich Mean Time Markus Gustafsson
    wrote:
    This is my /var/log/sddm.log from an unsuccessful upstart:
    [11:57:20.087] (II) DAEMON: Initializing...
    [11:57:20.090] (II) DAEMON: Starting...
    [11:57:20.090] (II) DAEMON: Logind interface found
    [11:57:20.091] (II) DAEMON: Adding new display...
    [11:57:20.091] (II) DAEMON: Loaded empty theme configuration
    [11:57:20.092] (II) DAEMON: Xauthority path: "/run/sddm/xauth_LWFoRx" [11:57:20.092] (II) DAEMON: Using VT 7
    [11:57:20.092] (II) DAEMON: Display server starting...
    [11:57:20.092] (II) DAEMON: Writing cookie to "/run/sddm/xauth_LWFoRx" [11:57:20.092] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt7 -auth /run/sddm/xauth_LWFoRx -noreset -displayfd 16 [11:57:21.377] (II) DAEMON: Setting default cursor
    [11:57:21.394] (II) DAEMON: Running display setup script "/usr/share/sddm/scripts/Xsetup" [11:57:21.395] (II) DAEMON: Display
    server started.
    [11:57:21.395] (II) DAEMON: Socket server starting...
    [11:57:21.395] (II) DAEMON: Socket server started.
    [11:57:21.395] (II) DAEMON: Loaded empty theme configuration
    [11:57:21.396] (II) DAEMON: Greeter starting...
    [11:57:21.406] (II) HELPER: [PAM] Starting...
    [11:57:21.406] (II) HELPER: [PAM] Authenticating...
    [11:57:21.406] (II) HELPER: [PAM] returning.
    [11:57:21.425] (II) HELPER: Writing cookie to "/tmp/xauth_ocMfUA" [11:57:21.425] (II) HELPER: Starting X11 session: "" "/usr/bin/sddm-greeter-qt6 --socket /tmp/sddm-:0-lMuEWF" [11:57:21.426] (II) DAEMON: Greeter session started successfully
    [11:57:21.468] (II) DAEMON: Message received from greeter: Connect

    I think it looks pretty much the same as for a successful one...

    There's more happening after this stage with a successful login.

    The daemon will register a login received from the greeter and the helper will negotiate authentication for the desktop session with PAM, then the helper
    will launch a X11 or Wayland desktop session. However, if you have no GUI display coming up to enter your password, the process will stop where you have arrived at above.

    Have you set up your haveged service to start at boot?

    I don't know if enabling any crypto co-processors available on the MoBo or CPU in the BIOS and in your kernel may make a difference. My SDDM problem was related to having enough entropy available when SDDM was launching too soon in the boot up process.


    I peeked into ~/.local/share/sddm/wayland-session.log as well, but I got the impression that this starts getting written later (after having logged in)?

    Yes, this would take place once a desktop session has been set up. I can't recall if you may see some errors in there in cases when SDDM does not
    shutdown and crashes.
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmefbuQACgkQseqq9sKV ZxnfbRAAxUO/bR72OhJ0CYfsZZSumQ9sDVje0hctQQmP6HSLUbv2JsjgGRW4gkmB KKer6U4JcQqGrUEIl7yapzJPFR3GiyKTYQZWJKMyQJGzpXUpW2OiG1XsjNOrWl+O uP3T0jxkGN8oGDAj3zuepojKRY+gd/PmqBU4sl10MfPYQLzW64Yn70YRNZtJ3ryK MvxHLh0ijPyDD8/vBVJih/iDTN23HFLXrNEfJgXQZgqVkPizm9cn3o3o3gNjKYk3 3D1HcQrmy471acVAHKAgox+P3aT7RSDHqHnRgTQWCK9PM+cVaaMy/UXY/w3jnhy7 jM5qlWlj1iRg6TCtTGwLfvX/7xlb1wFr9jKxUejBLgSxuwkKNZmNoQhyfDo8Q+/s QtxgwY/QeoHq26SnGkOLD9KTOhO+HfuyU1PXVKsxcvR9gJqb2Ep6D+aNaeLlUoKO ZHs5s0f/Ye1zoLDjtWts3KDRkuD2rCtSR6ouU2XE4e/o7CgiH0UOG15i/UvxvMH/ VU6gVrOLtpdd8gv/rgT3WvengetQfd+B9h9vu+IinjWIM95wDv1cCj1vR5SrARhh xFh+4QvJvw1nopth0gaNhBQpKX3EldXkKSb6ZA0u3oIMfDgxrS4pPvEmBmxUmEWE DFHyixTl4/fAdQ3fHj/eNN5U4yY0aRGxN7NRQuAF4TcK1xKQiQ4=
    =ePxA
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Markus Gustafsson@21:1/5 to Michael on Fri Feb 7 22:10:01 2025
    I don't run haveged, but I think you might be on to something regarding the entropy... Googling around shows a lot of people having similar issues. I'm gonna try out haveged and see if it improved the situation.

    On Sun, Feb 2, 2025, at 14:11, Michael wrote:
    On Sunday 2 February 2025 11:09:09 Greenwich Mean Time Markus Gustafsson wrote:
    This is my /var/log/sddm.log from an unsuccessful upstart:
    [11:57:20.087] (II) DAEMON: Initializing...
    [11:57:20.090] (II) DAEMON: Starting...
    [11:57:20.090] (II) DAEMON: Logind interface found
    [11:57:20.091] (II) DAEMON: Adding new display...
    [11:57:20.091] (II) DAEMON: Loaded empty theme configuration
    [11:57:20.092] (II) DAEMON: Xauthority path: "/run/sddm/xauth_LWFoRx"
    [11:57:20.092] (II) DAEMON: Using VT 7
    [11:57:20.092] (II) DAEMON: Display server starting...
    [11:57:20.092] (II) DAEMON: Writing cookie to "/run/sddm/xauth_LWFoRx"
    [11:57:20.092] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background >> > none -seat seat0 vt7 -auth /run/sddm/xauth_LWFoRx -noreset -displayfd 16 >> > [11:57:21.377] (II) DAEMON: Setting default cursor
    [11:57:21.394] (II) DAEMON: Running display setup script
    "/usr/share/sddm/scripts/Xsetup" [11:57:21.395] (II) DAEMON: Display
    server started.
    [11:57:21.395] (II) DAEMON: Socket server starting...
    [11:57:21.395] (II) DAEMON: Socket server started.
    [11:57:21.395] (II) DAEMON: Loaded empty theme configuration
    [11:57:21.396] (II) DAEMON: Greeter starting...
    [11:57:21.406] (II) HELPER: [PAM] Starting...
    [11:57:21.406] (II) HELPER: [PAM] Authenticating...
    [11:57:21.406] (II) HELPER: [PAM] returning.
    [11:57:21.425] (II) HELPER: Writing cookie to "/tmp/xauth_ocMfUA"
    [11:57:21.425] (II) HELPER: Starting X11 session: ""
    "/usr/bin/sddm-greeter-qt6 --socket /tmp/sddm-:0-lMuEWF" [11:57:21.426]
    (II) DAEMON: Greeter session started successfully
    [11:57:21.468] (II) DAEMON: Message received from greeter: Connect

    I think it looks pretty much the same as for a successful one...

    There's more happening after this stage with a successful login.

    The daemon will register a login received from the greeter and the helper will
    negotiate authentication for the desktop session with PAM, then the helper will launch a X11 or Wayland desktop session. However, if you have no GUI display coming up to enter your password, the process will stop where you have
    arrived at above.

    Have you set up your haveged service to start at boot?

    I don't know if enabling any crypto co-processors available on the MoBo or CPU
    in the BIOS and in your kernel may make a difference. My SDDM problem was related to having enough entropy available when SDDM was launching too soon in
    the boot up process.


    I peeked into ~/.local/share/sddm/wayland-session.log as well, but I got the >> impression that this starts getting written later (after having logged in)?

    Yes, this would take place once a desktop session has been set up. I can't recall if you may see some errors in there in cases when SDDM does not shutdown and crashes.
    Attachments:
    * signature.asc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Sat Feb 8 10:02:55 2025
    On Friday 7 February 2025 20:56:00 Greenwich Mean Time Markus Gustafsson
    wrote:
    I don't run haveged, but I think you might be on to something regarding the entropy... Googling around shows a lot of people having similar issues. I'm gonna try out haveged and see if it improved the situation.

    You need some way to generate/accumulate enough entropy in your system before SDDM is launched. Please read the 'Troubleshooting' section on the wiki page for SDDM, which mentions entropy as the first thing to check:

    https://wiki.gentoo.org/wiki/SDDM#Troubleshooting

    Hopefully, depending on your system, haveged should do the trick.
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmenK88ACgkQseqq9sKV ZxmwgxAAg/5Hkqf8GSNOsqskfFvBPMIyvJbVgVRTHEqbNC5RLkr084mhAPjr7Ytr GS3bATaFsh8sdrjEUIHp9Y+fb7gmwdzgzwQtrWp9Db1y7vbVQK299dJFWw8YJiqL IKwTHhxHCrFpGgStNqpP52EnIVh+2zgJ+PKeY/n3rOB5rNhTXx6f4qXoZoNAlOND ZiSVXFK+I4wTCjQPsTOStaleplksfO7/XPpUmY5u9HVK0DISItFWcGJrjSWH5q57 l64Rsqg+lmKY4FrcOh200Lc80QT5zwy2IDtdUXai1V8mWZzb1Kgg92ZQz6H9wfoM imyozDfv5kBjDfr1k1guc5+w+CiOQs+49Jj+d20qV5YdoyNqUWq66xl8NsxXtslT WW9I80y3S5PQzM4e5pEbZavuxSGDv64uMdpEPz0mO4p4k+tzCt/1CUHIRFfseonc amCuTw6b4Bph8r7wkNNKanM24H08j7fG79QDQXaRTsfeCJX2iMZ5mm2ZrYyeAsIA aRZvCWOWYILLgQVqNs+Da6IZyqehtr3xButaVggeg735jZXgki6FwUFBDrXH/guF gjZf3QDnCkLD4XJ4AyNX7woq4ICJzdkpodLQ/y1vtFLP1RRJMyHuq3BxAk7thCVK 2fp9d5OoWDN1ze45uLyBIXCeihUVGd361s67ZOlOD4GyEntPJtU=
    =Dd4I
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Sat Feb 8 11:02:22 2025
    On Saturday 8 February 2025 10:02:55 Greenwich Mean Time Michael wrote:
    On Friday 7 February 2025 20:56:00 Greenwich Mean Time Markus Gustafsson

    wrote:
    I don't run haveged, but I think you might be on to something regarding
    the
    entropy... Googling around shows a lot of people having similar issues.
    I'm
    gonna try out haveged and see if it improved the situation.

    You need some way to generate/accumulate enough entropy in your system
    before SDDM is launched. Please read the 'Troubleshooting' section on the wiki page for SDDM, which mentions entropy as the first thing to check:

    https://wiki.gentoo.org/wiki/SDDM#Troubleshooting

    Hopefully, depending on your system, haveged should do the trick.

    Another thing to consider, is the CPU or MoBo security chip crypto-processor. On recent CPUs/MoBos this co-processor functionality will need to be switched on at the BIOS menu and any associated modules in the OS kernel enabled.
    Their functionality is necessary in generating and storing entropy in a timely fashion.
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmenOb4ACgkQseqq9sKV ZxnSqw/8DloAFoQeL+YU5uCjMEO2Z6dH7oKpH09hCUeRcYFVku0JDTt/1rSyTz3W HdJF7O5FWYIAi4VUAJhR04Dq+/Aju1Z03pTuqKwSumSF1Ouv8DSnxr0hCJLi+Wxl 34PptpP2SuICisrDgwk4PVlTzPv8nrt8imUKbfpA+fRJS364ks3ScK6oNG6ZW5TQ DRy15D6d+ADYOqacdjN4GmStrkiC9hsjNyMlsXkgnPjxsIeWGdJlggktWMXChC6M Ojn82D+a7ooSkiK4p198Ky8b3z8lcESn2rBDNplk3mjHcjrtEXIq9oTdXD5iY00S xx3uJDCO1VvVmlVYW91sJdi0jc+HwWYHu328T1utVGV30hDAaKcaI0v11PJ9dWqW W7ytxuhwyCcaMljW+LvEFpiL7dAxesV890lnzF9OaMu+ko+xMkLR+F2bx8j9H/Ov Uye54PAPtbInyE5iqsFUcqy3Ep4CyH+gZxMNe6N6IIogHr9JXFXbKjgbRMtP/EXL lgWPbAJf2D82AF6AOcvus4BCDv67RtOieoy4b6/1648ykNNLNgUtrbGZo9OHzjqM PXlC047TIPCU0/+bDduqFJmv7kIjdGhkDFRLNV7X/nDpd5y+kr3iTn8OPhz5EQ6i /crrsdZekPQyTlf7DPwGkqJ3BzGibHPmaTWgkZhbceMhYlb0I74=
    =zNP6
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alan Grimes@21:1/5 to All on Tue Feb 11 18:30:01 2025
    Login manager?!?!?!!? Are you nuts?! I mean it almost makes sense as a
    concept but X11 is inherently unreliable and cannot be trusted to work
    at system bootup, the only solution is to boot to text mode, log in, and
    then start x11 (with the opportunity to switch to a secondary vterm and
    solve whatever issues crop up...). I have never attempted to use
    anything other than simple text-mode login in the last 20 years, and
    then when the system is up, just run it for several months without ever
    turning it off or making any change. I'm currently 51 days into a run
    without any attempt at system maintenence. The only issue I have is that
    the CPU frequency manager likes to clock my CPU down to about 550 mhz
    making the system unusably unresponsive despite low CPU temps and high
    load average. =\ I changed a kernel setting for user-space frequency
    management but have been too lazy to reboot.

    --
    You can't out-crazy a Democrat.
    #EggCrisis #BlackWinter
    White is the new Kulak.
    Powers are not rights.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)