Wer alte Smartphones vor der Elektroschrott-Deponie retten möchte, landet schnell bei postmarketOS – einem echten, schlanken Linux-System für mobile Hardware. Doch wie viel Energie verbraucht ein solches System im Alltag, wenn kein aufgeblähtes Android im Hintergrund funkt? Ich habe den Praxistest auf meinem Xiaomi Mi A2 Lite gemacht und den Verbrauch über ein selbstgebautes Docker-Webinterface in Echtzeit gemessen.

Das Ergebnis ist absolut verblüffend.

Der Idle-Verbrauch: Ein absolutes Sparwunder

Im Leerlauf (Idle), bei eingeschaltetem, aber gedimmtem Bildschirm und aktiver WLAN-Verbindung, pendelte sich die Messung bei gerade einmal 0,6584 Watt ein.

Um diese Zahl greifbar zu machen, blicken wir auf die Laufzeit. Das Xiaomi Mi A2 Lite besitzt einen Akku mit einer Kapazität von rund 4.000 mAh. Bei einer durchschnittlichen Zellspannung von 3,85 Volt entspricht das einer gespeicherten Energie von knapp 15,4 Wattstunden (Wh).

Rechnen wir das mathematisch auf die Praxis um:

• Dauerbetrieb mit eingeschaltetem Display: Das Smartphone könnte theoretisch über 23 Stunden am Stück im Idle-Zustand laufen, bevor der Akku schlappmacht.
• Vergleich zu klassischen Servern: Ein typischer Raspberry Pi 4 genehmigt sich im Idle oft schon zwischen 2,5 und 3,5 Watt – und das ohne Display! Das alte Smartphone schlägt den Mini-PC in Sachen Effizienz im Grundzustand also um Längen.

Der Stresstest und die „1700-Watt-Explosion“

Spannend wurde es, als ich die acht Kerne des verbauten Snapdragon 625 Prozessors über ein automatisiertes Shellskript zu genau 50 % auslasten wollte. Im Docker-Webinterface schoss die Verbrauchslinie schlagartig nach oben und quittierte den Dienst plötzlich mit einem utopischen Wert: 1.707,84 Watt!

Keine Sorge, das Telefon ist nicht explodiert. Was war passiert? Unter plötzlicher Volllast bricht die Spannung am Akku für wenige Millisekunden minimal ein. Dieser rapide Wechsel überforderte den Qualcomm-Akkutreiber im Linux-Kernel. Statt des echten Stromwerts lieferte die Kernelschnittstelle (current_now) kurzzeitig eine astronomisch hohe Zahl im Milliardenbereich – ein klassischer Vorzeichen-Überlauf (Integer Overflow). Das Skript multiplizierte diesen Wert stur mit der Spannung, was zu einer theoretischen Leistung führte, die sonst eher eine Mikrowelle oder ein Wasserkocher benötigt.

Nachdem der Prozess gekillt und ein mathematischer Sicherheits-Filter im Mess-Skript integriert wurde, pendelte sich der reale Verbrauch unter Last bei realistischen 1,5 bis 2,2 Watt ein.

Fazit: Das perfekte Device für autarke Mini-Server?

Das Experiment zeigt eindrucksvoll, wie effizient Linux auf ARM-Architekturen arbeitet. Wenn man bedenkt, dass das Smartphone zeitgleich:

1. Den postmarketOS-Kernel betreibt,
2. Einen Docker-Container mit einem Nginx-Webserver hostet,
3. Im Sekundentakt Hardwaredaten abfragt, berechnet und via JSON bereitstellt,

…dann sind 0,65 Watt ein phänomenales Ergebnis. Durch den integrierten Akku bringt das Smartphone zudem seine eigene, unterbrechungsfreie Stromversorgung (USV) direkt mit. Wer einen extrem sparsamen, autarken Heimserver oder ein lokales Dashboard für Smarthome-Daten sucht, findet in alten Smartphones und postmarketOS eine genial nachhaltige Lösung.

In meinem privaten Kubernetes-Lab (K3s auf kompakten Wyse D10 T-48 Thin Clients) gab es heute eine spannende Troubleshooting-Session: Vom blockierten Port bis hin zur funktionierenden WordPress-Instanz.

🛑 Problem 1: Port 6444 blockiert & Connection Refused

Beim Versuch, den Cluster via kubectl abzufragen, verweigerte der K3s-API-Server den Dienst:

Plaintext

dial tcp 127.0.0.1:6443: connect: connection refused

Ein Blick in den Status zeigte: k3s.service war gecrasht. Grund dafür war ein Port-Konflikt auf der internen Supervisor-Schnittstelle:

Plaintext

failed to listen on 127.0.0.1:6444: listen tcp 127.0.0.1:6444: bind: address already in use

[ Systemd ] ──► versucht k3s.service (Server) zu starten ────┐
                                                             ├─► 💥 PORT 6444 KONFLIKT
[ Systemd ] ──► startet k3s-agent.service (Worker) ──────────┘

💡 Die Ursache & Lösung

Auf dem betroffenen Worker-Node (3-dietpi-trac) lief fälschlicherweise sowohl der k3s-agent.service als auch der k3s.service (Server/Control Plane).

Da ein Worker-Node keinen Control-Plane-Server benötigt und beide Instanzen um Port 6444 stritten, haben wir den Server-Dienst auf dem Worker deaktiviert:

Bash

sudo systemctl stop k3s
sudo systemctl disable k3s

Ergebnis: Port 6444 war frei, der k3s-agent verband sich wieder sauber mit dem Control-Plane-Node (1-dietpi-tik), und alle Nodes standen wieder auf Ready!

🐘 Problem 2: MySQL 8.0 vs. Ältere Thin-Client-Hardware

Nachdem der Cluster wieder stabil lief, sollte ein einfaches WordPress-Deployment her. Modernes MySQL 8.0 setzt jedoch neuere CPU-Befehlssätze (wie SSE4.2) voraus, die ältere Wyse Thin Client Prozessoren nicht unterstützen.

       [ MySQL 8.0 ] ──► FEHLER: Fehlende CPU-Instruktionen / Ressourcen-Hunger
                                     │
                                     ▼
       [ MariaDB 10.5 ] ──► LIGHTWEIGHT & ABSOLUT KOMPATIBEL 🚀

Die Lösung: Wechsel auf MariaDB 10.5. Das verbraucht deutlich weniger Arbeitsspeicher, läuft auch auf betagter x86-Hardware extrem performant und ist vollständig zu WordPress kompatibel.

🖼️ Der Cluster im Überblick (Headlamp)

📝 Das verwendete Kubernetes-Manifest

Das komplette Manifest für WordPress inkl. MariaDB und Anbindung über NodePort 30080:

YAML

apiVersion: v1
kind: Service
metadata:
  name: wordpress-mariadb
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mariadb
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-mariadb
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mariadb
  template:
    metadata:
      labels:
        app: wordpress
        tier: mariadb
    spec:
      containers:
        - image: mariadb:10.5
          name: mariadb
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: secretpassword
            - name: MYSQL_DATABASE
              value: wordpress
            - name: MYSQL_USER
              value: wordpress
            - name: MYSQL_PASSWORD
              value: wordpress
          ports:
            - containerPort: 3306
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080
  selector:
    app: wordpress
    tier: frontend
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
        - image: wordpress:latest
          name: wordpress
          env:
            - name: WORDPRESS_DB_HOST
              value: wordpress-mariadb:3306
            - name: WORDPRESS_DB_USER
              value: wordpress
            - name: WORDPRESS_DB_PASSWORD
              value: wordpress
            - name: WORDPRESS_DB_NAME
              value: wordpress
          ports:
            - containerPort: 80

🎯 Fazit

Mit ein wenig Troubleshooting und der richtigen Auswahl an schlanken Docker-Images lassen sich selbst ältere Wyse Thin Clients noch hervorragend als produktives K3s-Kubernetes-Home-Lab nutzen! Digitale Souveränität und Self-Hosting im Kleinformat. 💻✨