Wieder was gelernt: apt-pinning

Nicht jedes Update bietet zwangsläufig Verbesserungen, manchmal gibt es auch unerwünschte Nebenwirkungen, wenn man ständig up-to-date sein will.Ich habe das mit dem proprietären nVidia-Treiber 304.37 erfahren.

Zuerst zeigten sich die Symptome bei gtk-redshift. Im Abstand von etwa zehn Sekunden schaltete es für eine halbe Sekunde auf 6.300 Kelvin, anschließend wieder zurück auf den von mir abends bevorzugten Wert von 4.900 Kelvin, was eine ziemlich nervige Flackerei ergab.
Beim vorhergehenden Treiber 302.17 gab es dieses Farbspiel nicht. Nach einigem Probieren und Suchen fand ich eine Lösung. gtk-redshift bietet verschiedene Modi, die man mit dem Parameter -m beim Aufruf einstellen kann. Die Modi werden angzeigt mit

redshift -m list

Es werden alle verfügbaren Modi angezeigt, bei mir sind es randr (default) und vidmode. Da randr eben nicht fehlerfrei lief, rief ich gtk-redshift mit vidmode auf

gtk-redshift -l 52.5:13.4 -t 6300:4900 -m vidmode

Diesen Aufruf habe ich in den KDE-Systemeinstellungen unter „Autostart“ eingetragen, er funktioniert tadellos.

Auf das nächste Problem stieß ich heute eher zufällig, als ich Googleearth starten wollte. Zuerst tat sich gar nichts, dann rief ich Googleearth im Terminal auf. Die Fehlermeldung lautete sinngemäß, dass Googleearth bereits laufe, anderenfalls es sich um einen Fehler handele und ich ~/.googleearth/instance-running-lock löschen soll.

Das tat ich, denn

ps -A|grep google

lieferte kein Ergebnis, also war da auch kein Prozess für die Anwendung googleearth aktiv.

Das Programm startete nun. Aber es fehlte der für die Anwendung nicht unwesentliche Erdball. An dessen Stelle blinkte nur hilflos ein winziger weißer Punkt. Keine Fehlermeldung im Terminal, nichts. Eine Neuinstallation brachte keine Änderung.

Auf dem Netbook ließ sich Googleearth installieren, und mit 32bit und der Intel-Grafik läuft es. Ich vermutete also, dass der Grafiktreiber nVidia 304.37 der Übeltäter sein müsste, was bedeutet, dass ich den Treiber auf die letzte, mir bekannte funktionierende Version downgraden muss. Nach ein wenig Probieren und Lesen fand ich die für mich brauchbare Methode: Downgrade und Halten der betroffenen Pakete mit apt-pinning. Über dieses pinning lassen sich verschiedene Paketquellen bevorzugen. Ich entschied mich, die betreffenden neun Pakete mit der letzten funktionierenden Versionsnummer in der Datei /etc/apt/preferences aufzulisten:

Package: nvidia-glx
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-settings
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-xconfig
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-kernel-dkms
Pin: version 302.17*
Pin-Priority: 1000

Package: libgl1-nvidia-glx
Pin: version 302.17*
Pin-Priority: 1000

Package: xserver-xorg-video-nvidia
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-vdpau-driver
Pin: version 302.17*
Pin-Priority: 1000

Package: nvidia-alternative
Pin: version 302.17*
Pin-Priority: 1000

Package: libgl1-nvidia-glx-ia32
Pin: version 302.17*
Pin-Priority: 1000

Die Datei kann mit einem beliebigen Editor erstellt werden, wichtig sind die Leerzeilen zwischen den einzelnen Abschnitten. Außerdem sollte man die Datei root übereignen, also den Editor einfach gleich mit root-Rechten aufrufen.

Jetzt braucht es nur noch einen kleinen Befehl in der Kommandozeile, und der proprietäre nVidia-Treiber 304.37 ist Geschichte und durch 302.17 ersetzt:

su
apt-get update && apt-get dist-upgrade
reboot

Reboot ist hier angesagt, weil es die einfachste Methode ist, das Kernelmodul für den nun geänderten Treiber zu laden.

Das apt-pinning über die Versionsnummer verhindert, dass bei künftigen dist-upgrades die eben installierten älteren Pakete wieder durch neuere als 302.17 überschrieben werden. Auch wird verhindert, dass diese Pakete bei Abhängigkeitsproblemen gelöscht werden. Wenn ich doch eine neuere Version des proprietären Treibers installieren will, gibt es eine einfache Lösung:

su
mv /etc/apt/preferences /etc/apt/preferences.nvidia.old
apt-get update && apt-get dist-upgrade
reboot

Die Datei /etc/apt/preferences ist damit nicht gelöscht, sondern nur umbenannt und wird daher nicht berücksichtigt. Durch eine erneute Umbenennung zum ursprünglichen Namen kann ich bequem den alten funktionierenden Treiber wieder installieren, falls eine neue Version doch nicht zündet.

Die Geschichte vom apt-pinning ist hier schneller niedergeschrieben, als sie praktisch gedauert hat. Es war schon einige Zeit für Recherche und Probieren nötig. Letztendlich hat es sich aber gelohnt, denn ich habe wieder etwas über die Mechanismen innerhalb der Paketverwaltung gelernt. Und das Ausprobieren an einem konkreten Fall ist einprägsamer als jedes noch so intensive Studium der einschlägigen man-pages und Websites, möchte ich meinen.

Werbeanzeigen