Neues aus der Linuxwerkstatt: Pipewire verantwortlich?

An manchen Tagen komme ich mir vor, als wenn ich eine Linuxwerkstatt hätte, statt einen PC mit einer Stableversion von Fedora. Da bin ich öfters im Redhat Bugtracker als auf meiner eigenen Webseite.

Neues aus der Linuxwerkstatt: Pipewire verantwortlich?

Der.. nein, sagen wir lieber „ein“ aktueller Fall in der Werkstatt ist das Unvermögen von Firefox Netflix über Wochen sauber abzuspielen ohne Probleme auf die oder andere Art zu produzieren.

Was war geschehen?

Am 2. Mai hatte Firefox beschlossen, daß ich zwar von Netflix den Ton hören dürfte, aber das Video wäre jetzt Privatsache vom Videodecoder. Die Bilder stockten also, insgesamt war alles im Firefox zäh wie Sirup. Die Probleme mit Netflix dauerten auch bis in den nächsten Tag an, wobei auch Webseiten sirupartig waren. Auf einem Ryzen 5600 mit RTX 4060 ist das eher kein Hardwareproblem.

Der Verdacht lag nahe, daß Firefox statt die GPU zu verwenden beschlossen hatte die CPU die ganzen bunten Dinge berechnen zu lassen, was zu immensen Performanceproblemen führen würde. Nach ein paar Stunden des selben Tages gab sich das Problem, was aber nicht an Firefox lag wie sich rausstellte.

Da es ein gstreamer Update gab, daß zeitlich korrelierte, habe ich mal ein Ticket im Bugzilla von Redhat aufgemacht, prompt hat sich da ein anderer User gemeldet, der ähnliche Probleme mit Firefoxplayback auf einer AMD RT 6800 hatte.

Die Zeit vergeht… alle sind ratlos

Die zeit vergeht, alle sind ratlos, dann schlägt das Schicksal erneut gnadenlos zu: Letzte Nacht stoppt Netflix mit dem gleichen Problem während ich ein Video mit OpenShot geschnitten habe. Also erstmal Firefox neugestartet, aber das half nichts. Dann gesagt: „nicht so wichtig“ und mich ums Video gekümmert. Das habe ich mir mit Celluloid ansehen wollen und was muß ich feststellen? Kein Videoplayback, nur Ton. „Oh oh“

Nichts geht mehr

Celluloid, MPV, Totem produzierten ALLE das gleiche Muster, nicht mal die Fortschritte auf den Zeitskalen wurden durchgezählt, die Videos zeigten nur das erste Bild vom Video was üblicherweise Schwarz ist, so daß man das nciht direkt merkt. Zum Glück hatte ich ein anderes Video das direkt ein Bild da hatte. Skippe man im Video rum, kamen auch anderen Standbilder raus.

Um Kernelprobleme auszuschließen habe ich rebooted, aber das half rein gar nichts. Alle Videoplayer zeigten das gleiche Bild ( sprichwörtlich ) … „wirklich alle?“ Nein, ein kleiner, oft völlig unbedachter Videoplayer trotzte dem Problem und spielte weiterhin alle Videos perfekt ab. Und an dem Punkt geht einem ein Licht auf.

Der Player war FFPLAY from FFMPEG Paket. Das heißt, alle anderen Videoplayer und Firefox müssen etwas gemeinsam haben: Pulseaudioplayback.

Der Workaround

Ums Kurz zu machen: sobald jemand via Pulseaudio auf das den HDMI Ausgang meiner Nvidiakarte wollte, stockte das Video, aber der Ton ging sauber durch, was  völlig GAGA ist, weil das kein bisschen was mit Grafiken zu tun hat.

Ich denke folgendes ist passiert: Pipewire läuft ja unter der Haube von Pulse und ist für Video und Audio zuständig. Das hat ein Problem mit dem HDMI Device gehabt. Das muß aber in der User-Config persistent gespeichert sein, also quasi blanker Unsinn im State File oder so etwas in der Art, weil es ja rebootfest war und das geht nur, wenn sich jemand den „Zustand“ von dem Device irgendwo auf der Platte merkt!

Ich habe dann einfach mal das Device via PulseAudio-Lautstärkeregler abgeschaltet, so daß alle Audiostreams über das Mainboard liefen und was soll ich sagen : 100% alle Probleme verschwunden. Alle Player funktionierten wieder 1a.

Nach dem das Ausgabegerät wieder auf dem selben Weg eingeschaltet wurde, liefen die Player auch mit dem HDMI Gerät wieder einwandfrei.

Im Bugtracker wird fleißig am Problem gearbeitet, sollte also bald gefixt sein.

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