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.

🔐 Open-Source verstehen – Teil 2: Wie man Software richtig prüft

(Digitale Signaturen, Checksums & Vertrauen – einfach erklärt)

Wer Open-Source nutzt – egal ob Debian, Ubuntu, postmarketOS, Fedora, Arch oder andere – arbeitet immer auch mit Paketen, also kleinen Software-Bausteinen.
Damit diese Pakete sicher sind und nicht manipuliert wurden, besitzt jedes seriöse Linux-System eingebaute Sicherheitsmechanismen, die wir in diesem Teil einfach erklären.

🧠 Warum muss man Pakete überhaupt prüfen?

Jedes Linux-Paket wird in der Regel digital signiert:
mit GPG / OpenPGP, einem kryptografischen Verfahren.

Die digitale Signatur stellt sicher, dass:

das Paket vom echten Entwickler stammt

es unterwegs nicht verändert wurde

die Quelle (Repository) authentisch ist

keine Schadsoftware eingeschleust wurde

Damit hat Linux von Haus aus einen höheren Sicherheitsstandard als Windows oder macOS – wenn man die Signaturhinweise beachtet.

🧩 Wie prüft man die Echtheit?
(Beispiele für Debian, Ubuntu & postmarketOS)

Es gibt viele Wege – aber alle basieren auf dem gleichen Prinzip:
Wurde die digitale Signatur erfolgreich geprüft oder nicht?

🔹 1. Paketlisten aktualisieren (und Warnungen ernst nehmen)

Beim Aktualisieren zeigt Debian/Ubuntu die Signaturen automatisch an:

sudo apt update

Wenn alles korrekt ist → läuft ohne Warnungen durch.

Wenn etwas nicht stimmt, erscheint:

W: GPG error: … The following signatures couldn’t be verified…

Das bedeutet:

❌ Die Echtheit des Repositorys kann nicht bestätigt werden
❌ Pakete könnten manipuliert sein
❌ Keine Updates installieren!

Solche Warnungen niemals ignorieren.

🔹 2. Wo speichert Debian die vertrauenswürdigen Schlüssel?

Die Schlüssel für alle Paketquellen liegen hier:

ls /etc/apt/trusted.gpg.d/

Dort befindet sich jeder Schlüssel, dem dein System vertraut.
Fehlt ein Schlüssel → kann APT Updates nicht verifizieren

🔹 3. Manuelle Prüfung bei Downloads (ISO, .deb, tar.xz)

Wenn du Software außerhalb eines Repos herunterlädst (z. B. GitHub, Gnome.org, KDE.org), findest du oft diese Dateien:

software.tar.xz (die Datei selbst)

software.tar.xz.asc (digitale Signatur)

software.tar.xz.sha256 (Hash-Prüfsumme)

Hash prüfen: sha256sum DATEI.iso

Ausgabe vergleichen → muss exakt übereinstimmen.

Signatur prüfen: gpg –verify DATEI.asc DATEI

Wenn korrekt signiert:

✔ „Good signature from …“

Wenn nicht:

❌ „BAD signature“ → Datei löschen, nicht benutzen.

🔹 4. postmarketOS / Alpine Linux (apk)

postmarketOS nutzt apk, ein extrem strenges und modernes Paket-System.
Die Schlüssel liegen hier: ls /etc/apk/keys/

Wenn bei dir apk update fehlschlägt, liegt es fast immer an:

fehlenden Schlüsseln

veralteten Schlüsseln

defekter Zeiteinstellung (sehr häufig!)

defekten Repository-Servern

🛡️ Warum diese Prüfungen so wichtig sind

Linux ist ein offenes System – und genau deshalb ist Transparenz so zentral.
Man ist nicht auf „Blindes Vertrauen in eine Firma“ angewiesen, sondern auf:

Kryptografie

Signaturen

Öffentliche Schlüssel

Offene Verfahren

Die größte Gefahr entsteht, wenn man Warnungen ignoriert wie:

„Signature could not be verified“

Darum gilt:

✔ Warnungen ernst nehmen
✔ Schlüssel prüfen
✔ Repositories im Blick behalten

So bleibt das System sicher – ganz egal ob Laptop, Server oder Smartphone.

💬 Fazit

Linux bietet eines der sichersten Paket-Systeme der Welt – aber es funktioniert nur richtig, wenn man ihm aufmerksam folgt.

Du musst kein Experte sein.
Du musst nur wissen, worauf du achten solltest:

Stimmen die Signaturen?

Gibt es Warnungen?

Kommt das Paket aus einer offiziellen Quelle?

Dann bist du auf der sicheren Seite.

🧠 Warum man Pakete prüfen sollte

🧠 Warum man Pakete prüfen sollte

(Und wie du dich vor manipulierten Updates schützt)

Wenn du Linux nutzt – egal ob Debian, Ubuntu, postmarketOS, Fedora oder andere Distributionen – installierst du Software immer als sogenannte Pakete:

.deb (Debian / Ubuntu)

.apk (postmarketOS / Alpine Linux)

.rpm (Fedora, Red Hat)

.tar.xz (Quellpakete, Releases auf GitHub usw.)

Damit du sicher sein kannst, dass diese Pakete echt sind, werden sie vom Entwickler oder vom Maintainer kryptografisch signiert – meistens mit GPG / OpenPGP.

Diese Signaturen stellen sicher, dass:

✔ das Paket vom richtigen Entwickler stammt
✔ es nicht manipuliert wurde (z. B. durch Malware)
✔ die Übertragung nicht abgefangen wurde

Das Prüfen von Signaturen gehört zu den wichtigsten Sicherheitsmechanismen im Linux-Universum.

🔍 Wie man die Echtheit prüft

(Beispiele für Debian, Ubuntu & postmarketOS)

Jede Linux-Distribution hat eigene Werkzeuge – aber die Prinzipien sind überall gleich.

🔹 1. Paketlisten aktualisieren (und Warnungen ernst nehmen)

Wenn du bei Debian/Ubuntu eingibst: sudo apt update

und du bekommst eine Warnung wie: W: GPG error: … The following signatures couldn’t be verified
dann heißt das:

❌ Die Signatur konnte nicht überprüft werden
❌ Das Paket ist möglicherweise unsicher
❌ Du solltest KEINE Updates installieren, bevor der Fehler behoben ist

Diese Warnungen NIE ignorieren – sie schützen dich vor manipulierten Repositories.

🔹 2. Vertrauenswürdige Schlüssel anzeigen

APT (Debian/Ubuntu) speichert alle Signaturen der Paketquellen hier: ls /etc/apt/trusted.gpg.d/

Jede Datei dort steht für einen Schlüssel, der für Updates vertraut wird.

Wenn hier ein Schlüssel fehlt → kann APT Updates nicht verifizieren.

🔹 3. Signatur manuell prüfen (z. B. bei Downloads von GitHub)

Wenn du ein .tar.xz oder .iso herunterlädst, findest du oft daneben:

eine Datei .asc (Signatur)

eine Datei .sha256 (Checksummen)

Du kannst damit prüfen:

🔸 Hash prüfen
sha256sum DATEI.iso

→ ergibt eine lange Zeichenkette
→ muss mit der Hersteller-SHA256 übereinstimmen

🔸 Signatur prüfen

gpg –verify DATEI.asc DATEI Wenn alles korrekt ist, erscheint:

✔ Good signature from “NAME DES ENTWICKLERS”

🔹 4. postmarketOS / Alpine Linux (apk-tools)

postmarketOS nutzt apk, nicht apt.

Du prüfst die Repository-Signaturen so:

Repository-Schlüssel anzeigen sudo apk policy
oder:
ls /etc/apk/keys/
Dort liegen die öffentlichen Schlüssel der Maintainer.

Wenn apk update bei dir sofort abbricht, kommt das meistens durch:

fehlende Schlüssel

beschädigte Schlüssel

falsche Zeitzone

falsches Datum des Systems

defekte Repository-Server

Das könnte gefixt werden, sobald du so weit bist.
Doch das würde in einem separaten Blogbeitrag erörtert werden.

🛡️ Warum das Prüfen so wichtig ist

In der Linux-Welt ist das Paket-System eines der sichersten der Welt.
Aber es hängt von dir ab, Warnungen ernst zu nehmen.

Wenn die Signatur nicht stimmt:

🚫 Kein Update installieren
🚫 Kein Paket anfassen
🚫 Repository überprüfen
🚫 Schlüssel aktualisieren

Nur so bleibt dein System wirklich sicher.

Und vor allem:

✔ Dein Server bei Hetzner oder sonstigen Hostern
✔ Dein Laptop
✔ Dein postmarketOS-Smartphone

sind dadurch besser geschützt als jedes Windows-System.

💡 Fazit
Das Prüfen von Paketen ist kein kompliziertes Hacker-Werkzeug, sondern ein eingebauter Schutzmechanismus in jeder Linux-Distribution.
Du brauchst nur:

die Warnungen zu verstehen

und angewöhnen, auf Signaturen zu achten

Dann kann dir fast nichts passieren.