[gentoo-user] Every other startup results in a black screen (possibly SDDM related?)

[Jack]

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.

[Michael]

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

$ 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 |

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.

[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

[Wols Lists]

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

[Michael]

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.

[Markus Gustafsson]

Hi again,

$ 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
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.

[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

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
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.
* signature.asc

[Dale]

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

:-)  :-) 

[Hoël Bézier]

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