Logs, Kernelparameter und wieder mal nvidia-Probleme

Jeder kennt bestimmt das Gefühl, wenn Plan A nicht funktioniert, versuche ich Plan B. Was aber, wenn Plan Z auch nicht geht? Dann schaue ich am besten in ein Logfile und suche dort nach Fehlern. Könnte man einfacher haben! (Frei nach dem Motto „Wer lesen kann, muss nicht so oft installieren“)

Folgende Problemstellung: Auf einem Thinkpad E530 war ein xubuntu 20.04 installiert. Der Nutzer hat leider das Upgrade auf 22.04 installiert, nach einem Neustart passierte…nichts.

Nun genau genommen, blinkte der Cursor rechts oben- aber die grafische Benutzeroberfläche startete nicht mehr.

In einem solchen Falle mache ich erst einmal ein Backup (gemäß dem Motto: Kein Backup – Kein Mitleid!) Meine erste Vermutung war, dass bei dem Upgrade auf eine Option („alte Konfigurationsdateien behalten oder neue nehmen?“) falsch gewählt wurde. Da ich den Nutzer sowieso auf Linux Mint umstellen wollte (siehe auch Linux Mint- das bessere Ubuntu? und Die erste Woche mit Linux Mint), habe ich Mint installieren wollen. Die Mint-DVD 21.0 startete ohne Probleme, und es fuhr auch hoch, aber nach dem Einspielen der Updates und dem Neustart war das gleiche Bild wie mit xubuntu 22.04. Das gleiche nochmal mit UEFI probiert- gleiches Ergebnis. Von USB startete das Gerät garnicht.

Dann habe ich bei unseren schnellem 7MBit-Internet die 21.1-Mint-Installations-DVD heruntergeladen und gebrannt. Und siehe da, beim Hochfahren blieb er genauso hängen wie nach den Updates.

Gab es einen Hardwaredefekt? Auch das Ausbauen der SSDs brauchte keine Änderung. Interessanterweise startete die DVD im Kompatibilätsmodus durch, aber nach dem Einbauen der Festplatte und der Installation darauf nicht mehr von dort.

Es musste also eine Bootoption geben, mit der das Booten möglich ist. Aber welche und wie komme ich an das Logfile des Bootens?

Also Installations-DVD nochmal booten bis zum blinkenden Cursor, mit (FN+)STRG+ALT+F2 in den Textmodus auf Screen 2 wechseln, mit Benutzer „mint“ einloggen. Aber was war das, wieder erscheint der blinkende Cursor, ach scheinbar wechselt der Splash-Screen beim booten automatisch wieder auf Screen 1.

Stick angeschlossen, Mountpunkt angelegt, manuell gemountet und mit

dmesg > /mnt/extern/log.txt

das hier wichtige Log auf den Stick geschrieben. Und siehe da, im Log fand sich:

[   77.630103] spl: loading out-of-tree module taints kernel.
[   77.820121] znvpair: module license 'CDDL' taints kernel.
[   77.820132] Disabling lock debugging due to kernel taint

Mit der mittleren Zeile habe ich dann diesen https://forums.linuxmint.com/viewtopic.php?t=388716 Beitrag gefunden. Hinweis hier: Es könnte was mit einer Nvidia-Grafikkarte zu tun haben. Aber Moment, das Laptop hat noch „nur“ eine eingebaute HD4000-Grafics-Adapter. Könnte es trotzdem was damit zu tun haben? Wie kann ich das ausprobieren?

Lösung: Beim Booten den Bootparameter

nomodeset

setzen. (Quelle hierfür: https://askubuntu.com/questions/38780/how-do-i-set-nomodeset-after-ive-already-installed-ubuntu )
Damit konnte ich das System installieren, nach dem Neustart funktionierte es trotz weiterer Korrektur nicht. Da ich keine Lust hatte, im 7 Sekunden-Takt immer (FN+)+STRG+ALT+F1 zu drücken, habe ich den openssh-Server installiert und gebe die Befehle von meinem Laptop ein 😉

Ich bin dann noch auf eine interessante Zeile in dmesg gestoßen:

 Direct firmware load for nouveau/nvc1_fuc084 failed with error -2

Immer noch, das Ding hat keine nvidia-Grafikkarte (zumindest nicht meines Wissens). Habe das mit lspci gecheckt- und siehe da, das Laptop hat doch zusätzlich eine nvidia-Grafikkarte zur internen Grafikkarte. Zum Problem mit nvidia-Grafikkarten und linux: https://wiki.ubuntuusers.de/Grafikkarten/Nvidia/nvidia/
Ich habe also erst einmal von der Kommandozeile alle Pakete aktualisiert, danach alles von nvidia entfernt und den 470-Treiber installiert (laut lspci ist eine GeForce GT 635M enthalten).

sudo apt install nvidia-driver-470 nvidia-settings

Und jetzt das ganze wieder bei 7MBit herunterladen und dann den Bootparameter nomodeset entfernen… Obwohl eigentlich das der falsche Treiber ist, funktioniert es…
Die Lösung sollte also auch für (x)ubuntu 22.04 funktionieren!

Ob der Nutzer glücklich ist, wird sich noch zeigen- ich bin es schon! 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Seite verwendet Cookies, um die Nutzerfreundlichkeit zu verbessern. Mit der weiteren Verwendung stimmst du dem zu.

Datenschutzerklärung