[gentoo-user] Login manager occasionally fails to show

[gentoo-user] Login manager occasionally fails to show

[Markus Gustafsson]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 905 bytes --]

Re: [gentoo-user] Login manager occasionally fails to show

[Peter Humphrey]

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.

Re: [gentoo-user] Login manager occasionally fails to show

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Login manager occasionally fails to show

[Markus Gustafsson]

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

Re: [gentoo-user] Login manager occasionally fails to show

[Michael]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

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?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Login manager occasionally fails to show

[Markus Gustafsson]

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

Re: [gentoo-user] Login manager occasionally fails to show

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Login manager occasionally fails to show

[Markus Gustafsson]

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

Re: [gentoo-user] Login manager occasionally fails to show

[Michael]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Login manager occasionally fails to show

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Login manager occasionally fails to show

[Alan Grimes]

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.