„Debian 13 Trixie auf dem ThinkPad P15 Gen 1 – vom NVIDIA-Chaos zum sauberen GNOME-System“.
Vom NVIDIA-Chaos zu einem sauberen GNOME-System
Manchmal merkt man erst nach einigen Schwierigkeiten, wie gut eine Kombination aus Hardware und Linux eigentlich sein kann.
Bei mir war es ein Lenovo ThinkPad P15 Gen 1, auf dem ich Debian 13 „Trixie“ installiert habe. Anfangs sah das allerdings alles andere als nach einer gelungenen Kombination aus. Beim Start tauchten rote Fehlermeldungen auf, die Tastaturbeleuchtung verhielt sich nicht wie gewohnt, verschiedene Desktop-Komponenten waren installiert und vor allem NVIDIA bereitete Schwierigkeiten.
Heute sieht die Sache ganz anders aus.
Das ThinkPad gefällt mir mit Debian inzwischen ausgesprochen gut. Aber der Weg dahin zeigt auch sehr schön, warum man bei Linux nicht gleich bei jeder roten Fehlermeldung anfangen sollte, wahllos Pakete zu installieren und zu entfernen.
Die Hardware: Intel und NVIDIA in einem ThinkPad
In meinem P15 Gen 1 arbeiten zwei Grafikeinheiten:
Intel Corporation CometLake-H GT2 [UHD Graphics]
NVIDIA Corporation TU106GLM [Quadro RTX 3000 Mobile / Max-Q]
Das ist grundsätzlich eine interessante Kombination. Die Intel-Grafik kann sich um den normalen Desktopbetrieb kümmern, während für anspruchsvollere Aufgaben zusätzlich eine Quadro RTX 3000 mit 6 GB VRAM vorhanden ist.
Mein System:
Debian GNU/Linux 13 (trixie)
x86_64
GNOME
Genau die NVIDIA-Grafik wurde aber zu einem unserer größeren Probleme.
Plötzlich war der NVIDIA-Treiber zwar installiert – aber nicht für den aktuellen Kernel
Nach einem Kernel-Update häuften sich beim Booten Fehlermeldungen. Unter anderem schlug dieser Dienst fehl:
systemd-modules-load.service
Im Journal erschienen Meldungen wie:
Failed to insert module ’nvidia_drm‘: Invalid argument
und:
Module nvidia-current-drm not found
Interessant wurde es bei der Kontrolle von DKMS:
sudo dkms status
Damals kam sinngemäß heraus:
nvidia-current/550.163.01, 6.12.95+deb13-amd64, x86_64: installed
Das System lief aber inzwischen mit:
uname -r
6.12.100+deb13-amd64
Da war der entscheidende Hinweis.
Der Kernel war neuer als das dafür vorhandene NVIDIA-DKMS-Modul.
Warum die Kernel-Header so wichtig wurden
Der proprietäre NVIDIA-Treiber besteht nicht ausschließlich aus fertigen Programmen im Userspace. Er benötigt Kernelmodule, die zum jeweils verwendeten Linux-Kernel passen müssen.
Genau dafür kommt unter Debian unter anderem DKMS ins Spiel.
DKMS kann ein Kernelmodul für einen neu installierten Kernel automatisch neu bauen. Dafür braucht es allerdings die passenden Kernel-Header.
Und genau diese fehlten für unseren neuen Kernel.
Also installierten wir:
sudo apt install linux-headers-$(uname -r)
Und plötzlich konnte man förmlich dabei zusehen, wie Debian das Problem reparierte:
Autoinstall of module nvidia-current/550.163.01
for kernel 6.12.100+deb13-amd64
Building module(s)………….. done.
Danach wurden unter anderem installiert:
nvidia-current.ko
nvidia-current-modeset.ko
nvidia-current-drm.ko
nvidia-current-uvm.ko
nvidia-current-peermem.ko
Am Ende stand:
Autoinstall on 6.12.100+deb13-amd64 succeeded
Das war der Durchbruch.
Aber warum soll ich nach jedem Kernel-Update selbst an die Header denken?
Genau diese Frage stellte sich anschließend.
Eigentlich möchte ich bei einem normalen Debian-Update nicht jedes Mal kontrollieren müssen:
Habe ich jetzt eigentlich die Header für meinen neuen Kernel?
Die bessere Lösung war deshalb, nicht nur die Header einer bestimmten Kernelversion zu installieren, sondern das Debian-Metapaket:
sudo apt install linux-image-amd64 linux-headers-amd64
Der wichtige Teil ist:
linux-headers-amd64
Dieses Paket verweist jeweils auf die Header des aktuellen Debian-Kernels.
Bei einem späteren Update auf Kernel 6.12.101 konnten wir bereits sehen, dass es funktionierte. Debian installierte die neuen Header und DKMS baute NVIDIA auch für den neuen Kernel.
Die Kontrolle zeigte:
nvidia-current/550.163.01, 6.12.100+deb13-amd64, x86_64: installed
nvidia-current/550.163.01, 6.12.101+deb13-amd64, x86_64: installed
nvidia-current/550.163.01, 6.12.95+deb13-amd64, x86_64: installed
Genau so wollte ich es haben.
NVIDIA lebt wieder
Nach der Reparatur zeigte:
nvidia-smi
wieder sauber die Grafikkarte:
NVIDIA-SMI 550.163.01
Driver Version: 550.163.01
CUDA Version: 12.4
Quadro RTX 3000
6144 MiB
Damit war klar: Die Hardware war nicht das Problem. Auch Debian selbst war nicht grundsätzlich das Problem.
Die Kette
Kernel → Kernel-Header → DKMS → NVIDIA-Kernelmodul
war unterbrochen gewesen.
Und genau das ist für mich eine der wichtigsten Erkenntnisse dieser ganzen Aktion.
Dann kam der Desktop-Frühjahrsputz
Auf der Maschine hatte ich zunächst MATE ausprobiert und später GNOME. Dazu hatten sich im Laufe der Zeit noch etliche KDE-/Plasma-Komponenten angesammelt.
Irgendwann stellte sich die einfache Frage:
Wenn ich GNOME benutze – wozu brauche ich den ganzen KDE-Unterbau überhaupt?
Ein Blick auf die automatisch installierten Pakete zeigte eine riesige Liste mit Dingen wie:
kdeconnect
kded6
kwallet6
systemsettings
libplasma6
plasma-desktoptheme
libkf6…
kirigami…
Jetzt hätte man natürlich sagen können:
sudo apt autoremove
und hoffen, dass alles gut geht.
Genau das wollte ich aber nicht.
Erst simulieren, dann löschen
APT bietet eine wesentlich vernünftigere Möglichkeit:
sudo apt -s autoremove
Damit wird nur simuliert.
APT zeigt, was es entfernen würde, verändert aber noch nichts am System.
Bei uns waren es über 200 automatisch installierte Pakete. Wir konnten die Liste also erst kontrollieren und feststellen, dass GNOME, GDM, NVIDIA, Kernel und andere wesentliche Bestandteile nicht zur Entfernung vorgesehen waren.
Erst danach kam das tatsächliche:
sudo apt autoremove
Das ist eine Vorgehensweise, die ich mir merken werde:
Bei großen autoremove-Aktionen erst simulieren, dann lesen und erst anschließend löschen.
Und dann glaubte ich, KDE wäre immer noch da …
Nach dem Aufräumen kontrollierten wir:
dpkg -l | grep -Ei ‚kde|plasma‘
Und tatsächlich erschienen noch Einträge:
libblockdev-crypto3
libblockdev-fs3
libblockdev-loop3
libblockdev-nvme3
…
Moment mal.
Was haben die denn mit KDE zu tun?
Gar nichts.
Der Grund war herrlich banal.
In:
blockdev
steckt zufällig die Zeichenfolge:
bloc-kde-v
Also fand grep -i tatsächlich „kde“ innerhalb von blockdev.
Linux macht eben manchmal genau das, was man ihm sagt – und nicht unbedingt das, was man eigentlich gemeint hat.
Mit einer präziseren Suche:
dpkg -l | grep -Ei ‚plasma|kdeconnect|kaccounts|libkf6|kirigami‘
kam schließlich:
nichts.
Genau das wollten wir sehen.
Das Ergebnis
Nach den ganzen Arbeiten kam für mich einer der schönsten Befehle dieser Fehlersuche:
systemctl –failed
Die Antwort:
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.
Null fehlgeschlagene Units.
APT meldete ebenfalls:
Aktualisiere: 0
Installiere: 0
Entferne: 0
Aktualisiere nicht: 0
GNOME läuft, NVIDIA funktioniert wieder, die Kernel-Header werden zukünftig über das Metapaket nachgezogen und die überflüssigen KDE-/Plasma-Pakete sind verschwunden.
Natürlich bedeutet das nicht, dass jedes einzelne Wort mit ERROR in einem Linux-Journal für alle Zeiten verschwunden sein muss. Gerade Hardwaretreiber können Meldungen erzeugen, die für den tatsächlichen Betrieb nicht zwangsläufig kritisch sind.
Entscheidend ist für mich etwas anderes:
Das System ist wieder in einem nachvollziehbaren und wartbaren Zustand.
Was ich aus der Aktion mitnehme
Ich habe bei dieser Installation wieder einmal gemerkt, warum mir Debian gefällt.
Debian nimmt einem nicht jede Entscheidung ab. Wenn etwas nicht stimmt, muss man gelegentlich genauer hinschauen. Aber das System gibt einem gleichzeitig sehr gute Werkzeuge, um herauszufinden, was tatsächlich passiert.
journalctl, systemctl, dkms, apt, dpkg, lsmod und nvidia-smi haben uns Stück für Stück zur Ursache geführt.
Und mein ThinkPad P15 Gen 1?
Das gefällt mir inzwischen richtig gut.
Aus der Maschine, bei der ich nach den ersten Starts noch dachte: Was ist denn hier alles los?, ist ein schnelles und aufgeräumtes Debian-Arbeitssystem geworden.
Vielleicht ist genau das der Unterschied zwischen „Linux funktioniert nicht“ und einer Linux-Fehlersuche:
Nicht jede rote Zeile bedeutet, dass das System kaputt ist.
Aber wenn tatsächlich etwas kaputt ist, lohnt es sich herauszufinden, warum – statt einfach auf Verdacht die nächste Software darüberzuinstallieren.
Und wenn am Ende im Terminal steht:
0 loaded units listed.
darf man sich auch einfach mal zurücklehnen und sagen:
So. Jetzt bleibt es erst einmal so. 😄
