Fedora & Kernel 6.3.4 und die nichtendenwollende Geschichte mit Nvidia

Ich bin ja gestern Abend schon gewarnt worden, daß das Kernel 6.3.4 Update Probleme bringen würde, aber hey, ich hatte doch damals im Januar, als Kernel 6.1.5 plötzlich mit schwarzem Bildschirm bootete, schon alles in Grub so geändert, daß es bereits funktioniert hat! Trotzdem hatte ich heute morgen einen schwarzen Bildschirm vor mir. Tja.

„Ups, we did it again“ ?

Ich erspare Euch mal viel Geschreibsel zur Suche, aber Ihr solltet vorher das hier gelesen haben:

Fedora: „Nein, es ist keine Verschwörung die User zum HW Wechsel zu bekommen.“

Heute morgen hatte ich also genau das gleiche Fehlerbild: schwarzer Bildschirm beim Booten. Passworteingabe blind.

Die Ursache war eine falsch zusammengebaute BLS Config, die sich aus den Grubdefaults ( /etc(/default/grub ) eine Kommentarzeile reingezogen hat, die aber seit dem Januarvorfall auskommentiert ist:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=“$(sed ’s, release .*$,,g‘ /etc/system-release)“
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
#GRUB_TERMINAL_OUTPUT=“console“
#GRUB_CMDLINE_LINUX=“vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 rd.luks.uuid=luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 rhgb quiet splash audit=0 nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init“
GRUB_CMDLINE_LINUX=“vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 rd.luks.uuid=luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 rhgb quiet splash audit=0 nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau“
GRUB_DISABLE_RECOVERY=“true“
GRUB_VIDEO_BACKEND=vbe
GRUB_FONT_PATH=/boot/grub2/fonts/unicode.pf2
GRUB_GFXMODE=0x11b
GRUB_GFXPAYLOAD_LINUX=“keep“
GRUB_TERMINAL_OUTPUT=“gfxterm“
#GRUB_GFXMODE=“1440x900x32″
GRUB_ENABLE_BLSCFG=true

Nachdem das aus der BLS Configdatei für Kernel 6.3.4 raus war, funktionierte es auch wieder. Entscheidend war das hier „initcall_blacklist=simpledrm_platform_driver_init„, welches den Init vom SimpleDRM System verhindert hat. Scheinbar wurde endgültig der Support der alten Treiber, die durch die falsche gebaute Config immer noch benutzt wurden, endgültig aus dem Kernel entfernt. Damit die BLS Config dann wieder richtig geschrieben wird, muß die Kommentarzeile raus und grub2-mkconfig ausgeführt werden. Da in der /boot/grub2/grub.cfg aber die richtige Zeile drinstand, ist das schon ein sehr kurioser Fehler vom grub2-mkconfig.

Für Euch: Immer genau hinsehen, ob etwas wirklich so ist, wie es sein sollte.

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? 😉

 

Fedora: „Nein, es ist keine Verschwörung die User zum HW Wechsel zu bekommen.“

Justin Forbes, einer der Hauptmaintainer für den Kernel, hat gerade die Sache mit dem Nvidia Treibern und den Kerneln 6.1.5/6 + 6.2.0rc1 aufgeklärt. Fedora wird also Nvidia nicht in die Schranken weisen 😉

Fedora: „Nein, es ist keine Verschwörung die User zum HW Wechsel zu bekommen.“

„Kleiner Fehler, große Wirkung“ das triffts wohl am besten 😀

Zwischenzeitlich hatte Leight Scott u.A. für Cinnamon, RPMFusion’s Nvidiatreiber und diverse andere wichtige Pakete verantwortlich, damit gedroht Fedora zu droppen. Das wäre ein schwerer Schlag für das Fedora Projekt geworden, aber wir haben da im Bugreport wohl etwas viel rein interpretiert. Der Bug ist offiziell geschlossen worden:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |CLOSED
         Resolution|---                         |NEXTRELEASE
        Last Closed|                            |2023-01-16 15:58:28

Der Kommentar dazu entlarvt uns dann als leicht hysterische Menschen, die da schon eine Fedora Verschwörung gewittert haben sollen. Wir lieben eben unser Fedora so wie es ist \o/

— Comment #42 from Justin M. Forbes —
This is not some conspiracy to get users to switch hardware. The simple explanation is nvidia’s driver is BROKEN. We know this, and as a result, we
carry a nasty hack to make things work. That hack is not, and never will be upstream, and we do not carry it in rawhide. Every rebase is an opportunity to
check and see if nvidia has fixed their driver. As you can see, they have not.

I had brought in the patch for the hack with 6.1.5, but forgot the config changes to make the hack work. Everything will be working with 6.1.7 when it
comes out this week. So no, it has nothing to do with my trying to force users to switch hardware. It is just more hope that nvidia will fix their driver.

@Justin: Alles Cool man, passiert halt 😀

Mit Kernel 6.1.7 ist dann alles wieder im Günen Bereich. Bis dahin habt Ihr ja noch 6.0.18 zur Verfügung.