gdm3 stopped working after hardware update

[_VZ]

I've been happily (subject to known mutter bugs) using Bookworm with GNOME/Wayland for almost a year when I had a hardware problem and had to replace the CPU. This obviously shouldn't have affected anything at all for the installed OS, but somehow since doing it, gdm3 doesn't work any more: it starts X11 but nothing at all appears on the screen (all 3 connected displays remain black). I can still start GNOME using `dbus-run-session -- gnome-shell --display-server --wayland` from a VT and I can also run `sway` from a VT without any problems, but somehow running gnome-shell in this way doesn't provide correct display information to X applications (that use XWayland) and they appear tiny on the display using 200% scaling, so this is not really usable. FWIW sway does work fine, including for X applications. But it feels a bit weird to have to login at the console instead of in gdm.

AFAICS there are several problems:

1. X doesn't work for some reason.
2. gdm3 uses X even though I only want to use Wayland.
3. X doesn't work correctly under gnome-session launched manually.

I'd like to avoid dealing with X if possible, so I'm mostly interested in solving (2) or at least (3). I.e. I'd like to know if gdm3 can work without X, or if it still needs it even with "WaylandEnable=true" in /etc/gdm3/daemon.conf?

And the main mystery is why did the behaviour change when I literally didn't do anything except changing (non-video) hardware?

FWIW I use a Radeon RX 6600 card for 2 displays and the integrated Intel UHD Graphics 770 for another one. I hadn't done anything to configure this hardware when installing Bookworm on this machine, everything just worked out of the box -- and Wayland still works fine.

Thanks in advance for any ideas!

[mrmazda]

What were the CPU models before and after replacement? Not all CPUs a motherboard socket supports are equipped with identical integrated GPUs. There could be a bug that only manifests with one of your before and after iGPUs.

You might should consider yourself lucky your three display configuration ever worked. It used to be that motherboard BIOS for Intel CPUs by default, if not entirely, disabled the iGPU when a discrete GPU was present. Others would allow the iGPU to be selected, but disabled the discrete. Newer ones typically allow to select a default/primary GPU and still enable the other, but not always.

It's possible you need to make a BIOS setup change. Did you reset BIOS defaults after your CPU change?

Doesn't your Radeon support three or more displays? If it does, why complicate things by using the iGPU?

[_VZ]

Thanks for your reply, but I don't think anything of this explains the problem unfortunately. The main question still remains: why does gdm3 decide to launch (not working) X11 session instead of using Wayland? I've just checked on another Debian Bookworm machine and, of course, there is no X11 running at all there -- just gdm-wayland-session. Why does it try to run gdm-x-session here and how can I convince it not to?

What were the CPU models before and after replacement?

The CPU are almost identical: I replaced i9-13900K with i9-14900K.

You might should consider yourself lucky your three display configuration ever worked.

Maybe, but it did work and continues to work just fine with Wayland if I start the compositor manually (whether it's mutter or sway).

It's possible you need to make a BIOS setup change. Did you reset BIOS defaults after your CPU change?

I had actually updated BIOS to the latest version even before replacing the CPU and while it didn't help with the hardware problem (it still froze intermittently), it didn't affect the video output. And I have the same, latest, BIOS now.

Doesn't your Radeon support three or more displays? If it does, why complicate things by using the iGPU?

It does support 3 displays, but it has a single HDMI input and I have 2 displays with only HDMI outputs, so I connected one of them to the HDMI output on the motherboard. I guess I could buy an adapter and connect it directly to the video card but, again, this looks like a software rather than hardware problem now, isn't it?

[mrmazda]

Why does it try to run gdm-x-session here and how can I convince it not to?

Are you using auto-login? The GDM login screen is the normal point at which one selects a session type to open. If you bypass it, it uses whatever it remembered as the last used type.

The CPU are almost identical: I replaced i9-13900K with i9-14900K.
...
I guess I could buy an adapter and connect it directly to the video card but, again, this looks like a software rather than hardware problem now, isn't it?

Yes, and no. Normal wisdom in the Linux world, unless you are a kernel, driver, or other foundational support developer, is not
to try to use young hardware and expect it to fully work as expected. Release to market of your current CPU isn't six months ago yet, not much bake time to account for whatever differences may exist between 13th gen 13900K and 14th gen 14900K.

Passive DP to HDMI adapters are inexpensive, and IME, reliable.

[_VZ]

Are you using auto-login?

No, I don't, and never did.

The GDM login screen is the normal point at which one selects a session type to open. If you bypass it, it uses whatever it remembered as the last used type.

Would you know where this is stored? I've never selected X session intentionally but who knows what happened while the system was crashing all the time due to a faulty CPU...

[mrmazda]

You might try selecting something other than one of the Gnome session types to test, searching through ~/ for the type selected, then switching back to Gnome Wayland.

The traditional location I'm aware of is ~/.dmrc, which may contain "Session=default" instead of a specific type. Whether GDM uses something else I don't know.

[_VZ]

You might try selecting something other than one of the Gnome session types to test, searching through ~/ for the type selected, then switching back to Gnome Wayland.

The traditional location I'm aware of is ~/.dmrc, which may contain "Session=default" instead of a specific type. Whether GDM uses something else I don't know.

Unfortunately I can't select anything because I don't see anything on the screen after starting gdm3. I don't have ~/.dmrc but it would be surprising if gdm3 looked there as it's run as root, not as my user. And according to everything I read, it should default to Wayland -- and it used to, because I had never configured it to do it explicitly. Except that, for some reason, it doesn't do it any longer. Why is this so remains a complete mystery to me...

[mrmazda]

Unfortunately I can't select anything because I don't see anything on the screen after starting gdm3. I don't have ~/.dmrc but it would be surprising if gdm3 looked there as it's run as root, not as my user.

You could do a nomodeset boot in order to enable the session type search - in your homedir. Yes, GDM runs as root, but IMO it logically would find required user data other than password in the user's homedir. You could try searching for your username in the /etc/ tree to see where it shows up.

[_VZ]

Unfortunately I can't select anything because I don't see anything on the screen after starting gdm3. I don't have ~/.dmrc but it would be surprising if gdm3 looked there as it's run as root, not as my user.

You could do a nomodeset boot in order to enable the session type search - in your homedir. Yes, GDM runs as root, but IMO it logically would find required user data other than password in the user's homedir. You could try searching for your username in the /etc/ tree to see where it shows up.

Sorry, I don't understand. Just to be clear, I can't even enter my username -- because I don't see anything on the screen. So how could gdm3 possibly look in my home directory before it even knows which user is logging in?

The problem doesn't happen when logging it, but already before showing gdm greeter itself.

[mrmazda]

A nomodeset boot means you strike the E key at the Grub menu and append string nomodeset to the end of the (usually wrapped) linu line before proceeding to boot. That should give you one working lowfi display from which you can do things like capture logs, reconfigure, or install software.

A "recovery" selection made from the Grub Advanced menu should provide a similar result, but possibly without working network or X.

[_VZ]

A nomodeset boot means you strike the E key at the Grub menu and append string nomodeset to the end of the (usually wrapped) linu line before proceeding to boot. That should give you one working lowfi display from which you can do things like capture logs, reconfigure, or install software.

A "recovery" selection made from the Grub Advanced menu should provide a similar result, but possibly without working network or X.

Sorry, this doesn't really help. I know how to use kernel parameters but with "nomodeset" X11 just refuses to start saying that there're no suitable screens, which is not really better. And I don't need to boot in the rescue mode, as I can boot into normal multi user target just fine -- and can run Wayland compositors from it too.

The question still remains why does gdm3 suddenly want to run X11 instead of Wayland and I still have no clue about it.

[mrmazda]

I can't help with why. I never use GDM, or Gnome, or Wayland. I'm here to provide troubleshooting ideas, to try to help get you to your desired end result - Gnome running satisfactorily on Wayland. Lightdm and SDDM both should also be able to give you what your particular GDM installation/configuration currently won't. If neither can either, it surely means GDM isn't where your problem lies, but may elicit log messages that sticking to GDM doesn't seem to have provided.

[_VZ]

OK, thanks for trying to help, but I think I still haven't managed to explain the problem properly Neither LightDM nor SDDM are of any help as both of them only support using X for their own display (even though they can start Wayland sessions), unlike gdm which is supposed to be able to use Wayland only -- yet, somehow, does not.

[mrmazda]

It was my understanding that GDM does run on X, and was expected to continue to do so for the foreseeable future, if not indefinitely, and that it's only at post-login user session startup where Wayland takes over display control.

[_VZ]

It was my understanding that GDM does run on X, and was expected to continue to do so for the foreseeable future, if not indefinitely, and that it's only at post-login user session startup where Wayland takes over display control.

No, this is definitely not the case. E.g. here is the list of processes running with no user logged in (I connected via ssh) on another Debian Bookworm machine:

Code: Select all

root        1593       1  0 61545  8016   3  2023 ?        00:00:00 /usr/sbin/gdm3
root      342653    1593  0 42745 11060   2 00:05 ?        00:00:00 gdm-session-worker [pam/gdm-launch-environment]
Debian-+  342681  342653  0 41260  8064   1 00:05 tty1     00:00:00 /usr/libexec/gdm-wayland-session dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart
Debian-+  342687  342681  0  1565  1520   0 00:05 tty1     00:00:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart
Debian-+  342696  342687  0 131521 22244  2 00:05 tty1     00:00:00 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart

As you can see only gdm-wayland-session is running and Xorg is not running at all.

On this machine, however, gdm3 launches gdm-x-session instead and I have no idea why...

[mrmazda]

As you can see only gdm-wayland-session is running and Xorg is not running at all.

The command you issued and trailing prompt are missing, so I have no idea what those 5 lines show just from looking. I just booted a 32bit Bookworm, logged in remotely, and get the following:

Code: Select all

# ps -e | wc -l
140
# ps -e | egrep -i 'dm|xorg|wayl|x11|tty'
  PID TTY          TIME CMD
  578 ?        00:00:00 rpc.idmapd
  626 ?        00:00:00 tdm
  640 tty7     00:00:02 Xorg
  761 ?        00:00:11 tdm_greet
#

[_VZ]

The command you issued and trailing prompt are missing, so I have no idea what those 5 lines show just from looking.

Sorry, I should have mentioned that this was `ps -A | egrep '(gdm|x11)'` output with the grep command itself excluded.

I just booted a 32bit Bookworm, logged in remotely, and get the following:

Code: Select all

# ps -e | wc -l
140
# ps -e | egrep -i 'dm|xorg|wayl|x11|tty'
  PID TTY          TIME CMD
  578 ?        00:00:00 rpc.idmapd
  626 ?        00:00:00 tdm
  640 tty7     00:00:02 Xorg
  761 ?        00:00:11 tdm_greet
#

Well, this machine doesn't seem to be running gdm at all, so I'm not sure what is this supposed to show?

[mrmazda]

140 running processes with newest still well under 4 digits, fetching in short order following fresh boot. Your ps ID 2023 makes me wonder what's going on, and how long before you ran ps.

A little busier here on newer/64bit with RAID added:

Code: Select all

# ps -e | wc -l
209
# ps -e | egrep -i 'dm|xorg|wayl|x11|tty'
    PID TTY          TIME CMD
    431 ?        00:00:00 mdadm
    948 ?        00:00:00 rpc.idmapd
    962 ?        00:00:00 tdm
    965 tty7     00:00:00 Xorg
   1066 ?        00:00:01 tdm_greet
   1234 tty1     00:00:00 agetty
   1239 tty4     00:00:00 agetty
   1240 tty2     00:00:00 agetty
   1242 tty5     00:00:00 agetty
   1244 tty6     00:00:00 agetty
   1247 tty3     00:00:00 agetty

# inxi -S
System:
  Host: msi85 Kernel: 6.1.0-18-amd64 arch: x86_64 bits: 64
  Desktop: Trinity v: N/A Distro: Debian GNU/Linux 12 (bookworm)
#

Still substantially less than 2023.

[_VZ]

140 running processes with newest still well under 4 digits, fetching in short order following fresh boot. Your ps ID 2023 makes me wonder what's going on.

I didn't reboot the machine and it had a lot of processes running on it (every time I run "make -j`nproc`" more than a thousand of processes must be getting created and destroyed), but why should it matter?

Again, the important thing is that gdm-session-worker launches /usr/libexec/gdm-wayland-session on that machine, but it launches /usr/libexec/gdm-x-session on this one and I have no idea why, as they're using identical configurations.

[friendlysalmon88]

I'd recommend that the OP try and grab the X11 and waylaid startup log files which usefully reside at /var/logs/X11 and /var/log/wayland. And either post them to the the debian 'ysers forums useing the code tags or to the following https://pastebin.com/.