Mailing List Archive

On 4/3/24 2:29 PM, Markus Gustafsson wrote:
> Hi,
>
> I'm having a problem I'm not quite sure how to tackle: every other
> startup or so results in a black screen. Usually nothing gets printed
> (no bios splash, not GRUB menu, no OpenRC prints), and the monitor
> goes to low power mode after a while (I haven't quite confirmed if
> this is actually the case, or if everything happens before my monitor
> have actually stated, but I'd expect the GRUB menu would hang long
> enough for it to do so).
>
> However, it does wake up if I switch to another TTY (e.g. ctrl+alt+F4)
> and lets me log on, so it has obviously booted up. If I switch back to
> TTY 8 from there it just shows a blinking cursor (i.e. not SDDM, which
> is what I'd expect). If I reboot from the TTY that lets me log on, the
> boot process is usually normal and leaves me at the SDDM login.
>
> Any tips on how to debug this would be much appreciated.
Are you certain it hasn't started on some TTY other than 8?  I always
start out on TTY1, although I start up text only, no SDDM. However, I do
have a very vague memory of something similar, and I believe it was that
I needed to change one of the kernel FB related settings.  Sorry not be
have more concrete suggestions.

>However, it does wake up if I switch to another TTY (e.g. ctrl+alt+F4) and lets me log on, so it has obviously booted up. If I switch back to TTY 8 from there it just shows a blinking cursor (i.e. not SDDM, which is what I'd expect). If I reboot from the TTY that lets me log on, the boot process is usually normal and leaves me at the SDDM login.
>
>Any tips on how to debug this would be much appreciated.

Since you can switch ttys, this means your computer “properly” booted. So as
far as we know, the only culprit is your login manager which failed to start,
or started improperly.

For starters you could check, once logged in, if it is actually running or not.

ps faux | less

will output the whole list of processes on your computer, check it to see if
you can find sddm in the list.

If not, then it failed to start, so you want to check if the service in charge
to start it has been run.

rc-service sddm status # for openrc
systemctl status sddm # for systemd

These commands should tell you if the process has been started and failed, or
if it never started in the first place. If it started and failed, search for
logs, or even try to start it manually. This will give you indications as to
why it won’t run.

Otherwise, if it was never run by your service manager, this means something
earlier in the dependency tree failed to run. Same solution here: search for
logs, `rc-status` will give you the list of running services on your computer
and their state for openrc.

Good luck,
Hoël

Hoël Bézier wrote:
>> However, it does wake up if I switch to another TTY (e.g.
>> ctrl+alt+F4) and lets me log on, so it has obviously booted up. If I
>> switch back to TTY 8 from there it just shows a blinking cursor (i.e.
>> not SDDM, which is what I'd expect). If I reboot from the TTY that
>> lets me log on, the boot process is usually normal and leaves me at
>> the SDDM login.
>>
>> Any tips on how to debug this would be much appreciated.
>
> Since you can switch ttys, this means your computer “properly” booted.
> So as far as we know, the only culprit is your login manager which
> failed to start, or started improperly.
>
> For starters you could check, once logged in, if it is actually
> running or not.
>
>   ps faux | less
>
> will output the whole list of processes on your computer, check it to
> see if you can find sddm in the list.
> If not, then it failed to start, so you want to check if the service
> in charge to start it has been run.
>
>   rc-service sddm status # for openrc
>   systemctl status sddm # for systemd
>
> These commands should tell you if the process has been started and
> failed, or if it never started in the first place. If it started and
> failed, search for logs, or even try to start it manually. This will
> give you indications as to why it won’t run.
>
> Otherwise, if it was never run by your service manager, this means
> something earlier in the dependency tree failed to run. Same solution
> here: search for logs, `rc-status` will give you the list of running
> services on your computer and their state for openrc.
>
> Good luck,
> Hoël


He could also do a:

ps aux | grep sddm

and see if it lists it.  Replace sddm if using something else. 

I'm not sure why but sometimes on my system, the GUI part is on 4.  I
once found it on 2.  Most of the time it is on 7 but sometimes, I find
it in other places.  4 is the most common alternative.  You may want to
cycle through ctrl alt F2 through F9 and see if it just parked itself
somewhere else for some crazy reason.  If you find it moves, we have a
common problem.  Most often it is on 7 where it should be but sometimes
I have to go hunting for the thing.

I've often wondered why it was in the wrong place.  I just figure as
long as I can find it, better not complain to much.  LOL 

Dale

:-)  :-) 

On 03/04/2024 19:53, Jack wrote:
> Are you certain it hasn't started on some TTY other than 8?  I always
> start out on TTY1, although I start up text only, no SDDM. However, I do
> have a very vague memory of something similar, and I believe it was that
> I needed to change one of the kernel FB related settings.  Sorry not be
> have more concrete suggestions.

My system isn't configured to switch ttys on - that's something I need
to investigate and enable. So sddm always starts on 2, with 1 being the
console output. When I switch user, it switches to 1 and starts the new
user there.

sddm will always start on the first available number, which with no ttys
is why it's 2 on my system.

Cheers,
Wol

On Wednesday, 3 April 2024 19:29:11 BST Markus Gustafsson wrote:
> Hi,
>
> I'm having a problem I'm not quite sure how to tackle: every other startup
> or so results in a black screen. Usually nothing gets printed (no bios
> splash, not GRUB menu, no OpenRC prints), and the monitor goes to low power
> mode after a while (I haven't quite confirmed if this is actually the case,
> or if everything happens before my monitor have actually stated, but I'd
> expect the GRUB menu would hang long enough for it to do so).

You can increase the GRUB timeout to a longer interval, but if this an
intermittent phenomenon it is probably related to hardware. Check your cable
and replace it if possible, or use an alternative port (DP/HDMI/DVI).


> However, it does wake up if I switch to another TTY (e.g. ctrl+alt+F4) and
> lets me log on, so it has obviously booted up. If I switch back to TTY 8
> from there it just shows a blinking cursor (i.e. not SDDM, which is what
> I'd expect). If I reboot from the TTY that lets me log on, the boot process
> is usually normal and leaves me at the SDDM login.

As others have mentioned sddm now starts in the first available tty, normaly
on VT2. However, some users/PCs appear to have problems with more recent sddm
versions, whereby the sddm-greeter fails to start, or fails to login into a
desktop:

https://bugs.gentoo.org/913862

> Any tips on how to debug this would be much appreciated.

Check the output on /var/log/ssdm when this problem manifests.

Hi again,

I tried to catch the error again and while doing so I realized you guys are of course correct: sddm usually starts on tty 2. I don't know why I got it into my head that it would start on tty 8. Anyway, when I finally got it to reproduce (took a few restarts) I didn't get a blinking cursor on tty 2, the monitor just goes to sleep (kind of like it does when it has no signal). Switching to tty 1 showed me the init log and let me log on so I could run the commands suggested earlier in this thread:

> $ ps aux | grep sddm
> root 2253 0.0 0.0 142408 14248 ? Ssl 06:26 0:00 /usr/bin/sddm
> root 2300 0.2 0.2 1653332 89588 ? Ssl 06:26 0:00 /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_UanezA -noreset -displayfd 16
> root 2358 0.0 0.0 61872 14024 ? S 06:26 0:00 /usr/libexec/sddm-helper --socket /tmp/sddm-auth-49123ec6-075d-4982-860d-ea1de56059ca --id 2 --start /usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV --user sddm --greeter
> sddm 2359 0.0 0.4 1557540 135804 ? Sl 06:26 0:00 /usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV
> sddm 2365 0.0 0.0 4320 1892 ? S 06:26 0:00 dbus-launch --autolaunch d3bb17ba0dc5f70ad177e3f764fe168e --binary-syntax --close-stderr
> sddm 2366 0.0 0.0 4620 224 ? Ss 06:26 0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session

> $ rc-service sddm status
> * rc-service: service `sddm' does not exist

This is what the command yields for a successful startup as well though. Should 'sddm' perhaps be 'display-manager' in the command above? Anyway:

> rc-status
> Runlevel: default
> sysklogd [ started ]
> dhcpcd [ started ]
> dbus [ started ]
> netmount [ started ]
> chronyd [ started ]
> cupsd [ started ]
> switcheroo-control [ started ]
> display-manager [ started ]
> numlock [ started ]
> local [ started ]
> Dynamic Runlevel: hotplugged
> Dynamic Runlevel: needed/wanted
> display-manager-setup [ started ]
> avahi-daemon [ started ]
> Dynamic Runlevel: manual

This is also what it looks like for a successful startup.

And finally from /var/log/sddm.log:

> [06:26:03.740] (II) DAEMON: Initializing...
> [06:26:03.743] (II) DAEMON: Starting...
> [06:26:03.743] (II) DAEMON: Logind interface found
> [06:26:03.743] (II) DAEMON: Adding new display...
> [06:26:03.744] (II) DAEMON: Loaded empty theme configuration
> [06:26:03.744] (II) DAEMON: Xauthority path: "/run/sddm/xauth_UanezA"
> [06:26:03.744] (II) DAEMON: Using VT 2
> [06:26:03.744] (II) DAEMON: Display server starting...
> [06:26:03.744] (II) DAEMON: Writing cookie to "/run/sddm/xauth_UanezA"
> [06:26:03.744] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_UanezA -noreset -displayfd 16
> [06:26:04.993] (II) DAEMON: Setting default cursor
> [06:26:05.010] (II) DAEMON: Running display setup script "/usr/share/sddm/scripts/Xsetup"
> [06:26:05.012] (II) DAEMON: Display server started.
> [06:26:05.012] (II) DAEMON: Socket server starting...
> [06:26:05.012] (II) DAEMON: Socket server started.
> [06:26:05.012] (II) DAEMON: Loaded empty theme configuration
> [06:26:05.012] (II) DAEMON: Greeter starting...
> [06:26:05.022] (II) HELPER: [PAM] Starting...
> [06:26:05.022] (II) HELPER: [PAM] Authenticating...
> [06:26:05.022] (II) HELPER: [PAM] returning.
> [06:26:05.142] (II) HELPER: Writing cookie to "/tmp/xauth_hBdSRs"
> [06:26:05.142] (II) HELPER: Starting X11 session: "" "/usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV"
> [06:26:05.152] (II) DAEMON: Greeter session started successfully
> [06:26:05.208] (II) DAEMON: Message received from greeter: Connect

Regards,
Markus

On Thu, Apr 4, 2024, at 01:02, Michael wrote:
> On Wednesday, 3 April 2024 19:29:11 BST Markus Gustafsson wrote:
>> Hi,
>>
>> I'm having a problem I'm not quite sure how to tackle: every other startup
>> or so results in a black screen. Usually nothing gets printed (no bios
>> splash, not GRUB menu, no OpenRC prints), and the monitor goes to low power
>> mode after a while (I haven't quite confirmed if this is actually the case,
>> or if everything happens before my monitor have actually stated, but I'd
>> expect the GRUB menu would hang long enough for it to do so).
>
> You can increase the GRUB timeout to a longer interval, but if this an
> intermittent phenomenon it is probably related to hardware. Check your cable
> and replace it if possible, or use an alternative port (DP/HDMI/DVI).
>
>
>> However, it does wake up if I switch to another TTY (e.g. ctrl+alt+F4) and
>> lets me log on, so it has obviously booted up. If I switch back to TTY 8
>> from there it just shows a blinking cursor (i.e. not SDDM, which is what
>> I'd expect). If I reboot from the TTY that lets me log on, the boot process
>> is usually normal and leaves me at the SDDM login.
>
> As others have mentioned sddm now starts in the first available tty, normaly
> on VT2. However, some users/PCs appear to have problems with more recent sddm
> versions, whereby the sddm-greeter fails to start, or fails to login into a
> desktop:
>
> https://bugs.gentoo.org/913862
>
>> Any tips on how to debug this would be much appreciated.
>
> Check the output on /var/log/ssdm when this problem manifests.
>
> Attachments:
> * signature.asc

On Thursday, 4 April 2024 05:55:20 BST Markus Gustafsson wrote:
> Hi again,
>
> I tried to catch the error again and while doing so I realized you guys are
of course correct: sddm usually starts on tty 2. I don't know why I got it
into my head that it would start on tty 8. Anyway, when I finally got it to
reproduce (took a few restarts) I didn't get a blinking cursor on tty 2, the
monitor just goes to sleep (kind of like it does when it has no signal).
Switching to tty 1 showed me the init log and let me log on so I could run the
commands suggested earlier in this thread:
> > $ ps aux | grep sddm
> > root 2253 0.0 0.0 142408 14248 ? Ssl 06:26 0:00
> > /usr/bin/sddm root 2300 0.2 0.2 1653332 89588 ? Ssl 06:26
> > 0:00 /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth
> > /run/sddm/xauth_UanezA -noreset -displayfd 16 root 2358 0.0 0.0
> > 61872 14024 ? S 06:26 0:00 /usr/libexec/sddm-helper --socket
> > /tmp/sddm-auth-49123ec6-075d-4982-860d-ea1de56059ca --id 2 --start
> > /usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV --user sddm --greeter
> > sddm 2359 0.0 0.4 1557540 135804 ? Sl 06:26 0:00
> > /usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV sddm 2365 0.0
> > 0.0 4320 1892 ? S 06:26 0:00 dbus-launch --autolaunch
> > d3bb17ba0dc5f70ad177e3f764fe168e --binary-syntax --close-stderr sddm
> > 2366 0.0 0.0 4620 224 ? Ss 06:26 0:00
> > /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7
> > --session

All of the above looks healthy to me.


> > $ rc-service sddm status
> > * rc-service: service `sddm' does not exist
>
> This is what the command yields for a successful startup as well though.
Should 'sddm' perhaps be 'display-manager' in the command above?

Yes, the sddm DM is started by the 'display-manager' OpenRC service from the
'default' runlevel:

~ $ rc-update -s -v | grep display
display-manager | default
display-manager-setup |


> Anyway:
> > rc-status
> > Runlevel: default
> >
> > sysklogd [
> > started ] dhcpcd
> > [ started ] dbus
> > [ started ] netmount
> > [ started ] chronyd
> > [ started ] cupsd
> > [ started ] switcheroo-control
> > [ started ] display-manager
> > [ started ] numlock
> > [ started ] local
> > [ started
> > ]>
> > Dynamic Runlevel: hotplugged
> > Dynamic Runlevel: needed/wanted
> >
> > display-manager-setup [
> > started ] avahi-daemon
> > [ started ]>
> > Dynamic Runlevel: manual
>
> This is also what it looks like for a successful startup.

Yes, nothing wrong with the above.


> And finally from /var/log/sddm.log:
> > [06:26:03.740] (II) DAEMON: Initializing...
> > [06:26:03.743] (II) DAEMON: Starting...
> > [06:26:03.743] (II) DAEMON: Logind interface found
> > [06:26:03.743] (II) DAEMON: Adding new display...
> > [06:26:03.744] (II) DAEMON: Loaded empty theme configuration
> > [06:26:03.744] (II) DAEMON: Xauthority path: "/run/sddm/xauth_UanezA"
> > [06:26:03.744] (II) DAEMON: Using VT 2
> > [06:26:03.744] (II) DAEMON: Display server starting...
> > [06:26:03.744] (II) DAEMON: Writing cookie to "/run/sddm/xauth_UanezA"
> > [06:26:03.744] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background
> > none -seat seat0 vt2 -auth /run/sddm/xauth_UanezA -noreset -displayfd 16
> > [06:26:04.993] (II) DAEMON: Setting default cursor
> > [06:26:05.010] (II) DAEMON: Running display setup script
> > "/usr/share/sddm/scripts/Xsetup" [06:26:05.012] (II) DAEMON: Display
> > server started.
> > [06:26:05.012] (II) DAEMON: Socket server starting...
> > [06:26:05.012] (II) DAEMON: Socket server started.
> > [06:26:05.012] (II) DAEMON: Loaded empty theme configuration
> > [06:26:05.012] (II) DAEMON: Greeter starting...
> > [06:26:05.022] (II) HELPER: [PAM] Starting...
> > [06:26:05.022] (II) HELPER: [PAM] Authenticating...
> > [06:26:05.022] (II) HELPER: [PAM] returning.
> > [06:26:05.142] (II) HELPER: Writing cookie to "/tmp/xauth_hBdSRs"
> > [06:26:05.142] (II) HELPER: Starting X11 session: ""
> > "/usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV" [06:26:05.152] (II)
> > DAEMON: Greeter session started successfully
> > [06:26:05.208] (II) DAEMON: Message received from greeter: Connect

And nothing wrong with your sddm.log either.

This makes me suspect again either some hardware issue, or some video driver
issue. Since the fault is intermittent and apparently random, what else can
control the signal to the monitor? o_O