Die stille Tür im Linux-Server: Was BPFDoor über unsere Telekommunikationsnetze verrät

Ein Linux-Server kann nach außen vollkommen ruhig wirken. Kein ungewöhnlicher Port steht offen, kein verdächtiger Dienst meldet sich regelmäßig bei einem Kontrollserver, und ein gewöhnlicher Portscan findet nichts. Trotzdem kann im System eine Hintertür warten. Nicht auf eine normale Anmeldung, sondern auf ein präpariertes Netzwerkpaket.

Genau dieses Prinzip nutzt BPFDoor. Die Backdoor ist kein theoretisches Laborstück und auch keine neue Windows-Schadsoftware mit Linux-Anstrich. Sie wurde für langfristige Zugriffe auf Linux-Systeme entwickelt und mit Spionagekampagnen gegen Telekommunikations- und Regierungsnetze verbunden. Rapid7 berichtete 2026 nach einer mehrmonatigen Untersuchung über eine fortdauernde, China-nahe Kampagne in Telekommunikationsumgebungen. Fraunhofer FKIE führt die Malwarefamilie in Malpedia, MITRE ordnet ihre Techniken im ATT&CK-Katalog ein.

Der Fall ist technisch interessant. Politisch ist er noch wichtiger. Berlin diskutiert gleichzeitig neue offensive Befugnisse für Nachrichtendienste, einschließlich Eingriffen in fremde IT-Systeme und des Umgangs mit unbekannten Schwachstellen. Brüssel verpflichtet Betreiber und Hersteller mit NIS2 und Cyber Resilience Act zu mehr Sicherheitsmanagement. Die eine politische Hand verlangt also bessere Verteidigung. Die andere will sich offensive Zugriffsmöglichkeiten erhalten.

Die entscheidende Frage lautet deshalb nicht nur, wie BPFDoor funktioniert. Sie lautet: Wie glaubwürdig ist staatliche Cybersicherheit, wenn derselbe Staat ein Interesse daran haben kann, Schwachstellen nicht sofort zu schließen?

BPF ist keine Firewall

Der Name BPFDoor verweist auf den Berkeley Packet Filter. BPF ist keine eigenständige Linux-Firewall. Es ist eine Filter- und Ausführungsmechanik, mit der Netzwerkpakete früh und effizient ausgewählt werden können. Werkzeuge wie tcpdump und Bibliotheken wie libpcap nutzen diese Technik, damit nicht jedes Paket vollständig in den Userspace kopiert und dort ausgewertet werden muss.

BPFDoor missbraucht diese legitime Fähigkeit. Die Malware bindet einen Filter an einen Raw Socket und prüft eintreffende TCP-, UDP- oder ICMP-Pakete auf bestimmte Aktivierungsdaten. Normale Pakete werden ignoriert. Ein passendes „Magic Packet“ löst dagegen die nächste Stufe aus. Je nach Variante startet die Malware eine Bind- oder Reverse-Shell und verschafft dem Angreifer eine Kommandozeile auf dem kompromittierten System.

Das ist der eigentliche Tarnvorteil: Die Backdoor braucht keinen dauerhaft sichtbaren Listening-Port und kein regelmäßiges Beaconing. Sie muss nicht alle paar Minuten nach Hause telefonieren. Sie wartet passiv im vorhandenen Verkehr.

Unsichtbar ist sie deshalb nicht. Sie hinterlässt Prozesse, Speicherzustände, Socket-Aktivität, geladene Filter, veränderte Firewallregeln oder Laufzeitdateien. Bekannte Varianten manipulieren Prozessnamen, löschen die abgelegte Binärdatei nach dem Start, verändern Zeitstempel und leiten Shell-Historien nach /dev/null. MITRE dokumentiert außerdem Varianten, die hohe TCP-Ports verwenden und iptables-Regeln zur Weiterleitung von Paketen einrichten.

Wer nur nach offenen Standardports sucht, kann BPFDoor übersehen. Wer Host, Speicher, Raw Sockets, BPF-Nutzung, Prozessbaum und ausgehenden Verkehr gemeinsam überwacht, ist nicht hilflos.

Ein Magic Packet ist kein universeller Generalschlüssel

In populären Erklärvideos wird gern eine feste Bytefolge gezeigt, die angeblich „die“ Backdoor aktiviert. Das ist anschaulich, aber gefährlich verkürzt. BPFDoor existiert in mehreren Varianten. Protokolle, Magic Values, Passwörter, Shell-Verhalten und Verschleierung können sich unterscheiden. Der 2022 öffentlich gewordene Quellcode erleichterte es weiteren Akteuren, Varianten abzuleiten.

Eine einzelne Signatur kann deshalb einen bekannten Stand erkennen, aber keine ganze Malwarefamilie abschließend ausschließen. Gute Erkennung kombiniert mehrere Ebenen:

  • bekannte Hashes und YARA-Regeln für Dateien und Speicher;
  • auffällige Raw Sockets und BPF-Filter;
  • unerwartete Prozesse mit Namen legitimer Systemdienste;
  • ungewöhnliche Runtime- oder Lock-Dateien;
  • neue oder unerklärliche iptables– beziehungsweise nftables-Regeln;
  • Shell-Verbindungen auf hohen Ports;
  • ausgehende Verbindungen, die nicht zum Zweck des Servers passen;
  • Unterschiede zwischen sauberer Referenzinstallation und produktivem Zustand.

Für einen kleinen selbstgehosteten Matrix- oder Nextcloud-Server bedeutet das nicht, jede Nacht eine Geheimdienstoperation zu vermuten. Es bedeutet, Monitoring nicht auf CPU, RAM und „Port 443 antwortet“ zu reduzieren. Ein System kann verfügbar und trotzdem kompromittiert sein.

Warum Telekommunikationsnetze so wertvoll sind

Telekommunikationsnetze verbinden Identität, Standort und Kommunikation. Im Kern liegen Systeme für Teilnehmerverwaltung, Authentifizierung, Roaming, Abrechnung und Signalisierung. Protokolle wie SS7, Diameter und SCTP transportieren Informationen darüber, welcher Teilnehmer sich wo befindet, wie Verbindungen geroutet und wie fremde Netze einbezogen werden.

Wer sich langfristig in einer solchen Umgebung positioniert, erhält nicht automatisch Zugriff auf jedes Gespräch. Er kann aber Kommunikationsmetadaten, Teilnehmerkennungen, Bewegungsereignisse, Authentifizierungsvorgänge und interne Vertrauensbeziehungen ausspähen. Außerdem kann ein kompromittierter Randserver als Sprungbrett in tiefer liegende Netzsegmente dienen.

Rapid7 beschreibt keinen einzelnen spektakulären Einbruch, sondern ein Kampagnenmodell: erste Zugriffe über exponierte VPNs, Firewalls, Router oder Webanwendungen; danach Zugangsdaten sammeln, seitlich weiterbewegen und langfristige Implantate platzieren. Genannt werden unter anderem missbrauchte Konten und Schwachstellen in öffentlich erreichbaren Systemen.

Das ist keine Besonderheit „des unsicheren Linux“. Linux dominiert viele Server- und Infrastruktursegmente gerade wegen seiner Offenheit, Anpassbarkeit und Stabilität. Diese Stärke schützt aber nicht vor schlechten Zugangsdaten, ungepatchten Appliances, mangelhafter Segmentierung oder fehlender Telemetrie. Open Source ermöglicht Prüfung. Sie ersetzt die Prüfung nicht.

China-Zuschreibung: ernst nehmen, aber sauber formulieren

Malpedia verbindet BPFDoor mit dem Akteur Red Menshen. Rapid7 spricht von einem China-nahen Bedrohungsakteur. Das ist eine fachliche Attribution aus Infrastruktur, Werkzeugen, Vorgehensweisen, Zielauswahl und anderen nachrichtendienstlichen Indikatoren.

Eine solche Zuschreibung kann belastbar sein, bleibt aber etwas anderes als ein öffentlich vollständig beweisbares Strafverfahren. Deshalb ist „China hat alle Netze übernommen“ keine seriöse Schlussfolgerung. Belegt sind Kampagnen und technische Indikatoren. Nicht belegt ist, dass praktisch jedes internationale Telekommunikationsnetz infiziert oder grundsätzlich nicht mehr bereinigbar wäre.

Gerade bei staatlicher Spionage ist Präzision kein Weichspüler. Sie verhindert, dass politische Kritik durch Übertreibung angreifbar wird.

Berlin: Der Staat als Verteidiger und Angreifer

Darknight-Coffee hat die geplante Reform des Nachrichtendienstrechts bereits ausführlich analysiert. Der veröffentlichte Beitrag „Der Geheimdienst als Hacker“ behandelt vorgesehene Eingriffe in fremde Systeme, automatisierte Maßnahmen, Attribution und den Umgang mit Zero-Day-Schwachstellen.

BPFDoor liefert dazu den technischen Realitätscheck. Eine Backdoor dieser Klasse lebt davon, dass Angreifer zuerst einen Zugang finden und anschließend unauffällige Persistenz aufbauen. Jede nicht geschlossene Schwachstelle in VPNs, Firewalls, Routern oder Serverdiensten kann Teil dieser Angriffskette werden.

Wenn staatliche Stellen unbekannte Schwachstellen für eigene Zugriffe zurückhalten, bleiben dieselben Lücken auch für fremde Dienste und kriminelle Gruppen offen. Der Staat kann eine Zero-Day-Lücke nicht exklusiv besitzen. Er kann nur hoffen, dass niemand anderes sie findet oder kauft.

Darum braucht Deutschland ein verbindliches und kontrollierbares Schwachstellenmanagement: Offenlegung und Schließen als Regelfall, eng begrenzte Ausnahmen, unabhängige Risikoprüfung, kurze Neubewertungsfristen und nachvollziehbare Verantwortung. Ohne diesen Vorrang wird der Satz „Wir stärken die Cybersicherheit“ politisch hohl.

Brüssel: NIS2 und CRA reichen allein nicht

NIS2 verlangt von wesentlichen und wichtigen Einrichtungen ein systematisches Risikomanagement und Meldeprozesse für erhebliche Sicherheitsvorfälle. Telekommunikation gehört zum Kernbereich kritischer digitaler Infrastruktur. Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen schrittweise zu Sicherheitsanforderungen, Schwachstellenmanagement und Meldungen aktiv ausgenutzter Lücken.

Beide Regelwerke setzen richtige Punkte. Betreiber müssen Risiken beherrschen; Hersteller dürfen Sicherheit nicht nach dem Verkauf einstellen. Doch Regulierung kann zur Papiermaschine verkommen. Eine gepflegte Richtlinie, ein ausgefülltes Auditformular und eine fristgerechte Meldung entdecken keinen passiven Implantatprozess im Arbeitsspeicher.

Entscheidend ist die technische Umsetzung:

  • belastbare Inventare aller Systeme und Abhängigkeiten;
  • schnelle Patch- und Notfallwege;
  • Segmentierung zwischen Rand-, Management- und Kernsystemen;
  • minimal notwendige Rechte und rotierende Zugangsdaten;
  • zentrale, manipulationsgeschützte Logs;
  • Egress-Filter und nachvollziehbare Netzwerkflüsse;
  • Host- und Speicherforensik für Linux;
  • regelmäßige Wiederherstellungs- und Neuaufbauproben;
  • unabhängige Red-Team- und Incident-Response-Übungen.

Digitale Souveränität heißt hier nicht, jeden Server selbst zu betreiben. Sie heißt, Systeme, Schlüssel, Protokolle und Wiederherstellung so zu beherrschen, dass ein Betreiber nicht blind vom Hersteller, einem Cloudanbieter oder einer ausländischen Behörde abhängig bleibt.

Was Betreiber konkret tun können

Ein Verdacht auf BPFDoor ist kein Fall für hektisches Löschen einzelner Dateien. Das System muss isoliert werden, ohne forensische Spuren unnötig zu zerstören. Flüchtige Daten wie Prozesse, Netzwerkverbindungen, Raw Sockets, geladene Filter und Speicherinhalte sind besonders wichtig. Danach müssen Zugangsdaten und Schlüssel aus einer sauberen Umgebung rotiert, seitliche Bewegungen geprüft und betroffene Systeme kontrolliert neu aufgebaut werden.

Ein Backup ist dabei notwendig, aber kein Freispruch. Wer ein komplettes kompromittiertes Systemabbild blind zurückspielt, kann die Hintertür gleich mit restaurieren. Wiederhergestellt werden sollten geprüfte Daten in eine saubere, aktualisierte Umgebung. Konfigurationen gehören mit einer bekannten Referenz verglichen.

Für Community-Infrastruktur gilt derselbe Grundsatz im kleineren Maßstab. Nginx-Logs, Synapse-Tokens, Nextcloud-App-Passwörter und Backupschlüssel müssen getrennt gedacht werden. Ein kompromittierter Reverse Proxy darf nicht automatisch Zugriff auf jede Datenbank und jedes Sicherungsziel besitzen.

Fazit: Verteidigung beginnt mit politischer Ehrlichkeit

BPFDoor zeigt, wie leise ein langfristiger Zugriff auf Linux-Infrastruktur sein kann. Die Backdoor braucht keinen auffälligen offenen Port und kein regelmäßiges Lebenszeichen. Sie kann legitime Kernelmechanismen missbrauchen und sich hinter vertraut wirkenden Prozessnamen verbergen.

Das macht Verteidigung anspruchsvoll, aber nicht aussichtslos. Wer nur Verfügbarkeit überwacht, sieht zu wenig. Wer Host, Netzwerk, Identitäten, Segmentierung und Wiederherstellung gemeinsam prüft, kann solche Angriffe erkennen und eindämmen.

Politisch bleibt der Widerspruch: Berlin und Brüssel fordern zu Recht mehr Cybersicherheit. Gleichzeitig will Berlin Nachrichtendiensten offensive Cybermacht und Zugriff auf Schwachstellen ermöglichen. Beides passt nur zusammen, wenn das Schließen von Lücken nachweisbar Vorrang hat.

Ein Staat, der seine digitale Infrastruktur schützen will, darf Sicherheitslücken nicht wie geheime Dietriche sammeln. Denn jede Tür, die für den eigenen Dienst offenbleibt, steht möglicherweise längst auch für einen fremden offen.

Quellen

1. Rapid7 Labs, „BPFdoor in Telecom Networks: Sleeper Cells in the Backbone“: https://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/ 2. MITRE ATT&CK, BPFDoor S1161: https://attack.mitre.org/software/S1161/ 3. Fraunhofer FKIE Malpedia, elf.bpfdoor: https://malpedia.caad.fkie.fraunhofer.de/details/elf.bpfdoor 4. EU, NIS2-Richtlinie 2022/2555: https://eur-lex.europa.eu/eli/dir/2022/2555/oj 5. EU, Cyber Resilience Act 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/oj 6. Darknight-Coffee, „Der Geheimdienst als Hacker“: https://carrabelloy.darknight-coffee.org/blog/2026/07/26/der-geheimdienst-als-hacker-mehr-cybermacht-verlangt-staerkere-kontrolle/

CTA

Diskussion: https://treff.darknight-coffee.eu Podcast: https://podcast.darknight-coffee.org/@carrabelloy/episodes/die-stille-tur-im-linux-server-bpfdoor-und-der-politische-preis-offener-schwachstellen 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

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.