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.