Meine RaspiBlitz-Node läuft auf einem Raspberry Pi 5 mit 8 GB RAM, Hardware nach der Empfehlung von Blocktrainer: 52Pi-Metallgehäuse, ein UGREEN-USB-zu-SATA-Gehäuse mit einer SanDisk-SSD, das originale 27-Watt-Netzteil, eine SanDisk Extreme Pro als microSD-Karte. Auf den Lightning-Kanälen lag zu dem Zeitpunkt kein Guthaben – kein Backup- oder Seed-Risiko also, nur eine Node, die nicht mehr wollte, wie sie sollte.
Der erste Verdacht: eine SSD, die sich gesund meldet und trotzdem nicht funktioniert
Das WebUI zeigte irgendwann nur noch „401 Unauthorized", das Display am Gehäuse „6 Neustarts" während des Blockchain-Syncs. dmesg bestätigte den Verdacht: wiederholte I/O-Fehler (I/O error, dev sda, sector ...) und EXT4-Dateisystemwarnungen auf mehreren Sektoren. Das Muster einer defekten SSD, die bitcoind in eine Neustart-Schleife zwingt und damit auch gleich das WebUI-Backend mit lahmlegt.
Zur Absicherung lief die Platte zusätzlich durch CrystalDiskInfo (S.M.A.R.T.-Werte) und HD Tune (Error-Scan, Benchmark). Und genau hier wurde es interessant: S.M.A.R.T. meldete „gesund" – der reale Durchsatz im Error-Scan brach trotzdem auf etwa 1 MB/s ein, statt der beworbenen 545 MB/s, und schwankte stark erratisch zwischen 41 und 185 MB/s statt stabiler 350–416 MB/s im Vergleich zu einer baugleichen, gesunden Referenz-SSD am selben Port. Auch die Echtheit der Platte habe ich anhand von Verpackungsfotos und dem physischen Label geprüft, trotz einer irreführenden Software-Anzeige „WD Green" war es zweifelsfrei eine originale SanDisk SSD PLUS 2TB.
Die Reklamation, die an einem Formularfeld scheiterte
Das komplette Beweispaket – Fotos, das dmesg-Log, Benchmark-Screenshots – habe ich in einem PDF-Bericht gebündelt, als Grundlage für eine Garantiemeldung. Der Versuch, dafür ein Konto im WD/SanDisk-Supportportal anzulegen, scheiterte dann an einem hartnäckigen Bug im Telefonnummer-Validierungsfeld: Eine korrekt formatierte deutsche Mobilnummer wurde durchgehend abgelehnt, egal wie ich sie eingegeben habe. Statt weiter Zeit zu verlieren, bin ich auf die Amazon-Rückgabe-/Ersatz-Funktion ausgewichen – das ging unkompliziert. Als Ersatz kam eine neue SanDisk Ultra 3D SSD mit 2 TB (560 MB/s lesen, 520 MB/s schreiben), die problemlos ins vorhandene UGREEN-Gehäuse passte, da beide dem Standard-2,5"-SATA-Formfaktor folgen.
Neu aufgesetzt, und trotzdem vier Wochen kein Fortschritt
Mit der neuen SSD habe ich die Node komplett neu aufgesetzt, frische SD-Karte und frisch formatierte SSD. Dabei bewusst entschieden, weiter sowohl Tor als auch I2P zu betreiben, statt aus Bequemlichkeit auf reines Tor umzusteigen – ein Verzicht auf I2P wäre ein spürbarer Anonymitäts-Kompromiss gewesen.
Vier Wochen später hing die Blockchain-Synchronisation bei ca. 65 % fest. getconnectioncount zeigte durchgehend 0 aktive Peer-Verbindungen. Die Fehlersuche förderte diesmal nicht eine, sondern drei sich überlagernde Ursachen zutage, die ich nacheinander identifizieren und beheben musste.
Ursache 1: zu viel Speicher für den Block-Cache reserviert
free -h zeigte nur noch ca. 106 MiB freien RAM und 5,4 von 10 GiB belegten Swap, top zeigte aktive kswapd/kcompact-Kernel-Threads und 25 % I/O-Wait – das klassische Muster für massives Swap-Thrashing. Der Auslöser stand direkt in meiner bitcoin.conf: dbcache=4096 reservierte 4 GB RAM allein für den Block-Cache. Auf einem 8-GB-Pi, der parallel auch noch LND, Tor, I2P und fail2ball betreibt, viel zu aggressiv.
sed -i 's/dbcache=4096/dbcache=1200/' bitcoin.confNach dem Neustart von bitcoind fiel die Swap-Nutzung von 5,4 GiB auf 773 MiB. Die Block-Validierungsgeschwindigkeit verbesserte sich dramatisch, von etwa 43 Blöcken in 25 Tagen auf mehrere hundert Blöcke pro Stunde.
Ursache 2: eine veraltete Portweiterleitung am Router
I2P wählt bei jeder frischen Installation zufällig einen neuen externen Port für eingehende Verbindungen (NTCP2/SSU2). Meine FritzBox leitete aber weiterhin den alten Port 11562 weiter, aus einem früheren, längst gelösten „Waiting for Peers"-Vorfall. Der aktuelle i2pd-Port, 13275, war am Router nie eingetragen worden. Beide FritzBox-Freigaben (TCP und UDP) auf 13275 korrigiert, dazu passende Firewall-Regeln auf dem Pi ergänzt:
sudo ufw allow 13275/tcp
sudo ufw allow 13275/udpUrsache 3: der Port, der sich bei jedem Neustart neu würfelt
Nach dem Neustart von i2pd zur Anwendung des Fixes aus Ursache 2 war das Problem sofort wieder da. ss -tulnp verriet, warum: i2pd lauschte jetzt auf einem komplett neuen Port, 21991, nicht mehr auf 13275. Der Grund: In der i2pd.conf war für NTCP2/SSU2 kein fester Port eingetragen. Ohne feste Vorgabe würfelt i2pd bei jedem Start einen neuen Port. Der eigentliche Fix lag also nicht am Router, sondern in der Konfiguration selbst:
port = 13275Diese Zeile oberhalb der [http]-Sektion in /etc/i2pd/i2pd.conf ergänzt und i2pd neu gestartet. Seitdem bleibt der Port über Neustarts hinweg stabil und deckt sich dauerhaft mit Router- und Firewall-Freigabe.
ss -tnp | grep i2pd zeigte 12 aktive externe I2P-Verbindungen statt zuvor nur einer einzigen. getconnectioncount stieg von 0 auf 2 und blieb stabil. Im debug.log war ein kontinuierlicher Block-Fortschritt sichtbar, die Blockhöhe stieg im Minutentakt, der Sync-Fortschritt kletterte über die vorherigen 65,58 % hinaus.Was bei so einer Fehlersuche eigentlich zählt
Erst als alle drei Ursachen nacheinander behoben waren, RAM/Swap, die alte Portweiterleitung und der zufällige Port-Wechsel, normalisierte sich der Betrieb. Ein einzelner Fix allein hätte das Symptom nicht vollständig erklärt, und genau das macht diese Art von Fehlersuche eigentlich aus: Anonymitätsnetzwerke wie I2P sind beweglich, Ports können sich bei einer Neuinstallation und bei jedem Neustart ändern, wenn sie nicht explizit fixiert werden. Eine einmal eingerichtete Portweiterleitung ist keine Garantie für Dauerhaftigkeit. Geholfen hat am Ende vor allem, jede Ursache einzeln über die Log-Auswertung zu isolieren, statt vorschnell mehrere Dinge gleichzeitig zu ändern, das machte am Ende nachvollziehbar, welcher Schritt tatsächlich gewirkt hat.
Genau solche Stellen, dort wo die offizielle Doku aufhört und die Praxis anfängt, sind der Grund, warum Modul 4 der Kursreihe (Full Node auf dem Raspberry Pi 5) nicht nur die Schritte zeigt, die glatt laufen, sondern auch die, die es nicht tun. Mit den echten Log-Ausgaben und Werten aus dem eigenen Fehlerbild, nicht nachgestellt.
Willst du benachrichtigt werden, sobald Modul 4 startet?