Warum du beim RaspiBlitz-Setup manchmal zweimal flashen musst

Die ursprüngliche SSD in meiner Node hatte defekte Sektoren und musste raus. Ersatz: eine brandneue, nie zuvor benutzte SanDisk Ultra 3D. Neue Platte eingebaut, RaspiBlitz-Setup-Assistent gestartet, Schritt „Prepare Drive" – und genau dort stand plötzlich wieder dieselbe Fehlermeldung am Display, die ich schon vom allerersten Setup kannte. Nicht mitten im Betrieb, nicht nachdem irgendetwas schon lief: direkt beim Einrichten der neuen Platte, bevor überhaupt irgendetwas synchronisiert werden konnte.

Der eigentliche Auslöser: das Datenlaufwerk wird nicht erkannt

Die Fehlermeldung im Assistenten:

error='storagePartition not detected'
FAIL: blitz.data.sh mount failed
ERROR - please report to development team

Die Ursache: Die externe SSD hat weder Partitionsschema noch Dateisystem – roh ab Werk. RaspiBlitz erwartet eine selbst angelegte Partition und bricht in diesem Fall bewusst hart ab, statt automatisch zu formatieren.

Der schnellste erste Versuch, bevor es technischer wird: Es gibt begründeten Verdacht auf ein reines Timing-Problem bei der USB-Erkennung direkt nach dem Boot. Lohnt sich also erst mal, im Assistenten die Seite neu zu laden und den „Prepare Drive"-Schritt (inklusive „Ja, alle Daten löschen") einfach noch einmal zu versuchen – das löst den Fehler manchmal schon ganz ohne manuellen Eingriff auf.

Hat das nicht geholfen, geht es per SSH weiter. Diagnose zuerst: lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT – zeigt das Laufwerk keinen Eintrag unter FSTYPE und keine Kind-Partitionen, ist es tatsächlich unformatiert. Der Fix läuft danach manuell:

sudo /home/admin/config.scripts/blitz.data.sh setup STORAGE sda 0

Wichtig dabei: Der Skriptname ist versionsabhängig. Ab RaspiBlitz-Version 1.12 heißt er blitz.data.sh, bis Version 1.11 blitz.datadrive.sh. Mit ls -la /home/admin/config.scripts/ | grep -i data lässt sich das vorher prüfen, statt zu raten. Danach mounten: sudo /home/admin/config.scripts/blitz.data.sh mount – „Already mounted: /mnt/disk_storage" bestätigt den Erfolg.

Und genau das erzwingt den zweiten Flash

Weil dieser Befehl manuell außerhalb des regulären Setup-Assistenten läuft, passt der interne Zustand auf der SD-Karte danach nicht mehr zum erwarteten Ablauf. RaspiBlitz erkennt das über einen eingebauten Sicherheitscheck und verlangt genau deshalb: PLEASE START WITH A FRESH SD CARD IMAGE. Kein Fehlschlag, sondern bewusstes Sicherheitsdesign – RaspiBlitz repariert einen inkonsistenten Zustand nicht, sondern verlangt einen sauberen Neustart. Die gute Nachricht: Die externe Festplatte bleibt dabei angeschlossen. Du flashst nur die SD-Karte neu (Image von github.com/raspiblitz/raspiblitz/releases), und der Setup-Assistent erkennt die bereits vorbereitete Partition beim nächsten Durchlauf automatisch über seine Recover-Funktion – ohne sie erneut zu formatieren. Genau das macht den zweiten Durchlauf beim zweiten Mal auch so viel schneller: Das Muster war schon bekannt.

Kein Einzelfall: ein offenes GitHub-Issue bestätigt das Muster

Was diesen Fall besonders macht: Eine nagelneue, nie zuvor benutzte Platte mit demselben Symptom ist ein starkes Indiz, dass es nicht an der Festplatte liegt. Tatsächlich gibt es dazu ein offenes, bislang unbestätigtes Issue im RaspiBlitz-Repository (GitHub #5158), das exakt dasselbe Symptom bei anderen Nutzern mit brandneuer Hardware beschreibt.

Woran du wirklich erkennst, dass es geklappt hat

Nach dem Reflash zeigen weder das LCD-Display noch die Web-Oberfläche zuverlässig an, ob das Laufwerk tatsächlich korrekt eingebunden ist – es erscheint einfach derselbe generische „ready for setup"-Bildschirm, unabhängig vom tatsächlichen Mount-Zustand. Verlässliche Gewissheit gibt es nur per SSH:

df -h
bitcoin-cli getblockchaininfo

df -h zeigt, ob das Laufwerk tatsächlich unter /mnt/disk_storage mit der erwarteten Größe eingehängt ist. Ein zweiter Aufruf von bitcoin-cli getblockchaininfo im Abstand einiger Minuten zeigt, ob blocks und headers tatsächlich steigen – dann läuft die Synchronisation wirklich.

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 Screenshots vom eigenen Fehlerbild, nicht nachgestellt.