#1125785 the login screen fails to show up after Debian got upgraded and the user logged out #1125785
- Package:
- gnome-shell
- Source:
- gnome-shell
- Description:
- graphical shell for the GNOME desktop
- Submitter:
- Al Ma
- Date:
- 2026-01-17 21:51:01 UTC
- Severity:
- normal
The user has had his/her GNOME session open for many days, during which Debian got upgraded from 13.2 to 13.3 in the background. After logging out, the user saw no graphical GDM login screen, though one was expected. Instead, the screen kept switching between completely black and almost black (perhaps backlit); one of the two types showed a mouse pointer. Trying to go to a tty with a key combination Ctrl+Alt+[F2…F6] took time; the user pressed the key combination quite a few times until he/she got a text login screen. A plain reboot didn't help. Rebooting with the kernel option `nomodeset` helped (and the GDM screen showed up), but the only resolution available with `nomodeset` is 1024×768 😥; this hack is better than nothing but too low-res these days. The graphics card is NVIDIA PΛLiΤ GeForce GTX 1660, to which two cables are connected: a DisplayPort-cable (with a 1900×1200-capable monitor on the other end), and a DVI cable (without a monitor on the other end). The motherboard is Asus WS C422 PRO SE. The output of `journalctl -p 0..4` is attached. I believe it's a software error (or, worse, a faulty hardware/firmware design), as it occurred on two similar computers with almost the same hardware. I'd be grateful for a bug fix (or a workaround if the bug is in the hardware/firmware design).
Uncommenting `WaylandEnable=false` in /etc/gdm3/daemon.conf works around the issue without nomodeset. I believe there should be a better fix.
A connected DVI cable without a monitor on the other end turned out to be unrelated; unplugging it didn't help. Alternatively to disable Wayland, it helps if we leave Wayland enabled in /etc/gdm3/daemon.conf but add the kernel option `nouveau.config=NvGspRm=0`: $ grep Wayland /etc/gdm3/daemon.conf #WaylandEnable=false $ grep CMD /etc/default/grub GRUB_CMDLINE_LINUX="nouveau.config=NvGspRm=0" However, this way we get a ton of repeated errors in the journal, which gets really noisy and distracting due to the repeated nouveau 0000:65:00.0: gr: DATA_ERROR 0000009c [] ch 6 [017f886000 gnome-shell[2361]] subc 0 class c597 mthd 0d78 data 00000004 The next upgrade would have to deal with a nondefault config file – be it /etc/gdm3/daemon.conf or /etc/default/grub – so errors may occur during upgrade. So I believe a better/proper fix from the authors/maintainers is needed. Temporarily, we switch to XOrg – simply because if we hit another error, we have a cleaner log to analyze and an option we understand.