Beim Upgrade von Debian 11 (Bullseye) auf Debian 12 (Bookworm) wurde das komplette System wie vorgesehen aktualisiert, lediglich das Zammad-Paket zeigte in der Weboberfläche die falsche Version:

Dies ist Zammad Version 6.1.0-1700492762.96ac5a60.bullseye

Was auf auch ein Anzeigefehler in Zammad hätte sein können, wurde von dpkg bestätigt

und apt zeigte keinerlei Motivation, das Paket zu aktualisieren.

Daß die eigentlich richtige Datei zur Installation zur Verfügung stand, bestätigte ein Aufruf von “apt-cache policy”

Trotz offensichtlich verfügbarer Bookworm-Installationsdatei hielt apt die Bullseye-Version für geeigneter. Die Suche nach der Ursache bzw. deren Lösung führte zum Beitrag “Distupgrade debian buster to bullseye - zammad still shows buster version” im Zammad-Forum, der für das Upgrade von Bullseye auf Bookworm noch genauso gilt. Dort erklärt MrGeneration vom Zammad-Core-Team:

Due to the way our version numbers are generated, you end up in

6.0.0-1692176490.0e2399eb.buster
6.0.0-1692176490.0e2399eb.bullseye

those versions. Versioning is done alphabetical. So buster vs bullseye apart from the rest of the version string being the same is your issue.

Das gleiche Verhalten tritt auch hier auf: beim Vergleich der beiden Versionen “6.1.0-1700492762.96ac5a60.bullseye” und “6.1.0-1700492762.96ac5a60.bookworm” ist apt nach Vergleich der Versionsnummern der Meinung, daß “bullseye” neuer als “bookworm” ist und behält deshalb die Bullseye-Version, statt auf die Bookworm-Version zu aktualisieren. Dies kann man auch mit dpkg evaluieren:

Die im oben verlinkten Beitrag vorgeschlagene Lösung eines “apt remove zammad” gefolgt vom einem “apt install zammad” ist zumindest im Fall des Upgrades von Bullseye auf Bookworm nicht notwendig, da Zammad auch in der Bullseye-Version problemlos arbeitet.

Mit der nächsten Änderung der tatsächlichen Versionsnummer wurde dann auch auch auf das Bookworm-Paket aktualisiert:

Gut gemeint ist nicht immer gut gemacht, so auch im Falle von GNOME und dessen Dateimanager Files: egal, ob die Ordner verwendet werden oder nicht, den freedesktop.org-Spezifikationen folgend werden bei jedem Login die XDG-Standard-Ordner wie z.B. “Musik” und “Videos” angelegt und auch in der Seitenleiste von Files angezeigt. Eine Möglichkeit, dies innerhalb der Oberfläche zu konfigurieren ist nicht vorgesehen.

This program reads a configuration file, and a set of default directories. It then creates localized versions of these directories in the users home directory and sets up a config file in $(XDG_CONFIG_HOME)/user-dirs.dirs (XDG_CONFIG_HOME defaults to ~/.config) that applications can read to find these directories. [Quelle]

Das Verhalten kann aber mit Hilfe von Konfigurationsdateien angepasst werden.

Ändern der Verzeichnisse

Wer den grundlegenden Mechanismus aktiviert lassen möchte, kann in der Datei “~/.config/user-dirs.dirs” die nicht benötigten Verzeichniseinträge auf sein “home”-Verzeichnis umbiegen.

Dies wird auch so vorgeschlagen:

To disable a directory, point it to the homedir. [Quelle]

Alternativ ist auch ein Auskommentieren der nicht benötigten Zeilen möglich, dies würde aber ggf. dazu führen, daß eine Applikation einen benötigten Ablageort nicht (mehr) findet.

Da “home” bereits exisitiert, werden Ordner, welche auf “$HOME” verweisen, nicht nochmal angelegt und auch nicht zusätzlich zum “Persönlichen Ordner” angezeigt. Das Verbiegen einer Variable mit dem Namen “XDG_PUBLICSHARE_DIR” auf “$HOME” hinterlässt aber auf Systemen, auf denen mehr als ein Benutzer aktiv ist, ein ungutes Gefühl.

Abschalten des Mechanismus

Alternativ (oder zusätzlich) kann der Mechanismus auch komplett stillgelegt werden.

At the moment there are only two settings, you can disable the whole thing, and you can specify the charset encoding used for filenames. [Quelle]

Dies kann entweder systemweit über die Datei “/etc/xdg/user-dirs.conf” gesteuert oder benutzerbezogen eingestellt werden.

Hierzu ist die Systemdatei zuerst ins Benutzerverzeichnis zu kopieren

dann kann die Einstellung “enabled” von “True” auf “False” geändert werden:

Bei der nächsten Anmeldung werden die Ordner nicht mehr neu angelegt und die Einträge in der Seitenleiste von “Files” sind verschwunden.

Als Copy & Paste-Vorlage …

Während auf anderen Geräten das GRUB-Menü in dem von Debian vorgesehenen Standard-Theme erstrahlte, wurde auf einem frisch installierten Laptop nur die Fallback-Darstellung in Cyan auf blauem Hintergrund gewählt:

Funktional ist dies zwar keine Einschränkung, aber die Neugier war geweckt und das “Warum?” wollte gelöst werden. Die Ausgabe von “update-grub” sah vollkommen normal aus, die Einbindung des Hintergrundbildes wurde auch explizit angezeigt:

Nachdem die in GRUB eingebauten Videotests alle erfolgreich waren und auch der Plymouth-Bootsplash wie erwartet angezeigt wurde, musste das Problem an einer anderen Stelle liegen - und so war es auch.

Den entscheidenden Hinweis lieferte der Debiag Bug Report #945404 “grub2-common: ‘/boot/grub/.background_cache.png’ is not created on LUKS encrypted system”: die Datenpartition des Laptops ist verschlüsselt und bei der Überprüfung des Hintergrundbildes erkennt das zuständige Skript nicht, daß beim Booten auf das Bild nicht mehr zugegriffen werden kann. Als möglicher Verursacher wurde Zeile 100 der Datei “/etc/grub.d/05_debian_theme” benannt:

It looks like the command ‘if is_path_readable_by_grub “${1}”; then’ in line 100 in ‘/etc/grub.d/05_debian_theme’ always returns “true”, and therefore ‘/boot/grub/.background_cache.png’ is never created. [Quelle]

“is_path_readable_by_grub” scheint entweder gar nicht zu funktionieren oder im konkreten Fall ein falsches Ergebnis zurückzuliefern.

Als einfacher Test bzw. Workround wurde das Ergebnis der Abfrage durch “false” ersetzt

und die Konfigurationsdatei neu erzeugt:

Nun wurde - wie erzwungen - davon ausgegangen, daß das Hintergrundbild zum Zeitpunkt des Bootens nicht lesbar sein würde und deshalb eine Kopie in einem für GRUB zugreifbaren Bereich erstellt.

Beim nächsten Bootvorgang wurde das GRUB-Menü dann auch mit Theme dargestellt. Ein vielleicht schönerer Workaround als die direkte Änderung der Datei “/etc/grub.d/05_debian_theme” ist im oben genannte Bug Report ebenfalls dargestellt.

Seit dem unrühmlichen Ende meines Nexus 5X war hier ein gebrauchtes Google Pixel der ersten Generation mit dem Betriebssystem LineageOS im Einsatz.

LineageOS ist zwar im Hinblick auf Datensparsamkeit ein Schritt in die richtige Richtung, in Sachen Sicherheit aber leider nicht mehr als ein Kompromiss: oft ist nicht klar, ob und wie vollständig Sicherheitspaches in das System integriert werden (dies variiert von Gerät zu Gerät und dem jeweiligen Maintainer) und auf Grund fehlender Quellcodes für die Blobs bleiben Teile des Systems nach Ende der offiziellen Wartung zwangsweise ungepatcht. Dazu kommt noch ein gravierender Nachteil: nach der Installation muss der Bootloader offen bleiben - das Smartphone sollte anschließend nach Möglichkeit nicht mehr aus den Augen gelassen werden, denn das Aufspielen eines Patchs oder Abziehen der Daten am Betriebssystem vorbei ist - je nach installierter Recovery - für einen Angreifer nur wenige Schritte entfernt.

Nachdem Google den 23. Geburtstag mit entsprechenden Rabatten feierte, rutschte der Preis des Pixel 4a in annehmbare Regionen. Bei dem Gerät handelt es sich um das bisher letzte Hosentaschengerät von Google, welches mit 5,8"-Bildschirm und mit dem Pixel fast identischen Gehäusemaßen (0,2 mm länger, dafür 0,1 mm schmaler) eine problemlos tragbare Alternative darstellt.

Nach wenigen Wochen mit dem Oiginalbetriebssystem von Google war klar: es ist zwar schön, was Google so alles an Komfortfunktionen bereitstellt, aber einen Großteil davon bezahlt man mit einem permanenten Daten(ab)fluss und es bleibt das Gefühl, permanent eine Wanze mit sich herumzutragen, die “Ich weiß, was Du letzten Sommer getan hast” besser beantworten kann, als man selbst. Somit ging die Suche nach einem alternativen Betriebssystem los, das nach Möglichkeit auch bessere Sicherheitsfeatures bieten sollte, als LineageOS.

Dank entsprechender Artikel des auf Sicherheit folussierten Blogs von Mike Kuketz endete die Suche bei GrapheneOS:

GrapheneOS ist ein auf Sicherheit und Datenschutz ausgerichtetes Open-Source-Betriebssystem mit Android-App-Kompatibilität.
…
Alle Komponenten, die für die Android-Basiskompatibilität nicht erforderlich sind, werden nicht integriert. GrapheneOS basiert demnach auf dem Android Open Source Project (AOSP), erweitert dieses aber um Funktionen und Maßnahmen, die die Sicherheit und den Datenschutz verbessern. [Quelle]

Der starke Fokus auf Sicherheit und Datenschutz zeigt sich in vielen Details: der Bootloader kann und soll nach Installation wieder geschlossen werden; WiFi und Bluetooth können systemseitig gestoppt werden, wenn für einen einstellbaren Zeitraum keine Verbindung (mehr) besteht; Systemupdates (sowohl Sicherheitsaktualisierungen als auch Versionsupdates) erscheinen teilweise früher als sie für die Google-Geräte verfügbar sind und genau wie beim System aus Mountain View reicht ein Neustart, um in das aktualiserte System zu wechseln. Auch ansonsten gibt es viele durchdachte Details, wie z.B. den eigenen App-Store, über den einige Graphene OS-eigene Apps installier- und aktualisierbar sind und auch die Möglichkeit, den Portal-Check beim Neuverbinden auf Graphene OS- statt der Google-Server umzustellen. Zum Surfen gibt es einen eigenen, auf Chromium basierenden Browser mit stets aktualisertem Webview.

Sofern man über einen Fehler stolpert, kann dieser im projekteigenen Github-Issue-Tracker gemeldet werden und zumindest die eigene Erfahrung zeigt, daß sich auch zeitnah jemand kümmert. Eine deutlich angenehmere Erfahrung als meine Fehlermeldung bei Google bzgl. der Funkverbindung meines “Nexus 4”, zu der ich wohl auch inzwischen keine Reaktion oder einen Fix mehr erwarten darf.

Als Alleinstellungsmerkmal bietet Graphene OS an, über den eigenen App-Store sogenannte “Sanboxed Google Services” zu installieren, also die Google eigenen Dienste inklusive PlayStore nachzuinstallieren. Diese laufen dann aber nicht - wie beim Originalsystem - mit Systemrechten somit fast uneingeschränktem Zugriff, sondern laufen nur mit den Rechten einer “normalen” App, was die Zugriffsmöglichkeiten deutlich einschränkt.

Mein Nutzungsprofil unterscheidet sich wahrscheinlich deutlich von dem der meisten Smartphone-Nutzer: ich verwende das Gerät hauptsächlich zum Telefonieren und als tragbaren Kalender und Kontaktverwaltung. Instant Messenger - egal, ob sie Signal, Threema oder WhatsApp heißen - sind bei mir nicht installiert, ich fand solche Dienste schon zu Zeiten von ICQ absolut überflüssig.

Die “Sanboxed Google Services” sind bei mir mangels Bedarf nicht installiert. Als Appstore kommt neben dem Graphene OS-eigenen lediglich F-Droid zum Einsatz, welcher eine ganze reihe frei verfügbarer, quelloffener Apps bündelt:

• DAVx5: Synchronisation von Kontakten und Kalendereinträgen mit der Nextcloud-Instanz

• Gadgetbridge: Companion-App zur Verbindung von Smartwatches wie z.B. der Pebble2 mit dem Smartphone

• KeepassDX: hat nach einigen Jahren auf Grund erweiterter Funktionalität das bisher installierte KeepassDroid ersetzt

• K-9 Mail: wenn auch zwischenzeitlich etwas angestaubt, ist K-9 Mail seit meinen ersten Schritten auf Android ein zuverlässiger Begleiter, mit dem ankommende Mails zumindest gelesen werden

• Music Player GO: die Auswahl an Musikplayern ist riesig, aber viele davon werden nur mäßig bis gar nicht geplegt. Der “Music Player Go” ist schlank, erhält regelmäßig Updates und sieht gut aus

• Nextcloud, Nextcloud News und Nextcloud Notizen: Kontakte, Kalender und Notizen werden über eine Nextcloud-Instanz synchronisiert

• OpenTracks: ideal, um ab und an eine Wanderung oder eine Radtour mitzutracken. Keine GPS-Daten, die in Richtung Cloud wandern, sondern auf dem Gerät bleiben

• Privacy Browser: auf dem System-Webview aufsetzende Browseroberfläche, welche bereits einige Filterlisten eingebaut hat und domänenspezifische Konfigurationseinstellungen (Javascript, Cookies, User Agent, …) mitbringt

• Schlichter Kalender: eine der sog. “schlichten Apps”, die funktional hochwertig und ohne Werbung sind

Auch wenn sich Graphene OS für den Produktiveinsatz uneingeschränkt eignet, so ist eine Baustelle anfangs irritierend: alle neu hinzugefügten (oder geänderten) Einstellungsmöglichkeiten und Apps sind zum aktuellen Zeitpunkt ausschließlich in englischer Sprache erhältlich, was sich stellenweise seltsam anfühlt. Auch wären ein paar zusätzliche Konfigurationsmöglichkeiten, wie z.B. den Eintrag eines privaten Portalservers zum “Internet Connectivity Check” wünschenswert. Aber das sind letztendlich Wohlfühl-Detailverbesserungen an einem ansonsten hervorragenden Produkt.