Pi nebenbei
Fehlerbehebung

Honeygain auf dem Raspberry Pi: „exec format error“ beheben

Wenn docker run honeygain/honeygain auf dem Pi sofort mit exec format error abbricht, liegt es nicht an dir und nicht an einem Tippfehler. Das offizielle Image ist für Intel-Prozessoren gebaut, dein Pi hat einen ARM-Prozessor. Die Lösung ist ein einziger Befehl.

Warum die Meldung kommt

exec format error ist die Antwort des Linux-Kerns auf eine simple Frage: „Kann ich diese Datei ausführen?“ Die Antwort lautet nein, weil im Programm Maschinenbefehle für eine andere Prozessorarchitektur stehen. Dein Raspberry Pi meldet auf uname -m ein aarch64. Das Honeygain-Image enthält Befehle für x86_64 – also für Intel- und AMD-Prozessoren, wie sie in gewöhnlichen PCs stecken.

Docker macht das nicht besser: Ein Container teilt sich den Kern mit dem Wirtssystem. Er bringt kein eigenes Betriebssystem mit, das übersetzen könnte. Ohne Hilfsmittel kann ein ARM-Kern ein Intel-Programm nicht starten – Punkt.

Prüf zuerst, was dein Pi meldet Erwartet wird aarch64. Kommt dort armv7l, läuft ein 32-Bit-System, und dann hilft auch die Übersetzungsschicht nicht weiter – in dem Fall setzt du Raspberry Pi OS in der 64-Bit-Variante neu auf.

Architektur prüfen
uname -m

Die Übersetzungsschicht einrichten

Linux kann fremde Maschinenbefehle ausführen, wenn man ihm sagt, womit. Zuständig dafür ist binfmt_misc, eine Kernfunktion, die für bestimmte Dateitypen einen Übersetzer hinterlegt. Der Übersetzer heißt QEMU und läuft im Benutzermodus, das heißt: Er emuliert keinen ganzen Rechner, sondern nur die Befehle des Programms.

Das Image tonistiigi/binfmt trägt diese Verknüpfung für dich ein. Es läuft einmal durch, meldet sich ab und ist wieder weg – der --rm-Schalter räumt den Container sofort auf. Was bleibt, ist der Eintrag im Kern.

Einmalig ausführen
docker run --privileged --rm tonistiigi/binfmt --install all

Warum hier --privileged steht Der Befehl schreibt in den Kern des Wirtssystems, und dafür braucht der Container erweiterte Rechte. Das ist bei diesem einen Schritt unvermeidbar. Gib erweiterte Rechte niemals einem Container, der dauerhaft läuft oder aus einer Quelle stammt, der du nicht traust.

Der Eintrag überlebt keinen Neustart des Systems. Läuft dein Container mit --restart unless-stopped, startet Docker ihn nach dem Booten trotzdem – dann fehlt aber der Übersetzer, und der Container läuft in dieselbe Fehlermeldung. Der nächste Abschnitt löst das dauerhaft.

Honeygain vollständig einrichten

Falls Docker noch fehlt, ist das der vom Hersteller empfohlene Weg:

1 · Docker installieren
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker

Was curl … | sh tatsächlich macht Es lädt ein fremdes Skript und führt es sofort mit deinen Rechten aus. Bei get.docker.com ist das der offizielle Weg. Bei unbekannten Quellen lädst du das Skript besser herunter und liest es, bevor du es startest – das gilt für jede Anleitung im Netz, auch für diese.

2 · Übersetzungsschicht
docker run --privileged --rm tonistiigi/binfmt --install all
3 · Honeygain starten
docker run -d \
  --name honeygain \
  --restart unless-stopped \
  --platform linux/amd64 \
  honeygain/honeygain -tou-accept \
  -email [DEINE_HONEYGAIN_MAIL] \
  -pass [DEIN_HONEYGAIN_PASSWORT] \
  -device [NAME_FUER_DEN_PI]

Zum Passwort Es liegt im Container und lässt sich später über docker inspect honeygain im Klartext auslesen. Verwende deshalb ein eigenes, langes Passwort, das du nirgendwo sonst benutzt. Wer den Pi mit anderen teilt, sollte das im Kopf behalten.

Ob es läuft, zeigen die Protokollzeilen:

4 · Prüfen
docker logs honeygain

Damit es den Neustart überlebt

Die Übersetzungsschicht ist nach jedem Booten weg. Am saubersten trägst du sie als kleinen Systemdienst ein, der einmal vor Docker läuft. Dann startet Honeygain nach einem Stromausfall ohne dein Zutun wieder.

Dienst anlegen
sudo tee /etc/systemd/system/binfmt-arm.service >/dev/null <<'EOF'
[Unit]
Description=binfmt fuer fremde Architekturen
Before=docker.service

[Service]
Type=oneshot
ExecStart=/usr/bin/docker run --privileged --rm tonistiigi/binfmt --install all
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl enable binfmt-arm.service

Zum Nachprüfen Nach einem Neustart zeigt dir docker ps, ob der Container läuft. Steht dort nichts, hilft docker logs honeygain weiter – dort steht dann in aller Regel wieder die alte Fehlermeldung, und der Dienst oben war nicht aktiv.

Wieder loswerden

Ein Befehl, und der Container samt Inhalt ist weg. Das Konto löschst du separat im Dashboard des Anbieters.

Honeygain entfernen
docker rm -f honeygain
Häufige Fragen

Fragen zu diesem Thema

Warum reicht --platform linux/amd64 nicht allein?

Der Schalter sagt Docker nur, welche Variante des Images es holen soll. Ausführen muss die Befehle trotzdem dein Prozessor. Ohne die eingetragene Übersetzungsschicht bekommst du dieselbe Fehlermeldung, nur eine Stufe später.

Kostet die Emulation viel Rechenleistung?

Für Bandbreiten-Sharing spielt es keine Rolle. Der Dienst rechnet praktisch nicht, er leitet Datenverkehr weiter. Bei rechenintensiven Programmen wäre die Emulation dagegen deutlich spürbar.

Gibt es kein natives arm64-Image von Honeygain?

Zum Zeitpunkt der letzten Prüfung wird für den Raspberry Pi der Weg über die Übersetzungsschicht gebraucht. Anbieter ändern ihre Images ohne Ankündigung – ein Blick in die offizielle Dokumentation vor der Einrichtung schadet nie.

Bringt ein zweiter Pi im selben Netz mehr?

Nein. Honeygain lässt pro IP-Adresse nur ein Gerät zu, sonst erscheint die Meldung „Network overused“. Verkauft wird nicht Bandbreite, sondern der Zugang aus einem echten Haushalt – und der bleibt einer.

Läuft der Container nach einem Stromausfall wieder?

Nur mit dem Systemdienst aus dem Abschnitt oben. --restart unless-stopped allein startet zwar den Container, aber ohne Übersetzungsschicht bricht er sofort wieder ab.