Bein Verfassen des Beitrags “Sechs Jahre Debian” stellte sich die Frage, wie der Installationszeitpunkt eines Linux-Systems herauszufinden ist. Die einfachste Variante ist wahrscheinlich der Befehlt “stat /”, welcher in der Ausgabe-Zeile “Geburt …” die gewünschte Information anzeigt:

Handelt es sich um ein Debian-basiertes System, so kann der Blick in das Verzeichnis “/var/log/installer/” ein paar zusätzliche Informationen liefern:

Die Datei “lsb-release” gibt hierbei auch Informationen zum verwendeten Installationsmedium:

Seit mehr als sechs Jahren ist hier auf den Desktop-Systemen Debian Linux im Einsatz und das Fazit aus “Debian - ein Erfahrungsbericht” hat sich nicht geändert:

Debian is a bit boring in a good way.
Quelle

Installieren, konfigurieren und anschließend die Kiste einfach für das verwenden, für was sie angeschafft wurde - ohne sich ständig mit dem Unterbau beschäftigen zu müssen - für manche(n) pure Langeweile, für mich genau die richtige Wahl.

Eines der Argumente, die gegen Debian Stable auf dem Desktop immer wieder aufgegriffen werden ist die “alte” Software. Hier gabelt sich der Weg zwischen Aktualität und Stablilität, denn wenn während Rolling-Release-Distributionen neue Pakete direkt verteilen, sobald sich die Versionsnummer ändert, so erfolgt bei Debian der Wechsel ungefähr alle zwei Jahre.

Zu diesem Zeitpunkt gibt es Software, die schon einige Wochen oder Monate in Testzyklen vebracht hat und deren Versionsnummer(n) natürlich zum Release-Zeitpunkt ggf. bereits hinterherhinken. Dafür steigt die Wahrscheinlichkeit, daß die meisten schwerwiegenden Bugs gefunden und behoben wurden und man mit dem Upgrade wieder eine stabile Systembasis für die nächsten Jahre erhält.

Sollte tatsächlich einmal eine aktuellere Version einer Software benötigt werden, so hilft ein Blick in die Backports, in denen für die aktuelle Stable-Version rückportierte Versionen aus “Testing” angeboten werden.

Die bisherigen Upgrades liefen probemlos, trotzdem kann vor einem Systemupgrade ein Blick in die Release-Notes (hier insbesondere in die Upgrade-Hinweise) nicht schaden, genauso wie auch in die Liste der möglichen Probleme. Ab und an fällt ein Paket weg, das man vielleicht selbst noch verwendet oder es kommt zu einem größeren Umbau - dann schadet es nicht, sich vorher darüber bewusst zu sein.

Im Desktop-Umfeld habe ich bisher nur den Wechsel Buster → Bullseye → Bookworm → Trixie hinter mich gebracht, aber der älteste von mir betreute produktive Server zeigt als Installationsdatum den 07. Dezember 2012 an, damals installiert auf Basis des “Testing”-Releases von Debian Wheezy.

Durch den Sprung von rund zwei Jahren ändert sich natürlich mit dem Upgrade so einiges bei der eingesetzten Software, was an und an zu Nacharbeiten führt. Beim für diesen Blog eingesetzten Static Site Generator Hugo sprang die Software-Verion z.B. von 0.111 auf 0.131, was natürlich einige Nacharbeiten mit sich brachte. Auf der anderen Seite kann man anschließend wieder zwei Jahre bis zum nächsten Wechsel arbeiten und hat “Breaking Changes” nicht alle paar Wochen oder Monate als Überraschungspaket.

Als Grundausstattung kommt zum Großteil nur zur Distribution gehörende Software zum Einsatz, lediglich drei Fremdprogramme sind installiert: Sublime Text (das als native Linux-Version existiert) sowie Adobe Photoshop CS5 und Exact Audio Copy (die Dank Wine ihre Arbeit auch klaglos verrichten).

Auch in Sachen Spiele ist Dank GOG und Steam so einiges möglich, wobei auf Grund der Tatsache, daß unter dem Schreibtisch ein Mini-PC steht, nur moderat grafiklastige Software zum Einsatz kommt.

In Sachen Hardware gab es bisher auch noch keine Enttäuschung: egal, ob die Cherry-Tastatur, die Logitech Funkmaus oder die mittels Daisy-Chaining angebundenen Bildschirme: alles läuft problemlos.

Da kann man eigentlich nur einen großen Dank an das gesamte Team aussprechen und ab und an auch eine Spende nicht vergessen!

Werden Umgebungsvariablen auch außerhalb Terminal-Sitzung benötigt, so reicht es nicht, diese z.B. in die Datei “.bashrc” einzutragen. Das Setzen von

bewirkt zwar, daß sich alle QT-Programme an die Vorgabe halten, sofern diese über die Kommandozeile gestartet werden. Erfolgt der Start aber über einen anderen Weg, ist die Variable aus der Sicht dieser Programme nicht gesetzt und wird somit auch nicht berücksichtigt.

Wurden solche Definitionen früher in der Datei “/etc/environment” systemweit vorgenommen, lassen sich auf Systemen mit systemd die Variablen auch mit Hilfe einer Konfigurationsdatei in einem der “environment.d”-Ordner setzen:

Configuration files in the environment.d/ directories contain lists of environment variable assignments passed to services started by the systemd user instance.

Mit Hilfe einer “conf”-Datei im Verzeichnis “~/.config/environment.d/” können Variablen auch benutzerbezogen bzw. durch den Benutzer selbst gesetzt werden:

Als Copy & Paste-Vorlage …

Debian 13 “sources.list” mit “main”, “contrib”, “non-free” sowie “non-free-firmware” aktiviert:

Alternativ die “debian.sources” im deb822-Format, welche mit “apt modernize-sources” aus der “sources.list” erzeugt werden kann:

Wer die Quell-Pakete aktivieren möchte, muß in der “sources.list” die entsprechende(n) Zeile(n) entkommentieren bzw. in der “debian.sources” hinter “deb” noch ein “deb-src” einfügen.

Nach einem Betriebssystem-Update von Debian 11 auf Debian 12 wollte Torchlight 2, das vor dem Update problemlos lief, nicht mehr starten: nach dem Klick auf das Icon erschien nur noch kurz der Spash-Screen … und das war’s - vom eigentlich erwarteten Startschirm fehlte jede Spur.

Als erste Möglichkeit zur Fehlersuche bietet sich meist ein Start des Programms über die Kommandozeile an, in der Hoffnung, dadurch vielleicht in paar Statusmeldungen zu sehen. Dies funktioniert auch beim Start von Torchlight 2, welches eine ganze Menge an Meldungen ausgab, bevor es letztendlich mit einem “Speicherzugriffsfehler” abbrach.

Leider führte die Kombination von “Torchlight 2” und “Speicherzugriffsfehler” bei der Suche nach Lösungsmöglichkeiten nicht zu hilfreichen Ergebnissen. Auch Tips, die in Richtung von Bibliothekskonflikten gingen halfen nicht, das Programm wieder zum Starten zu bewegen.

Zum Ziel führte letztendlich ein Blick in die Datei “ogre.log”, die auf den ersten Blick identisch mit den Ausgaben beim Programmstart aussieht, allerdings noch ein paar zusätzliche Ausgaben enthält:

So war der entscheidende Hinweis zwischen den Zeilen “Loading library RenderSystem_GL” und “Path for saving is” versteckt, im konkreten Fall ein

der sich durch Installation des Pakets libglu1-mesa letzendlich leicht beheben ließ.