Schlagwort: postmarkeros

Regain Control: Wem dient dein Smartphone?

Ein Smartphone kann dir gehören und trotzdem den Interessen anderer dienen. Du hast es bezahlt, hältst es in der Hand und darfst über Kratzer und Hülle entscheiden. Aber wer entscheidet über Updates, vorinstallierte Dienste, Datenerfassung, Bootloader und Lebensdauer?

Genau deshalb ist die neue Formulierung auf der postmarketOS-Webseite stark: nicht bloß „Full Control“, sondern „Regain Control“ – Kontrolle zurückgewinnen. Der Satz erkennt an, dass Kontrolle längst verteilt wurde: an Hersteller, Plattformen, Werbenetzwerke und geschlossene App-Ökosysteme.

Eigentum am Gehäuse reicht nicht

Kontrolle besteht aus mehreren Ebenen. Quellcode muss prüfbar sein. Software muss verändert und ersetzt werden können. Daten und Dienste müssen exportierbar sein. Und es braucht einen Rückweg, wenn eine Änderung scheitert.

Open Source garantiert das nicht automatisch. Ein öffentliches Repository kann schlecht dokumentiert, ungetestet oder verlassen sein. Aber offener Code schafft die Voraussetzung dafür, dass Aussagen überprüft, Probleme gemeinsam bearbeitet und Arbeiten von anderen fortgesetzt werden können.

Für mein Fairphone FP4 wird das konkret. Reparierbare Hardware ist ein starkes Stück Souveränität. Doch ein austauschbarer Akku allein reicht nicht, wenn die Software zum Endpunkt wird. Umgekehrt hält ein freier Kernel kein Gerät am Leben, dessen Display oder Akku nicht ersetzt werden kann. Langlebigkeit braucht beides: reparierbare Hardware und langfristig pflegbare Software.

Zusammenarbeit statt technischem Kleinstaat

Ein weiterer aktueller Änderungsvorschlag für die postmarketOS-Startseite schärft den Abschnitt „Connecting Projects and People“. Die Kernaussage: postmarketOS baut nicht alles selbst neu. Das Projekt verwendet vorhandene freie Arbeit, verbessert sie und gibt Änderungen möglichst an Linux, Bibliotheken, Dienste und Anwendungen zurück.

Das ist keine Schwäche. Souveränität bedeutet nicht, jedes Rad allein neu zu erfinden. Sie bedeutet, gemeinsame Grundlagen prüfen, beeinflussen und notfalls ersetzen zu können.

Eine Momentaufnahme der offenen Arbeiten im pmaports-Projekt vom 25. Juli 2026 zeigt, wie breit diese Zusammenarbeit ist:

  • Kernel werden aktualisiert.
  • Menschen übernehmen Maintainer-Rollen.
  • Wayland-Umgebungen erhalten Startkorrekturen.
  • Modem-, Audio-, Tastatur- und Energieprobleme werden bearbeitet.
  • CI-Läufe werden an neue Architekturen angepasst.
  • neue Geräte kommen hinzu, unbetreute Geräte werden archiviert.

Diese Liste ist keine fertige Funktionszusage. Ein „Draft“ ist ein Entwurf. „Request for test“ verlangt praktische Prüfung. Eine bestandene Pipeline bestätigt nur die definierten automatischen Tests. „Merged“ bedeutet, dass eine Änderung in einen Zweig übernommen wurde – nicht, dass sie auf jeder Hardware zuverlässig funktioniert.

Gerade diese Unterschiede machen das Projekt glaubwürdig. Eine rote Pipeline kann mehr Vertrauen schaffen als eine grüne Werbebroschüre, wenn sie ein Problem vor der Auslieferung sichtbar macht.

Maintainer sind Infrastruktur

Bei mobilen Linux-Systemen schauen Nutzer zuerst auf Gerätebilder und Funktionslisten. Dahinter steht eine weniger sichtbare Frage: Wer reagiert, wenn sich Kernel, Compiler, Oberfläche oder Hardwareunterstützung verändern?

In der aktuellen Arbeitsliste stehen technische Änderungen und Zuständigkeitswechsel nebeneinander. Für den PinePhone Pro werden sowohl ein neuer Kernelstand als auch Maintainer-Anpassungen vorgeschlagen. Für Xiaomi beryllium möchte jemand die Pflege übernehmen. Andere Änderungen warten ausdrücklich auf Maintainer-Review.

Das ist entscheidend. Ein neuer Kernel ohne Menschen, die Fehlerberichte einordnen und reale Geräte testen, ist kein nachhaltiger Fortschritt.

Auch Archivierung gehört zu ehrlicher Pflege. Ein archivierter Port wird nicht automatisch wertlos oder gelöscht. Das Projekt kennzeichnet jedoch, dass aktuelle Verantwortung fehlt. Neue Maintainer können ihn später wiederbeleben. Eine kürzere, ehrliche Geräteliste ist besser als eine lange Liste technischer Versprechen ohne belastbare Pflege.

Nachhaltigkeit ist unspektakuläre Dauerarbeit

Lange Gerätenutzung entsteht nicht durch einen grünen Aufkleber. Sie entsteht durch kleine, fortlaufende Arbeiten:

  • ein korrigierter Start einer Wayland-Oberfläche,
  • ein funktionierendes Modem,
  • eine deutsche Hardwaretastatur,
  • weniger unnötige Pakete,
  • eine aktualisierte Audiokonfiguration,
  • ein reparierter Ladevorgang,
  • angepasste Compiler- und Kernelkonfigurationen.

Jede Änderung wirkt klein. Zusammen entscheiden sie darüber, ob ein Gerät nur theoretisch startet oder im Alltag benutzbar bleibt.

Dasselbe gilt beim Selbsthosting. Ein Matrix-Homeserver bleibt nicht souverän, weil Synapse einmal installiert wurde. Datenbankmigrationen, Backups, Medien, Zertifikate, .well-known, Nginx und Zugangstokens benötigen dauerhafte Pflege. Ein offener Bauplan ersetzt keine Instandhaltung.

Kontrolle ist eine Beziehung

postmarketOS ist keine fertige Lösung für jeden Menschen und jedes Gerät. Kamera, Modem, Energiemanagement, Bankanwendungen und Sicherheitsanforderungen müssen konkret geprüft werden. Ein Fairphone FP4 mit mobilem Linux ist nicht automatisch alltagstauglich, nur weil das Ziel richtig ist.

Doch das Projekt zeigt, wie digitale Souveränität praktisch aussehen kann: Arbeit wird sichtbar. Zuständigkeiten werden öffentlich. Grenzen werden benannt. Verbesserungen fließen in gemeinsame Projekte zurück.

Die entscheidende Frage lautet deshalb nicht nur: „Ist der Code offen?“

Wir sollten fragen:

  • Wer kann ihn bauen und prüfen?
  • Wer pflegt ihn?
  • Wer dokumentiert seine Grenzen?
  • Wer übernimmt, wenn ein Maintainer ausfällt?
  • Können Verbesserungen an andere freie Projekte zurückgegeben werden?
  • Kann der Nutzer sein Gerät weiterverwenden, wenn der Hersteller längst das nächste Modell verkaufen möchte?

Kontrolle zurückzugewinnen heißt nicht, alles allein zu machen. Es heißt, gemeinsam genutzte Technik prüfen, verändern und notfalls verlassen zu können.

Diskussion: https://treff.darknight-coffee.eu
Podcast: https://podcast.darknight-coffee.org/pages/startseite
Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Handy flashen heißt Rückweg planen: Was postmarketOS über echte digitale Souveränität zeigt

Handy flashen heißt Rückweg planen: Was postmarketOS über echte digitale Souveränität zeigt

Stand: 19. Juli 2026
Status: Entwurf – nicht veröffentlicht, Freigabe erforderlich

Ein freies Betriebssystem auf dem Smartphone zu installieren, fühlt sich nach Befreiung an. Der Bootloader ist offen, das Image stammt aus einem freien Projekt, die Kontrolle scheint zurück beim Nutzer. Doch diese Freiheit wird erst beim ersten ernsten Fehler geprüft: Startet das Gerät nach einem Update noch? Gibt es einen alten Systemstand? Funktioniert die Recovery? Sind Fotos, Kontakte, Schlüssel und Zwei-Faktor-Zugänge unabhängig gesichert?

Wer hineinflashen kann, aber nicht wieder herauskommt, ist nicht souverän. Er hat lediglich die Richtung seiner Abhängigkeit geändert.

postmarketOS liefert im Sommer 2026 ein Lehrstück darüber, wie ein freies Projekt mit diesem Problem umgehen kann. Duranium setzt auf vollständige, verifizierte A/B-Systemabbilder und automatischen Rückfall. Ein Fallback-Bootloader soll auf geeigneten EFI-Systemen eine noch frühere Fehlerstufe absichern. usb-signaller soll USB-Modi robuster beherrschbar machen. Gleichzeitig archiviert das Projekt unbetreute Geräteports und verschärft die Anforderungen an „testing“. Das sind keine spektakulären App-Neuheiten. Es sind Bausteine praktischer Souveränität.

Duranium behandelt Updates als vollständige Zustände

Die offizielle Duranium-Beschreibung trennt ein schreibgeschütztes Kernsystem unter /usr vom veränderlichen System- und Nutzerdatenbereich. Aktualisierungen werden nicht als lose Folge von Paketoperationen in das laufende System geschrieben. Sie landen als vollständiges Abbild in einem inaktiven Slot. Zwei /usr-Slots bilden das A/B-Modell.[2][3]

dm-verity prüft die Integrität des Systemabbilds. systemd-sysupdate, systemd-repart und systemd-boot übernehmen Aktualisierung, Partitionierung, Boot-Auswahl und Rückfall. Unified Kernel Images bündeln Kernel, Initramfs, Kommandozeile und Device Trees passend zur jeweiligen Systemversion. Startet die neue Version nicht erfolgreich, soll der vorherige Slot automatisch ausgewählt werden.[2][3]

Der postmarketOS-Monatsbericht vom 6. Juli 2026 nennt eine zusätzliche Sicherung: Auf Systemen mit Unterstützung für EFI-Variablen verwendet Duranium nun systemd/bootctl, um bei einer Aktualisierung einen Fallback-Bootloader vorzuhalten.[1] Das schließt eine wichtige Lücke. Ein alter Systemslot nützt wenig, wenn ein beschädigter neuer Bootloader gar nicht mehr bis zur Slot-Auswahl kommt.

Das Prinzip kennt jeder verantwortungsvolle Serverbetrieb. Vor einem Synapse-Upgrade reicht ein Datenbankdump nicht. Benötigt werden außerdem Medien, Schlüssel, Reverse-Proxy-Konfiguration, .well-known, die passende Softwareversion und ein dokumentierter Restore. Eine Sicherung ist erst dann ein Rückweg, wenn alle notwendigen Teile wieder zusammenspielen.

Rollback ist nicht Recovery – und Recovery ist kein Backup

Drei Begriffe müssen auseinandergehalten werden:

  • Rollback startet einen früheren Systemstand.
  • Recovery macht ein nicht mehr startendes Gerät wieder erreichbar.
  • Backup stellt Nutzerdaten, Schlüssel und Zugänge wieder her.

Duranium verbessert vor allem den ersten Bereich und mit dem Bootloader-Fallback einen Teil des zweiten. Daraus folgt kein universeller Backup-Prozess für Kontakte, Nachrichten, Fotos, App-Daten oder Zwei-Faktor-Zugänge. Ein A/B-System schützt nicht automatisch den veränderlichen Datenbereich.

Auch ein formal erfolgreicher Start beweist nicht, dass die neue Version im Alltag funktioniert. Telefonie kann ausfallen, die Kamera kann streiken oder eine Netzwerkfunktion kann erst nach dem Boot versagen. Automatischer Rückfall braucht erkennbare Fehlerkriterien. Die ausgewerteten Quellen belegen das grundsätzliche Boot-Zähler- und Rollback-Design, aber keinen lückenlosen Umgang mit jedem denkbaren Gerätefehler.[3]

Hinzu kommt: Duranium wird ausdrücklich als „work in progress“ beschrieben. Das Projekt sucht Tester und richtet sich noch nicht an Menschen, die ein garantiert verlässliches Alltagsgerät benötigen. UEFI ist erforderlich; auf Android-Geräten soll eine geeignete U-Boot-Umsetzung die Schnittstelle liefern. Die A/B-Slots und Verity-Daten benötigen zusätzlichen Speicher. Nicht jedes postmarketOS-Gerät wird das Modell unterstützen. In der Einführung vom März waren Secure Boot und eine vollständige Verified-Boot-Kette noch nicht umgesetzt.[2]

USB ist im Fehlerfall eine Wartungstür

usb-signaller wurde laut Monatsbericht in den Entwicklungszweig edge aufgenommen.[1] Die Neuimplementierung für mobile Geräte mit Mainline-Linux behält eine mit usb-moded kompatible D-Bus-Schnittstelle. Dokumentiert sind transaktionales Umschalten zwischen USB-Modi, klareres Logging, Unterstützung für systemd und OpenRC sowie seit Version 0.3.0 der Rollenwechsel zwischen Geräte- und Hostfunktion.[7]

Scheitert die Aktivierung eines USB-Gadgets, ist ein Rückfall auf reines Laden vorgesehen. Gleichzeitig steht universelle Kabelerkennung weiterhin auf der Roadmap. Die Aufnahme in edge bedeutet also weder, dass usb-signaller Teil jeder stabilen Installation von Version 26.06 ist, noch dass sämtliche USB-Funktionen auf jedem Gerät belastbar arbeiten.

Diese Abgrenzung ist praktisch wichtig. Laden, MTP, Netzwerk-Tethering, Hostmodus und Entwicklerzugriff sind unterschiedliche Funktionen. Ein Ladesymbol beweist keinen funktionierenden Diagnoseweg. Das ist vergleichbar mit einem Reverse Proxy: Dass Nginx läuft, sagt noch nichts darüber aus, ob der Upstream-Dienst antwortet.

Warum postmarketOS Geräte archiviert

Über Jahre verlangte postmarketOS bei Gerätepaketen nicht zwingend einen Maintainer im APKBUILD. Nach Darstellung des Projekts entstanden dadurch mehrere hundert unbetreute Geräte-, Kernel- und andere Pakete. Einige bauten mit einem aktuellen GCC nicht mehr.[5]

Nach Version 26.06 wurden unbetreute Gerätepakete in die Kategorie archived verschoben.[1][4] Das bedeutet:

  • Der Port wird in der normalen Geräteauswahl nicht angeboten.
  • Es werden keine Binärpakete dafür gebaut.
  • Die Dateien bleiben als Entwicklungsgrundlage erhalten.
  • Der Port kann zurückkehren, wenn Betreuung und Anforderungen wieder erfüllt sind.

Archivieren ist hier kein Löschen und kein Verbot. Es ist eine ehrliche Kennzeichnung. Ein vorhandener Geräteordner ist so wenig ein gepflegtes Produkt wie ein altes Container-Image ohne Maintainer, Sicherheitsupdates und reproduzierbaren Build.

Auch die Kategorie testing muss nüchtern gelesen werden. Der Kernel muss mindestens so neu sein wie der älteste noch unterstützte LTS-Kernel von kernel.org und mit LLVM gebaut werden. Port und Abhängigkeiten müssen bauen, das Gerät muss starten.[4] Trotzdem können wenige oder viele Funktionen vorhanden sein. Maintainer müssen keinen Nutzersupport leisten, und Geräte können ohne Vorankündigung archiviert werden. Version 26.06 führte 254 Geräte in testing.[6] Das sind 254 Entwicklungsstände, nicht 254 garantierte Alltagstelefone.

Hardwaretests sind Infrastruktur, keine Garantie

postmarketOS baut eine eigene Hardware-CI mit realen Testgeräten, steuerbarer Stromversorgung, Gateway und GitLab-Anbindung auf. Für die höchste Kategorie main verlangt das Projekt Hardware-CI an mindestens zwei Orten mit zusammen mindestens drei Geräten sowie ein Maintainer-Team von mindestens fünf Personen.[4][8]

Das ist der richtige Ansatz: Ein Kernel, der kompiliert, beweist noch keine funktionierende Hardware. Zugleich bezeichnet die Dokumentation die Testinfrastruktur selbst als „Work-In-Progress“ und warnt vor Instabilität.[8] Automatisierte Tests reduzieren Blindflug; sie garantieren nicht jede reale Nutzungssituation.

Klar gekennzeichnete Bewertung

Meine Bewertung: postmarketOS handelt richtig, wenn es weniger verspricht und dafür genauer benennt, was tatsächlich getragen wird. Eine lange Geräteliste ohne Maintainer, aktuellen Kernel und getesteten Wiederanlaufweg ist keine digitale Souveränität. Sie ist eine Liste technischer Möglichkeiten, deren Betriebsrisiko vollständig beim Nutzer landet.

Duranium setzt an der richtigen Stelle an. Atomare Abbilder, Verity, zwei Systemslots und ein Bootloader-Fallback verlagern Zuverlässigkeit aus der persönlichen Improvisation in die Architektur. Das ist politisch relevant: Proprietäre Ökosysteme verkaufen Bequemlichkeit durch zentrale Kontrolle. Ein freies System muss dem nicht mit romantischer Bastlerfreiheit antworten, sondern mit nachvollziehbarer, dezentral wartbarer Verlässlichkeit.

Es gibt berechtigte Einwände. A/B-Slots kosten Speicher. Ein unveränderliches Kernsystem begrenzt Flexibilität. Strenge Kategorien können Nischengeräte aus dem sichtbaren Angebot drängen. UEFI- und U-Boot-Anforderungen schließen Hardware aus. Diese Kosten verschwinden nicht. Aber schwache Unterstützung als fertige Freiheit auszugeben, wäre die schlechtere Antwort. Die tragfähige Antwort lautet: Maintainer finanzieren, Hardwaretests ausbauen, Wiederherstellung dokumentieren und Grenzen offen benennen.

Was vor jedem Flash-Vorhaben geklärt sein muss

Dies ist kein universeller Flash-Leitfaden. Gerätespezifische Schritte dürfen erst nach Prüfung der offiziellen Dokumentation formuliert werden. Vorher sollten mindestens diese Fragen beantwortet sein:

  1. In welcher Kategorie steht genau dieses Modell: main, community, testing, downstream oder archived?
  2. Gibt es aktive Maintainer und einen noch gepflegten Kernel?
  3. Welche Funktionen sind aktuell belegt – Telefonie, Kamera, Verschlüsselung, USB?
  4. Liegen Originalabbild, offizieller Recovery-Weg und benötigte Werkzeuge vor?
  5. Sind Kontakte, Nachrichten, Schlüssel, Fotos und Zwei-Faktor-Zugänge getrennt gesichert?
  6. Gibt es für das Wartungsfenster ein Ersatzgerät oder einen anderen Kommunikationskanal?
  7. Wurde der Restore auf Lesbarkeit und Umsetzbarkeit geprüft?

Fazit

Digitale Souveränität ist nicht die einmalige Erlaubnis, ein anderes System zu installieren. Sie ist die dauerhafte Fähigkeit, Zustände zu prüfen, Fehler zu erkennen und nach einem Ausfall handlungsfähig zu werden.

postmarketOS ist mit Duranium, usb-signaller, ehrlicher Geräteklassifizierung und Hardware-CI noch nicht am Ziel. Doch das Projekt bearbeitet die richtige Frage: nicht nur, wie ein freies System auf das Gerät kommt, sondern wie Nutzer nach einem Fehler wieder zurückkommen.

Ein Gerät ist erst dann praktisch souverän, wenn der Weg hinein nicht zur Einbahnstraße wird.

Quellen

  1. postmarketOS, „postmarketOS in 2026-06: Plasma 6.7“, 6. Juli 2026: https://postmarketos.org/blog/2026/07/06/pmOS-update-2026-06/
  2. postmarketOS, „Introducing Duranium: a more reliable postmarketOS“, 17. März 2026: https://postmarketos.org/blog/2026/03/17/introducing-duranium/
  3. postmarketOS GitLab, duranium-build/DESIGN.md: https://gitlab.postmarketos.org/postmarketOS/duranium-build/-/blob/main/DESIGN.md
  4. postmarketOS-Dokumentation, „Device Categorization“: https://docs.postmarketos.org/pmaports/main/packaging/device-categorization.html
  5. postmarketOS, „Unmaintained devices to be archived after v26.06“, 24. März 2026: https://postmarketos.org/devel/2026/03/24/archiving-unmaintained-devices/
  6. postmarketOS, „v26.06: Alpen Avocado“, 21. Juni 2026: https://postmarketos.org/blog/2026/06/21/v26.06-release/
  7. Dylan Van Assche, usb-signaller: https://codeberg.org/DylanVanAssche/usb-signaller
  8. postmarketOS-Dokumentation, „Hardware Continuous Integration“: https://docs.postmarketos.org/hardware-ci/index.html
  9. Linux Kernel Archives, „Active kernel releases“: https://www.kernel.org/releases.html
  10. postmarketOS, „State of postmarketOS“: https://postmarketos.org/state/

CTA

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
Podcast: https://podcast.darknight-coffee.org/pages/startseite
Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Mein Weg mit verschiedenen mobilen Betriebssystemen: Eine Reise durch die Vielfalt

Einleitung

In der Welt der mobilen Betriebssysteme gibt es eine Vielzahl von Alternativen, die es den Nutzern ermöglichen, ihre Geräte nach ihren eigenen Vorstellungen zu gestalten. Von Ubuntu Touch über Sailfish OS bis hin zu PostmarketOS und Android Jockel – ich habe mich intensiv mit diesen Systemen auseinandergesetzt, auf verschiedenen Geräten getestet und alle Hürden genommen, die bei der Nutzung dieser alternativen OS aufgetreten sind. Diese Reise hat mich nicht nur technisch herausgefordert, sondern mir auch wertvolle Einblicke in die Zukunft der mobilen Technologie gegeben.

1. Ubuntu Touch – Der Start in die Welt der alternativen OS

Ubuntu Touch war das erste System, das ich auf einem meiner Geräte installiert habe – dem OnePlus 3. Es war ein aufregender Moment, da ich mich von der typischen Android-Oberfläche verabschiedete und den Weg zu einem System einschlug, das auf Open-Source setzt und mehr Kontrolle über die Datensicherheit bietet. Auch wenn es damals nicht perfekt lief, hat Ubuntu Touch die Basis für meine Reise in die Welt der alternativen Betriebssysteme gelegt.

Hauptmerkmale:

Open-Source

Datensicherheit und Privatsphäre im Fokus

Eine wachsende, aber noch kleine Entwicklergemeinschaft

2. Sailfish OS – Die Zukunft des mobilen Systems

Sailfish OS war mein nächstes Ziel, und es war ein großer Schritt. Mit seiner eleganten Benutzeroberfläche und den einzigartigen Möglichkeiten, Android-Apps zu integrieren, stellte Sailfish OS für mich eine echte Alternative zu den großen kommerziellen Systemen dar. Besonders interessant fand ich, dass Sailfish mehr Freiheit und Kontrolle bot als andere Systeme, ohne auf grundlegende Funktionen verzichten zu müssen.

Hauptmerkmale:

Elegante Benutzeroberfläche

Unterstützung von Android-Apps

Starke Community und viele Anpassungsmöglichkeiten

3. PostmarketOS – Der Durchbruch für den Linux-fokussierten Nutzer

PostmarketOS war der nächste Schritt auf meiner Reise. Als Open-Source-Betriebssystem, das auf Linux basiert, bot es mir alle Vorteile, die ich als Linux-Enthusiast suchte. Es läuft auf älteren Geräten reibungslos und gibt den Nutzern die Kontrolle über jedes Detail. Doch es gab auch einige technische Herausforderungen – wie das Flashen von Systemen und die Anpassung an unterschiedliche Geräte.

Hauptmerkmale:

Basiert auf Linux

Ideal für Nutzer, die Kontrolle über ihre Geräte haben wollen

Optimiert für ältere Geräte

4. Android Jockel – Ein Android, das den Namen verdient

Schließlich landete ich bei Android Jockel, einer Variante von Android, die mehr Kontrolle und Privatsphäre bietet. Es war interessant zu sehen, wie Android auf einem Gerät wie dem Fairphone 4 flüssig lief und gleichzeitig alle Google-Dienste entfernt wurden. Es war die perfekte Mischung aus offenen Systemen und praktischen Funktionen.

Hauptmerkmale:

Android ohne Google-Dienste

Anpassbare Benutzeroberfläche

Starke Leistung und viele Apps

5. Das Fairphone 4 – Das perfekte Testgerät

All diese Systeme wurden auf dem Fairphone 4 getestet, einem Gerät, das in vielerlei Hinsicht für die Nutzung alternativer Betriebssysteme prädestiniert ist. Es bietet nicht nur eine gute Hardware, sondern ist auch mit dem Gedanken an Nachhaltigkeit und Modularität gebaut. Auf diesem Gerät habe ich die meisten meiner Tests und Flash-Versuche durchgeführt.

6. Herausforderungen und Lösungen

Egal, ob es sich um das Flashen von Systemen oder die Einrichtung von Containerdiensten handelt, es gab immer wieder Herausforderungen. Eine große Hürde war es, sicherzustellen, dass alle Systemdateien korrekt übertragen wurden und dass der Bootloader stabil lief. Doch durch ständiges Ausprobieren und Anpassungen habe ich es geschafft, alle Systeme zum Laufen zu bringen.

Fazit

Diese Reise hat mir nicht nur gezeigt, wie vielfältig die Welt der mobilen Betriebssysteme ist, sondern auch, wie wichtig es ist, die Kontrolle über die eigene Technologie zu haben. Jede dieser Systemalternativen hat ihre eigenen Stärken und Schwächen, aber alle bieten eine wertvolle Perspektive auf die Zukunft der mobilen Nutzung. Ich hoffe, dass mein Erfahrungsbericht dir hilft, den richtigen Weg für dein Gerät und deine Bedürfnisse zu finden. Und vielleicht inspirieren dich meine Erfahrungen dazu, eines dieser Systeme selbst auszuprobieren!

Wenn Linux auf dem Smartphone abstürzt – Debugging eines postmarketOS-Bootfehlers auf dem Fairphone 4

Alternative Smartphone-Betriebssysteme faszinieren mich seit Jahren. Während die meisten Nutzer ihre Geräte im geschlossenen Ökosystem von Apple oder Google betreiben, interessiert mich vor allem die Frage:

Wie frei kann ein Smartphone wirklich sein?

Genau deshalb teste ich seit langer Zeit alternative Systeme wie Ubuntu Touch, Sailfish OS und postmarketOS. Mein Ziel ist es, herauszufinden, ob ein vollständig offenes mobiles Linux eines Tages als echter Daily Driver taugt.

Doch bei meinem letzten Experiment mit postmarketOS auf dem Fairphone 4 lief nicht alles glatt. Statt eines sauberen Systemstarts landete ich plötzlich in einer Debug-Shell.

Mein Setup: Mehrere Linux-Smartphones im Alltag

Aktuell teste ich mehrere Geräte parallel. Jedes davon läuft mit einem anderen System, um Unterschiede in Stabilität, Software-Ökosystem und Bedienbarkeit zu verstehen.

  • Fairphone 4 – postmarketOS mit GNOME
  • Fairphone 4 – Ubuntu Touch
  • Fairphone 4 – Sailfish OS (Community-Port)
  • Fairphone 5 – iodéOS (Android-basierend)
  • OnePlus 3 – Ubuntu Touch Testgerät

Der Grund dafür ist einfach: Ich möchte herausfinden, welches System langfristig wirklich als offene Alternative zu Android funktionieren kann.

Das Experiment: postmarketOS als Daily Driver

postmarketOS verfolgt eine spannende Idee: Smartphones sollen wie normale Linux-Computer behandelt werden. Das System basiert auf Alpine Linux und verwendet einen sehr aktuellen Kernel.

Mein Testsystem:

  • Gerät: Fairphone 4
  • postmarketOS Version: v25.12
  • Kernel: 6.17.6
  • Desktop: GNOME Mobile

Der Flash-Vorgang über Fastboot verlief zunächst problemlos. Das System startete – doch kurz darauf begann das eigentliche Problem.

Der Crash: Bootpartition nicht gefunden

Nach einem Neustart blieb das Gerät im Bootscreen hängen.

Fehlermeldung:

ERROR: Boot partition not found
Linux 6.4.2 | fairphone-fp4

Nach mehreren Neustarts landete das Gerät schließlich in der integrierten Debug-Shell von postmarketOS.

Die postmarketOS Debug-Shell

Statt der grafischen Oberfläche erschien eine minimale Shell-Umgebung: 

postmarketOS debug shell
https://postmarketos.org/debug-shell

Device: Fairphone 4 (fairphone-fp4)
Kernel: 6.17.6
pmOS version: v25.12

Run 'pmOS_continue_boot' to continue booting.
Read the initramfs log with 'cat /pmOS_init.log'.

Damit wurde klar: Das System konnte nicht vollständig booten und stoppte bereits im frühen Init-Prozess.

Log-Analyse

Über die Debug-Shell konnte ich die Bootlogs exportieren. Dabei entstanden mehrere Dateien:

  • pmOS_init.txt
  • dmesg.txt
  • blkid.txt
  • partitions.txt
  • cmdline.txt

Diese Logs sind entscheidend, um Bootprobleme zu analysieren.

Kernel-Cmdline

Ein besonders interessanter Teil war die Kernel-Cmdline: 

pmos_boot_uuid=3c7d8dc2-b86d-4d3b-be40-c47502ba782f
pmos_root_uuid=1119d23f-e612-4faa-9d4c-8950b34539f3
androidboot.mode=charger
androidboot.slot_suffix=_a
rootwait
init=/init

Der Eintrag androidboot.mode=charger deutet darauf hin, dass das Gerät möglicherweise im Lade-Modus startet statt im normalen Systemmodus.

Das könnte erklären, warum der Bootprozess nicht vollständig abgeschlossen wird.

Android-A/B-Partitionen

Moderne Android-Geräte besitzen ein sogenanntes A/B-Partitionssystem.

Das bedeutet:

  • Slot A enthält eine Systeminstallation
  • Slot B enthält eine zweite Installation
  • Updates werden auf dem inaktiven Slot installiert

Beim Booten entscheidet der Bootloader, welcher Slot verwendet wird.

In meinem Fall zeigte die Cmdline: 

androidboot.slot_suffix=_a

Das System versuchte also, von Slot A zu starten.

Warum solche Fehler wichtig sind

In proprietären Systemen bleiben solche Fehler meist unsichtbar. Nutzer sehen nur einen schwarzen Bildschirm.

In offenen Systemen wie postmarketOS passiert etwas anderes:

  • das System zeigt die Debug-Shell
  • Logs können exportiert werden
  • Fehler können reproduziert werden
  • die Community kann daran arbeiten

Genau diese Transparenz ist ein zentraler Vorteil von Open Source.

Open-Source-Mobile-Linux: Realität und Zukunft

Mobile Linux-Distributionen befinden sich noch immer im Aufbau. Projekte wie:

  • postmarketOS
  • Ubuntu Touch
  • Sailfish OS

zeigen jedoch bereits heute, dass Smartphones nicht zwangsläufig in geschlossenen Ökosystemen gefangen sein müssen.

Der Weg dorthin ist technisch anspruchsvoll – aber genau deshalb lohnt es sich, diese Systeme zu testen und Fehler offen zu dokumentieren.

Fazit

Der Absturz meines postmarketOS-Systems war kein Rückschritt, sondern ein Beispiel dafür, wie offene Software funktioniert:

  • Fehler werden sichtbar
  • Logs können analysiert werden
  • die Community kann Verbesserungen entwickeln

Während große Plattformen ihre Systeme hinter verschlossenen Türen entwickeln, entsteht mobile Linux-Software öffentlich – Schritt für Schritt.

Und genau deshalb teste ich weiter.

Dieser Artikel dokumentiert ein reales Debugging-Experiment mit postmarketOS auf dem Fairphone 4.

Sailfish OS auf dem Fairphone 4

Sailfish OS auf dem Fairphone 4

Warum Verschlüsselung hier kein Feature, sondern Haltung ist

Während andere Betriebssysteme beim ersten Start fragen, welche Cloud man anbinden möchte, macht Sailfish OS etwas völlig anderes:
Es verschlüsselt zuerst meine Daten. Punkt.

Kein Marketing.
Kein Konto.
Kein Zwang zur Online-Anmeldung.

Ein stiller, technischer Akt – mit politischer Aussage.

Kein Klick-OS, sondern Kontrolle zurückholen

Die Installation von Sailfish OS ist kein „Weiter-Weiter-Fertigstellen“.
Sie ist bewusst nicht bequem. Und genau das ist ihre Stärke.

Bootloader offen

Flashen per Terminal

Kein One-Click-Installer

Kein App-Store-Zwang

Kein Google

Keine Telemetrie-Orgie

Das System läuft jetzt auf meinem Fairphone 4 – weil ich es so wollte, nicht weil ein Konzern es mir erlaubt.

Verschlüsselung als Standard – nicht als Option

Während Android & iOS Verschlüsselung gerne als „Sicherheitsfeature“ verkaufen, behandelt Sailfish sie als das, was sie ist:

Grundvoraussetzung für digitale Selbstbestimmung.

Die komplette interne Festplatte wird verschlüsselt:

Kontakte

Nachrichten

Systemdaten

Ohne Cloud.
Ohne Hintertüren.
Ohne Werbe-ID.

Das Passwort liegt bei mir – nicht auf fremden Servern.

Warum genau das der Unterschied ist

Wir reden ständig über:

Datenschutz

Digitale Souveränität

Abhängigkeiten von US-Konzernen

europäische Alternativen

Aber kaum jemand geht den Weg konsequent zu Ende.

Sailfish OS ist keine perfekte Lösung –
aber eine ehrliche.

Ja, nicht jede Hardware läuft perfekt

Ja, es gibt weniger Apps

Ja, es erfordert technisches Verständnis

Doch dafür gibt es:

Kontrolle

Transparenz

ein System, das mir gehört

Technik ohne Ideologie – und gerade deshalb politisch

Sailfish OS ist nicht „woke“.
Nicht missionarisch.
Nicht belehrend.

Es sagt nicht, was du denken sollst.
Es zwingt dich nur, selbst Verantwortung zu übernehmen.

Und das ist heute radikaler als jede Parole.

Mein Fazit (vorläufig)

Während mein Fairphone gerade still vor sich hin verschlüsselt, wird mir klar:

Freiheit beginnt nicht beim Posten –
sondern beim Besitz der eigenen Infrastruktur.

Sailfish OS ist kein Massenprodukt.
Es ist ein Werkzeug für Menschen, die verstanden haben,
dass Bequemlichkeit der Preis für Kontrolle ist.

Ich bleibe dran.
Tests, Alltagserfahrungen, Stärken, Schwächen – alles folgt.