NVIDIA: Durchbruch beim proprietären Nvidiatreiber \o/

Ihr erinnert Euch an diese Sache:

Fedora: Kernel 6.1.5 & 6.2.0.alpha ohne Nvidia Grafikkartensupport

NVIDIA: Durchbruch beim proprietären Nvidiatreiber \o/

Wie Ihr den Artikeln dazu entnehmen könnt, hatten einige Benutzer überhaupt keine Probleme mit dem proprietären Treiber von Nvidia, andere konnten nichts mehr sehen, weil der Bildschirm schwarz blieb.

In einer fast schon spektakulären Tag & Sonnenschein Aktion sind wir heute der Ursache endgültig auf die Spur gekommen und konnten den Kernel 6.1.5 , der ohne efifb / vesa Framebuffertreiber kompiliert wurde, erfolgreich booten, trotz Nvidia Treibern.

Das liegt darin, daß die Nvidia-Treiberversion 525.xx schon mit SimpleDRM Support ausgerüstet ist, und daher auch ohne efifb/vesa Support geladen werden kann. Ein Umstand, der sehr sehr lange in der Gemeinde für Frust und Wut über Nvidia gesorgt hat. „Emotionsgeladene Argumentationen“ wäre als Beschreibung völlig untertrieben, wenn Ihr mich fragt 😉

Wieso konnte man dann aber trotzdem nichts sehen?

Da Nvidiainstallationen nicht vom Baum fallen, sondern über die Zeit gewachsen sind und mit dem OpenSource Treiber nouveau nicht gleichzeitig genutzt werden können, muß man nouveau in der Kernel Command Line ausschalten und aktiv den Nvidiatreiber ansprechen.

Da sah bisher so aus:

nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init

Wie Ihr sehen könnt, ist auch die simpledrm Factory abgeschaltet, so daß man efifb/vesa braucht. Lässt man initcall_blacklist=simpledrm_platform_driver_init weg, könnte man schon den 6.1.5 Kernel booten, würde aber erst beim Init von X was sehen, z.b. wenn GDM startet. Alles was im initramfs passiert, bleibt unsichtbar. Da in dieser Phase die Festplattenverschlüsselung nach dem Passwort fragt, muß man das blind eingeben oder ist aufgeschmissen. Das ist Erklärung #1 , wieso einige Benutzer von dem Problem nichts mitbekommen haben: Keine Festplattenverschlüsselung!

ein goldener Pinguin in einem technisch angehauchten Raum mit Glasboden und Monitoren reißt die Flügel hoch vor Freude.

erstellt mit: https://you.com – Stable Diffusion 2.1

Und so booten man normal mit dem 6.1.5 Kernel

Wie Ihr oben sehen könnt, steht in der Kernel Command Line noch mehr drin, nämlich: nvidia-drm.modeset=1

Und das ist der Grund, wie man im Initramfs nichts sehen kann, weil darüber auch efifb/vesa aktiviert wird, was nicht geht, weil es nicht mehr einkompiliert ist. Ergo, lassen wir auch diesen Eintrag weg und booten nur noch mit:

nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau

und alles funktioniert \o/ Woher ich das weiß, weil ich es ausprobiert habe und Ihr seid die ersten, die das erfahren 🙂 Naja, fast, die Kernelgang von Redhat weiß es seit 15 Minuten 😉

$ uname -a
Linux charming.knuddelpc.de 6.1.5-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jan 12 16:10:44 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
$ date -R
Tue, 28 Feb 2023 15:34:36 +0100

Aber wieso, waren einige gar nicht davon betroffen?

Weil neuere Installationen beim Eintragen in die Grub Default andere Kernelparameter eingetragen haben!

Das ist die Erklärung, wieso einige Benutzer von dem Problem nichts mitbekommen haben! Sie hatten einfach die richtigen Anweisungen in der Config stehen!

How To FIX!

Damit Ihr in Zukunft gewappnet seid, ändert Ihr als root die Datei /etc/default/grub und werft dort „nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init“ komplett raus.

Dann könnt Ihr gelassen auf das nächste Kernelupdate warten, daß Euch eine neue Bootconfig baut. Deswegen extra eine zu erstellen ist nicht nötig, Ihr habt ja gerade ein Bild, oder? 😉

 

Linux Surface: Update iptsd entfernt globale Config

Mehr oder weniger aus Versehen hat ein Update für den Touchsupport vom Linux Surface Kernel Project Touch deaktiviert.

Linux Surface: Update iptsd entfernt globale Config

Wer ein Touchgerät bedienen will braucht .. richtig.. Touchsupport. Für den Surface Kernel macht das seit 5.0 der iptsd , der sich auch um den Stift kümmert. Bis vor kurzem, in den letzten 2 Wochen, hies die config vom iptsd noch /etc/ipts.conf . Das hat sich geändert, was dramatische Folgen hatte, denn der Touchsupport lieferte nur noch jede Menge Phantomklicks und Gesten, weil die richtigen Parameter nicht mehr in der Defaultconfig stehen.

Ihr löst das am besten so: legt /etc/iptsd.d/ipts.conf neu an und schreibt rein:

[Config]
# BlockOnPalm = false
TouchThreshold = 50
StabilityThreshold = 0.55

[Touch]
CheckStability = true
DisableOnPalm = true
DisableOnStylus = false

[Contacts]
Detection = advanced

TemporalWindow = 5

SizeMin = 0.3

[Cone]

[DFT]

Ihr merkt schon, man hat einfach im RPM die Config umgenannt. Das hat zur Folge, daß RPM die Datei einfach entfernt. Mit der neuen /etc/iptsd.d/ Dropinmechanik wird das nicht mehr passieren.

systemctl restart iptsd@dev-hidraw0.service

und schon wird es ruhig auf dem Desktop 😀

Linux am Dienstag – Programm für den 17.1.2023

Bei Linux am Dienstag schauen wir uns heute mal an, wie von einem dummen Fehler, zu einer Verschwörung und wieder zurück kommt. Das alles schauen wir uns Live on Disk mit dem Fedora Bug des Monats im Kernel 6.1.5 an, der mal kurz Nvidia’s Proparitären Treiber ausgeknockt hat.

Linux am Dienstag – Programm für den 17.1.2023

Dienstag Abend ab 19 Uhr geht es u.a. um:

  • OpenSource – Apachen gegen Apache – Kulturelle Aneignung oder Bewunderung?
  • Sicherheit – Centos Web Panel mit RCE
  • Fedora – Kernel“fehler“ schaltet Nvidia Grafik ab (Marius)
  • Krypto – FTX – 5 Milliarden Dollar zurückgeholt
  • Datenschutz – Google vom Kartelamt abgemahnt

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .