#1115901 Bug on Debian 13 Trixie with Cinnamon desktop or with Cinnamon Live ISO

Package:
cinnamon
Source:
cinnamon
Description:
Innovative and comfortable desktop
Submitter:
Date:
2026-10-20 14:19:02 UTC
Severity:
normal
#1115901#5
Date:
2025-09-21 12:02:28 UTC
From:
To:
Version: 6.4.10-2: amd64


Severity: important


Tags: cinnamon, forky, sid, trixie


Bug Description:


With the live ISO of Debian 13 Trixie Cinnamon, on my system (AMD 5950x + RTX 5070 Ti), the system boot but it's impossible to access a graphic session.


It displays an error message on startup :


nouveau 0000:00:00.0 unknown chipset (1b300a1)


After this I can use the text console. If I use the commande line "startx" the graphical environment then starts without problems.


If I edit Grub at boot and add the function "nouveau.modeset=0" like below, there is no change, it still does not work :


GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nouveau.modeset=0"


This affects all ISOs when you using Cinnamon.


Strangely this problem is only present under Cinanmon, everything works fine from Gnome.


I am attaching the files :


- boot.log


- Xorg.0.log


After installing Nvidia's proprietary .run driver, everything is back to normal.


Thank you to correct this as soon as possible.


Best regards.


Philippe

#1115901#12
Date:
2026-09-13 16:05:50 UTC
From:
To:
Hi, and sorry for the long delay.

Thanks for the logs, they make the picture clear. The nouveau in the
trixie kernel does not
know your card ("unknown chipset (1b300a1)"), so there is no KMS and no
`/dev/dri/card0` at
all. X still starts, but only on the EFI framebuffer at 800x600, and GLX
falls back to
indirect swrast:

(EE) [drm] Failed to open DRM device for pci:0000:08:00.0: -19
(II) AIGLX: Screen 0 is not DRI2 capable
(II) IGLX: Loaded and initialized swrast

Cinnamon needs a GL context it can actually use, so it does not get that
far, which is why
you end up without a session. Nothing in the cinnamon package can fix
that: the missing
piece is the kernel driver, so installing the NVIDIA driver, as you did,
is the right
answer for now. A newer kernel from trixie-backports may also help,
though I cannot tell
from here whether nouveau supports your card yet.

One thing worth trying, if you ever want the open driver: at the login
screen pick the
session "Cinnamon (Software Rendering)" instead of "Cinnamon". It runs
Cinnamon with
`LIBGL_ALWAYS_SOFTWARE=1`, which works even with no DRM device. If that
gets you a usable
desktop where the normal session does not, I would very much like to know.

Your report was useful beyond your own machine: upstream has just
removed that session from
the display manager, so I opened linuxmint/Cinnamon#13996 asking how the
no-usable-GL case
should be handled from now on, and linuxmint/cinnamon-session#218 about
the leftover
detection helper nobody calls.

If you want to dig further, the missing pieces are
`/var/log/lightdm/lightdm.log`,
`/var/log/lightdm/x-0.log` and `~/.xsession-errors` from a boot without
the NVIDIA driver,
plus what exactly your `startx` launches (`~/.xinitrc`), since that is
the part I could not
reproduce.

Thanks,
Fabio

#1115901#17
Date:
2026-09-22 16:54:11 UTC
From:
To:
Hello Fabio,

No worries about the response time, it’s kind of you to have taken the time to reply to me.

Unfortunately, since I only have access at command line, I log in with my username, then I run the startx command, and there, I immediately arrive on the Cinnamon desktop by-passing the graphical login manager. It is therefore impossible for me to choose the "Software Rendering" mode.

I took advantage of an upgrade to the Nvidia driver released today to uninstall the old driver, launch a text cession and start a graphic cession via "startx" without additional driver and thus provide you with the 3 requested files.

`/var/log/lightdm/lightdm.log`
`/var/log/lightdm/x-0.log`
`~/.xsession-errors`

Notice that I renamed ".xsession-errors" to "xsession-errors" for convenience.

I hope that the Nova pilot will soon be mature enough to take over from the Nouveau pilot. That will probably avoid this type of problem in the futur.

Thank you again for everything, it’s always a pleasure to have contact with you and to be able to make my modest contribution to free software, me too :)

Best regards.

Philippe

#1115901#22
Date:
2026-09-25 19:08:42 UTC
From:
To:
Hello Philippe,

Thank you for the logs. They narrow things down a lot, and they also
show that something I told you last time was wrong.

The `.xsession-errors` from your `startx` session without the NVIDIA
driver shows Cinnamon starting normally ("Cinnamon took 508 ms to
start") on the framebuffer, and the session stays up for as long as you
used it. So I was wrong when I wrote that Cinnamon does not get that far
without a usable GL context: it works on the software GL it gets there,
and the "Software Rendering" session would not have changed anything.
Sorry for sending you in that direction.

What seems to fail is the step before, and `lightdm.log` points to it:

     [+0.00s] DEBUG: Monitoring logind for seats
     [+0.00s] DEBUG: Stopping Plymouth, no displays replace it

lightdm never adds a seat, so it never starts X at all. By default it
only starts the seats that systemd-logind reports as able to run
graphics, and logind decides that from udev tags. In trixie's
`/usr/lib/udev/rules.d/71-seat.rules` a DRM device (`/dev/dri/card0`)
always qualifies, but a plain framebuffer like the EFI one you are left
with only qualifies when the kernel is booted with `nomodeset`:

     # Allow efifb / uvesafb to be a master if KMS is disabled
     SUBSYSTEM=="graphics", KERNEL=="fb[0-9]",
IMPORT{cmdline}="nomodeset", TAG+="master-of-seat"

Your kernel command line only has `ro quiet`, so my guess is that seat0
is not considered graphical, lightdm waits for it forever and you are
left on the console. `startx` does not ask logind about any of this,
which would explain why it works.

I could not check this on hardware like yours, so if you are willing to
test it, next time you are without the NVIDIA driver:

1. from the console, `loginctl show-seat seat0 -p CanGraphical` should
print `CanGraphical=no`;
2. reboot, press `e` on the Debian entry in GRUB, add `nomodeset` at the
end of the line starting with `linux`, and boot with Ctrl+X (this only
affects that one boot, nothing is saved);
3. the same command should now print `CanGraphical=yes`, and the lightdm
login screen should appear;
4. if it does, log in to the normal "Cinnamon" session from there and
tell me whether you get a working desktop, as you do with `startx`.

If that is confirmed, the problem would not be in cinnamon: the missing
piece would still be nouveau support for your card in the kernel, and
the seat rule is a deliberate choice in systemd (a bare framebuffer only
counts as a graphical seat when KMS is disabled on purpose). If instead
lightdm still does not start, or the Cinnamon session fails when started
from it, the logs from that boot (the same three files, plus the output
of the `loginctl` command) would tell us where to look next.

Thanks again for your patience and for the careful testing,
Fabio

#1115901#27
Date:
2026-10-09 16:10:25 UTC
From:
To:
Hello Fabio,

I took the time to redo some tests today.


- From a console, `loginctl show-seat seat0 -p CanGraphical` show `CanGraphical=no`

- After restarting, `e` on the Debian entry in GRUB, and adding `nomodeset` at the end of the line starting with `linux`, and starting with Ctrl+X, it works perfectly.


There are two points that I don’t quite understand :


- Why isn’t command "nouveau.modeset=0" working ?

- Why is Gnome not affected by this same bug ?


I wish you an excellent weekend, rest well.

Best regards.

Philippe

#1115901#32
Date:
2026-10-20 14:16:08 UTC
From:
To:
After testing Debian SID + Cinnamon, I confirm that the bug seems resolved for Debian 14.

The NV 5000 series GPUs are now natively supported under SID.

For the NV GPU series 1650 and higher, it is now theoretically the "NOVA" GPU driver that has taken over from the old "Nouveau" driver.

On the other hand, the bug persists in Debian 13, it will certainly not be resolved...

Regards.