Nach 3 Stunden sinnloser Verringerung meiner Lebenszeit möchte ich ggf. anderen das Gleiche ersparen... ;-)
lokaler Hintergrund: Ich beziehe mein $HOME per NFS, trenne dort die einzelnen Rechner/Settings per XDG-Umgebungsvariablen, Firefox durch Profile in Verbindung mit einem lokalen Weave-Server zum Synchronisieren. Fallstrick bei meinem NFS-Server (unfsd statt kernel-nfsd) ist, daß dieser kein netzwerkweites Locking unterstützt. nolock bei den Mountoptionen umgeht dies aber zuverlässig. Ich arbeite also unter gleichem Usernamen(und $HOME) auf verschiedenen Rechnern...
Das funktionierte prächtig bis ich heute alle Rechner updatete.
An meinem Arbeits-PC konnte ich dann den Firefox nicht mehr starten. Bei mehr als eibnem Profil geht automatisch der Profilmanager (firefox -ProfileManager) auf. Dieses Fenster blieb aber bis auf den Rahmen vom Windowmanager leer.
So, was habe ich nun die 3 Stunden alles probiert...:
a) pacman.log studiert, ok FF-Update, kein Downgrade da es an anderen Rechnern problemlos funktionierte (selber User per NFS)
b) Neuer User auf dem Problemrechner, FF funktioniert auch per NFS...
c) strace-Auszüge verglichen, 50% nicht verstanden <g>, aber gesehen das einmal zuwenig die profiles.ini durch den FF geöffnet wird...
d) Arbeits-PC FF-Profil gesichert, gelöscht und mit einem frischen begonnen -> Fehlanzeige, nur Rahmen des WMs...
e) Da der Effekt ähnlich war als wenn ich NFS-Locking-Probleme habe alle lokalen, pc-bezogenen Caches gelöscht, NFS-Server neu gestartet, alle PCs runtergefahren, immer noch das selbe Problem am Arbeits-PC...
f) Gedanklich hatte ich mich schon auf ein dbus-Problem eingeschossen (frage mich zwar warum, aber... <g>) und war nahe dran das Backup von gestern zurückzuspielen...
g) Überlegt, was die anderen Rechner den vom Arbeits-PC unterscheiden... Hmm, Grafikkarte... Gut, es gab ja ein nvidia-Treiber-Update. Aber ein neuangelegter User hat die Probleme nicht. Es muß also etwas in meinem $HOME sein...
So, und hier die Lösung:
Nachdem ich nochmal alle Verzeichnisse mir angeschaut hatte fiel mir das $HOME/.nv auf. Dort gab es zwei "Profile":
./GLCache/ebae222b91aeac249297208bdf5b6632
./GLCache/ec6f932fae7d95e478bbdf2897444f22
mit jeweils *.bin und *.toc Files (ich hasse diese kryptischen 12345.toc Files, v.a. wenn ich nicht weiß woher die kommen...)
Ich also das $HOME/.nv weggesichert und gelöscht, tataaa, FF startet wieder auf dem Problem-PC wie eh und je...
Ich frage mich natürlich, wo kommt dieses Verzeichniss her (und haben evtl. doch die Illuminaten was damit zu tun <g>). nv läßt natürlich nvidia naheliegen. Andere PCs mit meinem User (und FF) lassen daß Verzeichniss nach dem Löschen nicht wieder erscheinen. Auch mein Nvidia-PC hat es nicht z.B. nach Start des Windowmanager (also X plus nvidia).
Erst ein Start des Firefox erstellt hier $HOME/.nv. DAS also war des Pudels Kern...
Durch das nvidia-Update wurde zwar (Datum) ein neues Dir $HOME/.nv./GLCache/ebae222b91aeac249297208bdf5b6632 erstellt, aber eben leer während die *toc und *.bin Files im anderen noch von älteren Boots waren. Erst das Löschen/Leeren des gesmten .nv Verzeichnissen brachte die ersehnte Lösung.
Das muß jetzt nichts Firefox-spezielles sein, aber beim Rendern nutzt FF wohl auch GL-Funktionen. Ich hätte wohl auch mit anderen GL-Anwendungen in das Problem rennen können....
Also die Kurzfassung:
Nvidia-User (mit dem nvidia-Treiber), bei denen Applikationen nur den Rahmen des Windowmanagers - aber eben nicht das Programm selbst - anzeigen: Löscht euer $HOME/.nv Verzeichniss!