• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

extension "GLX" missing on display ":0" mit NVIDIA 340.32

Keine Ahnung ob noch weitere das Problem haben werden, allerdings hatte ich das Problem beim aktualisieren auf den aktuellsten nvidia Treiber, und vielleicht hilft meine Lösung ja dem einen oder anderen verzweifeltes Stundenlanges suchen.

Nach der Meldung habe ich mir jedenfalls mal die log Datei /var/log/Xorg.0.log genauer angeschaut und dabei sind mir folgende Zeilen aufgefallen:

Loading /usr/lib64/xorg/modules/updates/extensions/libglx.so
[ 4.779] (EE) Failed to load /usr/lib64/xorg/modules/updates/extensions/libglx.so: /usr/lib64/xorg/modules/updates/extensions/libglx.so: cannot open shared object file: No such file or directory
[ 4.779] (II) UnloadModule: "glx"
[ 4.779] (II) Unloading glx
[ 4.779] (EE) Failed to load module "glx" (loader failed, 7)

Ein genauer Blick auf besagte Datei zeigt, dass diese auf
/usr/lib64/xorg/modules/updates/extensions/libglx.so.340.32
verlinkt ist, welche allerdings nicht existiert. Scheinbar hat sich hier ein kleiner Fehler eingeschlichen bei dem .rpm Package.

Allerdings existiert eine weitere Datei unter
/usr/lib64/xorg/modules/updates/extensions/nvidia/nvidia-libglx.so

Also einfach auf diese Datei Verlinken, neustarten, und das ganze sollte wieder funktionieren. Zumindest wars bei mir so.
Code:
ln -s /usr/lib64/xorg/modules/updates/extensions/nvidia/nvidia-libglx.so /usr/lib64/xorg/modules/updates/extensions/libglx.so
 

Pitti 1

Hacker
Recht herzlichen Dank! :thumbs:

Genau vor diesem Problem stand ich bis vor wenigen Minuten.
Ich war gerade dabei, hier im Forum einen "Hilferuf" zu starten, als ich diesen Beitrag gefunden hatte...

Für die 32 - Bit Variante sieht die Kommando-Zeile dann so aus (vorher den "toten" Link entfernen):

Code:
ln -s /usr/lib/xorg/modules/updates/extensions/nvidia/nvidia-libglx.so /usr/lib/xorg/modules/updates/extensions/libglx.so
Danach "Neustart" und unter Systemeinstellungen -> Arbeitsflächeneffekte -> Erweitert kurzzeitig den Composit-Typ wechseln und wieder zurückstellen - "Anwenden" bestätigen und alles wird gut...

:)
 

spoensche

Moderator
Teammitglied
Nach dem anlegen des Symlinks brauchst du den Rechner nicht neustarten. Ein neustarten des X-Servers ist völlig ausreichend. Mit STR+ALT+2*BACKSPACE kannst du den X-Server neustarten.

Nachteil des Symlinks ist, dass er nach der Deinstallation des Treibers auf eine nicht existente Datei verlinkt und der X-Server wird sich daher wieder lautstark bei dir beschweren.

Statt setzen des Symlinks ist es sinnvoller die xorg.conf zu überprüfen und den mittels
Code:
ModulePath "/usr/lib/xorg/modules, /usr/lib/da/wo/fehlendes/modul/zuhause/ist"

dem X-Server sagen, dass er zusätzlich noch in einem anderen Verzeichnis nach Modulen suchen soll.
 
OP
C

cyborg78sbg

Newbie
Nunja, die xorg.conf sollte doch unter
zu finden sein, richtig? Zumindest wars früher immer so.

Es wird zwar noch eine Datei mit dem Namen
xorg.conf.nvidia-xconfig-original
erzeugt (und die Datei ist leer), aber das Problem bei mir ist, dass die xorg.conf nicht mehr existiert, und ich sie auch sonst nirgendwo mehr finden konnte.

Somit war das mit dem Verlinken für mich der praktikabelste Weg.

Aber danke für den Shortcut für den X-Server Reboot. Ich wusste zwar, dass es einen gibt, aber ich kannte ihn nicht, und Neustart ging schneller als lang danach suchen. :)
 

Pitti 1

Hacker
Ohne jetzt weiter auf die letzten beiden Beiträge eingehen zu wollen, fiel mir dennoch auf, dass unter Systemeinstellungen -> Anzeige und Monitor -> Bildschirmsperre die installierten Open-GL Bildschirmschoner, die expizit mit "GL" gekennzeichnet sind, seit dem update nicht mehr funktionieren! Der Rest funktioniert zumindest seit der Korrektur :



Ich kann mich allerdings frühestens ab Dienstag kommender Woche näher damit beschäftigen - selbstverständlich mit einem neuen Thema! ;)
 

josef-wien

Ultimate Guru
spoensche schrieb:
STR+ALT+2*BACKSPACE
Auf diese Methode sollte man nur zurückgreifen, wenn sonst nichts mehr geht, dadurch werden alle im grafischen System laufenden Anwendungen brutal niedergeknüppelt. Ein simples Ab- und Anmelden erfüllt den Zweck besser.

Bei fglrx und nvidia existiert planmäig eine Verknüpfung libglx.so im Verzeichnis /usr/lib64/xorg/modules/updates/extensions/, die auf die tatsächliche Datei zeigt, welche im Unterverzeichnis fglrx bzw. nvidia liegt. Somit ist aus meiner Sicht die Korrektur der falschen Verknüpfung der richtige Weg, und ich stimme
cyborg78sbg schrieb:
Scheinbar hat sich hier ein kleiner Fehler eingeschlichen bei dem .rpm Package.
zu.

P. S. Der Standard-ModulePath lautet gemäß /var/log/Xorg.0.log "/usr/lib64/xorg/modules/updates,/usr/lib64/xorg/modules", und damit werden auch die im Unterverzeichnis extensions vorhandenen Dateien gefunden.
 

Pitti 1

Hacker
Offenbar wurde es auch bemerkt, denn soeben kam ein erneutes update herein, das diesmal auf Anhieb funktionierte.
 
OP
C

cyborg78sbg

Newbie
Jup,

diesmal wird auf dieselbe Datei verlinkt wie schon vorhin, nur, dass diese diesmal vorhanden ist. :)

linux-hhvz:/usr/lib64/xorg/modules/updates/extensions # ls -l
total 10736
lrwxrwxrwx 1 root root 16 Aug 17 08:57 libglx.so -> libglx.so.340.32
-rwxr-xr-x 1 root root 10989992 Aug 16 16:10 libglx.so.340.32
 

spoensche

Moderator
Teammitglied
@cyborg:

Die frühere xorg.conf ist in mehrere Dateien gesplittet worden und der X-Server konfiguriert sich beim Start autom. selbst, sofern keine Konfiguration vorliegt. Die einzelnen Dateien befinden sich unter /usr/share/X11/xorg.conf.d. Zwecks überschreiben kopiert man die jeweilige Datei nach /etc/X11/xorg.conf.d und editiert sie anschließend.
 
Oben