Gnome-fallback-login-bug: PPA aktivieren

[Rüdiger Kupper]

Querverweis: #4

Die GNOME-Fallback-session hat definitiv einen Bug, der bewirkt, dass der Session-Login hängt, wenn der test auf Grafikbeschleunigung fehlschlägt (was er logischerweise tut, denn warum sonst sollte man die Fallback-Session verwenden??)

Der Bug fällt offenbar nur ins Gewicht, wenn man sich remote einloggt:

• über VNC
• von einem LTSP-Thin-Client
• über ssh

Bei einer direkten lokalen Sitzung tritt er irgendwie nicht auf, was anscheinend der Grund dafür ist, dass sich niemand darum kümmrt, diesen Bug zu beheben (er ist bei uns mit 13.10 aufgetaucht und existiert noch immer in 14.04 LTS.)

An unseren LTSP-Terminals habe ich den Bug bisher damit umgangen, dass ich in der lts.conf einen X-Parameter setzte, der die Beschleunigung von vornherein deaktiviert: source:keplertools/LTSP-setup/trunk/lts.conf@719:20. Damit klappte zwar der Login, doch jede Hardwarebeschleunigung war deaktiviert.

Da dieses Problem auch den Login vom Raspberry Pi betrifft, den ich heute getestet habe, habe ich erneut nach diesem Problem gesucht und tatsächlich einen Bugreport mit funktionierender Lösung gefunden: ​launchpad:1251281.

Hier hat jemand den Fehler identifiziert und stellt einen Backport der aktuellen GNOME-Bibliotheken als
PPA zur Verfügung. Sowohl auf dem Raspberry Pi wie auch auf dem neuen ltsp8 (14.04 LTS) löst das das Login-Problem. Die Option in der lts.conf kann entfallen und die Hardwarebeschlenigung läuft (zum ersten mal seit Jahren) richtig auf unseren Clients.

Aufgabe: Das PPA auch auf den anderen Servern aktivieren.

[bau]

Test verschiedener Clients:

• AMD Athlon X2 / ATI Radeon (ehemaliger LTSP-Server): Youtube flüssig im Vollbild
• Intel DualCore / PCIe-Grafikkarte: Youtube flüssig im Vollbild

Wie sollen wir also weiter vorgehen?
Ich denke fast, dass unsere Pentium IV zu langsam sein werden, gut wären irgendwelche DualCores, die sind offensichtlich schnell genug. Problem: Die Boards brauchen den längeren Mainboardstecker - unsere Gehäuse haben nur den kurzen :-(

[Rüdiger Kupper]

Dual Core sind mit Sicherheit gegenüber Single-Core-Prozessoren im Vorteil, selbst, wenn sie langsamer getaktet sind.

Aber waren Deine YouTube-Tests mit dem Serverbasierten oder dem lokalen Firefox?

[bau]

Es war jeweils der lokale Firefox

[Rüdiger Kupper]

Tsss, sieht so aus, als ob das Problem des nicht-ausloggen-könnens mit den oben erwähnten Backports zusammenhängt. Hier steht's (comment 4): ​https://bbs.archlinux.org/viewtopic.php?pid=1344528#p1344528.

In den normalen trusty-sourcen ist gnome-session 3.9.90. Im PPA des Nutzers, der den fix für die Grafikbeschleunigung zur Verfügung stellt, ist ein Backport von gnome-session 3.12.0. Und laut dem Forumskommentar wurde mit 3.10 der nötige Logout-Dialog entfernt.

Das ganze ist auch deswegen nervig, weil wir den Gnome-Logout-Knopf eigentlich nur deshalb brauchen, weil plank (unsere aktuelle Seitenleiste) wiederum den normalen Logout über das Zahnradsymbol verhindert.

Derzeit sehen die Optionen also so aus:

• keine Grafikbeschleunigung haben, dafür Plank verwenden können und mit dem Gnome-Knopf ausloggen
• Grafikbeschleunigung haben, aber Plank nicht verwenden und mit dem Zahnradsymbol ausloggen

Oder die Entwickler treten, dass sie einen dieser beiden Bugs beheben!
Nervig!

[Rüdiger Kupper]

Habe ein kleines Logout Skript geschrieben, das die GNOME-Session so freundlich wie möglich verwendet. Das können wir auf den Desktop/das Panel packen, bis der Bug behoben wurde.

[Rüdiger Kupper]

Das Skript besteht nur aus dem *.desktop-Starter und befindet sich in source:keplertools/LTSP-setup/trunk/logout-workaround.desktop

[Rüdiger Kupper]

Mit der anstehenden Virtualisierung aller Server erhalten alle Server das entsprechende Update, wenn sie die Trusty-Maschine wiederherstellen.

[Rüdiger Kupper]

Super, der Mensch, der die GNOME-Backports zur Verfügung stellt, arbeitet offenbar aktiv daran, dass seine Fixes in die laufenden Ubuntu-Paketquellen kommen: ​https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1251281/comments/20

Und was mir beim update am Mittwoch Probleme bereitet hat, ist wohl das hier:

Notes:

• If you installed previously backported packages from my PPA, you will need to downgrade them manually or "re-install" my PPA using ppa-purge and add-apt-repository.

Das habe ich natürlich nicht gemacht, daher waren (sind)?) einige Pakete in inkonsistentem Zustand, und ich musste in einem Skript manuell Änderungen vornehmen.

TODO

Bei nächster Gelegenheit das PPA mittels ppa-purge deinstallieren und neu installieren.

[Rüdiger Kupper]

Replying to kup:

TODO

Bei nächster Gelegenheit das PPA mittels ppa-purge deinstallieren und neu installieren.

Erledigt.

[Rüdiger Kupper]

Musste das PPA nach einem allgemeinen Update wieder purgen, da der Windowmanager nicht mehr funktionierte. Habe jetzt keine Zeit mehr, es neu zu installieren, daher laufen die Clients erst einmal wieder ohne 2D-Beschleunigung.

Hoffentlich ist das Intel-Grafik-Problem ja ohnehin bald Geschichte. Was soll eigentlich im COmputerraum oben geschehen, kommt da dann auch neue Hardware hin?

[bau]

Derzeit habe ich nur Hardware für die Klassenzimmer, das LZ und einige Fachräume gekauft.
Als nächstes stelle ich mir vor, dass wir die dummen Windoofs-Rechner in den unteren PCRäumen
ersetzen (vielleicht mit Restgeldern am Ende des Jahres). Möglichst bald möchte ich dann auch Hardware für die oberen Räume beschaffen - kostet halt eine Stange Geld :)

[Rüdiger Kupper]

Das PPA bleibt vorerst deaktiviert. Die alte Hardware sollte nach und nach verschwinden.