Die SD-Karte ist draußen — ein Tag am falschen Ende
Zweimal verlorene Langzeitstatistik, vier korrupte Datenbankdateien. Der Umzug auf eine NVMe kostete einen Tag, zwei fremde Fehler und zwei eigene Irrtümer.
Inhalt
- Warum überhaupt
- Die Lehre kam vor der Hardware
- Erstens: Das Kabel saß verkehrt herum
- Zweitens: Eine negative Plattengröße
- Meine zweite These, und warum sie falsch war
- Vier Sackgassen, um überhaupt an die Platte zu kommen
- Der Denkfehler, der den ganzen Plan umwarf
- Der Weg, der funktioniert hat
- Zwei Stolpersteine dabei
- Was dabei nebenbei herauskam
- Stand danach
- Und was heißt das?
Die SD-Karte in meinem Raspberry Pi in Meran ist draußen. Home Assistant läuft auf einer NVMe-SSD, 234 GB, davon 210 frei.
Bis dahin lagen: ein Tag Arbeit am falschen Ende, zwei Fehler fremder Software und zwei eigene Thesen, die sich als falsch erwiesen haben. Beide gehören in diesen Text, weil sie die Zeit gekostet haben.
Warum überhaupt
Zweimal ist mir die Langzeitstatistik gelöscht worden. Beide Male fehlten alle Messreihen ab demselben Zeitpunkt — Gesamtleistung, Außentemperatur, jeder Ventilfühler — und beide Male auf die Stunde genau zur selben Uhrzeit: zwei Uhr nachts UTC, wenn der nächtliche Aufräumlauf des Rekorders läuft.
Beim zweiten Mal war es nachweislich kein Update. Die Version war unverändert. Es war also etwas Wiederkehrendes, etwa monatlich, und es hielt nur rund acht Tage Statistik vor.
Dazu kamen vier korrupte Datenbankdateien mit zusammen 4 GB. Der Verdacht lag auf einer müden SD-Karte.
Die Lehre kam vor der Hardware
Acht Tage Vorhaltezeit heißt: wöchentlich sichern ist Pflicht, nicht Kür.
Meine Sicherung ins Repository funktionierte — sie hatte alles bis zum letzten Lauf gerettet. Sie lief nur zuletzt sechzehn Tage vorher. Die 180 Stunden dazwischen sind endgültig weg, kein zweiter Ort hat sie.
Darunter die einzigen Daten mit einem Gast, der anders lüftet als wir. Genau die Art Messreihe, die man nicht wiederholen kann.
Erstens: Das Kabel saß verkehrt herum
Nach dem Einbau sah der Kernel gar nichts. Kein nvme, kein sda, nur die
SD-Karte.
Hier war ich zu voreilig. Im PCI-Verzeichnis standen zwei Geräte, und ich hielt eines davon für die Platte. Es war der I/O-Chip des Pi 5 selbst. Was fehlte, war der zweite PCIe-Anschluss — der externe tauchte im Protokoll gar nicht auf.
Die Lösung war mechanisch: das Flachbandkabel umgedreht. Danach:
nvme nvme0: pci function 0001:01:00.0
nvme0n1 250059096 Blöcke (256,06 GB)
Der Konfigurationshinweis, den ich vorsorglich aus einem Wiki geholt hatte, war nicht nötig. Gut, dass das Kabel zuerst drankam.
Zweitens: Eine negative Plattengröße
Die Platte lief. Der Umzug nicht:
Cannot use ... as data disk as it is smaller than
the current one (new: -1065472, current: 125064691200)
Eine negative Größe. Der Kernel misst korrekt, das System führt die Platte ordentlich — nur die Verwaltungsschicht meldet Größe null und rechnet dann mit einer Null.
Und hier die Beobachtung, die alles entscheidet: Das ist kein Problem dieser
Platte. Drei Tage zuvor war derselbe Fehler mit exakt derselben Zahl
gemeldet worden — andere Hardware, andere Plattengröße, dieselbe -1065472.
Eine Konstante, die sich nicht mit der Plattengröße ändert, kommt nicht von der Platte.
Das ist ein Prüfkriterium, das ich mir gemerkt habe. Wenn eine Fehlermeldung eine Zahl nennt und dieselbe Zahl bei fremder Hardware auftaucht, ist der Wert nicht gemessen, sondern gerechnet — aus etwas, das fehlt.
Meine zweite These, und warum sie falsch war
Beim Vergleich der Geräteeigenschaften fiel genau ein Unterschied auf: Der SD-Karte war ein Partitionstisch zugeordnet, der fabrikneuen Platte nicht.
Die Vermutung lag nahe: Die Verwaltung leitet die Größe aus dem Partitionstisch ab, und bei einer fabrikneuen Platte gibt es nichts abzuleiten.
Das war falsch. Nach dem Schreiben eines GPT stand der Tisch da — und die Größe blieb null. Auch nach einem Neuladen. Auch nach einem vollständigen Neustart des Hosts, bei dem die zuständigen Dienste frisch starten und die Platte von Anfang an mit Tisch sehen.
Der fehlende Partitionstisch war ein Symptom der fabrikneuen Platte, nicht die Ursache.
Vier Sackgassen, um überhaupt an die Platte zu kommen
Jede einzelne spart beim nächsten Mal Zeit:
1. Das offizielle Terminal-Zusatzprogramm kann es nicht. Schreibzugriff meldet „Operation not permitted“. Der Grund: Es fordert gar keine Sonderrechte an. Deshalb gibt es dort auch keinen Schutzmodus-Schalter — es ist nichts da, was freizuschalten wäre.
2. Das erweiterte SSH-Zusatzprogramm kann es auch nicht. Es meldet die nötigen Fähigkeiten an, aber seine Geräteliste enthält die Platte nicht. Eine Fähigkeit nützt nichts gegen eine Liste, in der das Gerät fehlt. Auch mit abgeschaltetem Schutzmodus: dieselbe Meldung.
3. Die Tür ist der Zugang zum Container-Dienst des Hosts. Ein kurzlebiger privilegierter Container mit durchgereichtem Geräteverzeichnis sieht die Platte vollständig.
4. Drei Hürden auf dem Weg dahin:
- Host-Schlüssel geändert. Zwei Zusatzprogramme sind zwei SSH-Dienste mit eigenen Schlüsseln. Die Warnung war echt und erklärbar; der alte Eintrag musste weg.
- „Corrupted MAC on input“. Das Protokoll nannte das Angebot: ausschließlich
ETM-Varianten. Die Form ohne
-etmgab es dort nicht. - Über SSH ist man nicht root, im Web-Terminal desselben Programms dagegen schon. Daher „Permission denied“ bei Platte und Container-Dienst.
Der Denkfehler, der den ganzen Plan umwarf
Ich hatte vor, auf eine Behebung des Größen-Fehlers zu warten. Das war der falsche Plan, und zwar aus einem Grund, den ich erst beim Nachrechnen gesehen habe:
Die eingebaute Umzugsfunktion verschiebt nur die Daten. Der Systemstart wäre weiterhin von der SD-Karte gekommen.
Selbst ein funktionierender Umzug hätte die Karte also nicht überflüssig gemacht — und genau das war die Frage gewesen: Was muss man tun, damit man die SD-Karte komplett entfernen kann?
Monatelang auf eine Behebung zu warten, die das Problem gar nicht gelöst hätte: Das ist der teuerste Fehler des ganzen Tages, und er war reines Nachdenken, keine Technik.
Der Weg, der funktioniert hat
Der Pi 5 kann sich selbst als Kartenleser anbieten. Ein kleines Startprogramm lädt einen schlanken Kern in den Pi, der die angeschlossenen Laufwerke — SD, eMMC, NVMe, USB — dem angeschlossenen Rechner als gewöhnlichen USB-Massenspeicher reicht.
Die NVMe erscheint am Windows-Rechner als ganz normales Laufwerk. Von dort aus:
- Home Assistant OS direkt darauf schreiben
- Pi normal starten
- Sicherung einspielen
- SD-Karte raus
Vier Schritte. Nachdem der halbe Tag mit dem Versuch vergangen war, es von innen zu machen.
Zwei Stolpersteine dabei
Der Windows-Treiber. Das Gerät meldete einen fehlgeschlagenen Treibereinbau und brauchte eine manuelle Zuordnung mit erhöhten Rechten — deshalb von Hand ausgeführt, nicht aus dem Skript heraus.
Ein PowerShell-Fallstrick. Eine Variable namens $gadget kollidierte mit dem
Schalter -Gadget: PowerShell unterscheidet bei Variablennamen nicht zwischen
Groß- und Kleinschreibung. Der Abbruch lautete „Cannot convert … to type
SwitchParameter“ und sagt genau nichts über die Ursache. Seitdem heißt die
Variable anders.
Was dabei nebenbei herauskam
Das Betriebssystem-Update, das über die Luft wochenlang nicht ankam, war im frisch geschriebenen Abbild einfach enthalten.
Die Ursache dafür ist kurios: Der Dienst, von dem die Aktualisierung geholt wird, schickt seit einigen Wochen eine Sicherheitsrichtlinie von über 9 KB in den Kopfzeilen. Die verwendete Netzwerkbibliothek nimmt höchstens 8190 Byte an und bricht ab.
Der Umweg hat das Problem nicht gelöst, sondern umgangen. Das ist ein Unterschied, den man beim Aufschreiben ehrlich machen sollte — es kann wiederkommen.
Stand danach
| Betriebssystem | 18.3, frisch geschrieben |
| Platte | 234 GB gesamt, 210 GB frei |
| SD-Karte | draußen |
| Vier korrupte Datenbankdateien | miterledigt — sie lagen auf der Karte |
In Kapfenberg läuft derselbe Aufbau längst auf NVMe. Der Unterschied war nie eine Entscheidung, sondern eine Reihenfolge: Dort stand die Platte von Anfang an drin, hier wuchs die Anlage auf einer Karte, bis sie nicht mehr mochte.
Und was heißt das?
Für dich, wenn du noch auf einer SD-Karte bist:
- Zieh eine Sicherung der Langzeitstatistik, bevor du sie brauchst. Acht Tage Vorhaltezeit sind acht Tage. Was weg ist, ist weg — es gibt keinen zweiten Ort.
- Plane den Umzug, bevor die Karte müde wird. Korrupte Datenbankdateien sind das erste Anzeichen, nicht das letzte.
- Die eingebaute Umzugsfunktion macht die Karte nicht überflüssig. Sie verschiebt die Daten, nicht den Systemstart. Wenn dein Ziel „Karte raus“ ist, ist der Weg über den Rechner der kürzere.
- Prüf das Flachbandkabel zuerst. Es lässt sich verkehrt herum einbauen und sieht dabei richtig aus.
Und eine Regel, die über diesen Tag hinausgeht: Wenn eine Fehlermeldung bei fremder Hardware dieselbe Zahl nennt, ist es nicht deine Hardware. Ich habe einen halben Tag an einer Platte gesucht, die nie das Problem war.
Wenn du das verfolgen willst: nimm RSS
Kein Newsletter. Du gibst mir keine Adresse, ich führe keine Liste, und niemand muss einer Einwilligung zustimmen, um zu erfahren, dass ein Artikel fertig ist. RSS ist die ältere und für beide Seiten ehrlichere Lösung.
Wie das geht, und warum kein Newsletter
- 1Hol dir einen Feed-Leser. Ohne Konto geht das mit einer App am Telefon oder einer Erweiterung im Browser; wer mag, nimmt einen Dienst mit Konto.
- 2Trag die Adresse von oben dort ein.
- 3Fertig. Neue Artikel erscheinen von selbst in deinem Leser — ungelesen bleibt ungelesen, und nichts landet zwischen Rechnungen und Werbung im Postfach.
Warum das besser ist: Dein Leser holt die Datei ab. Ich bekomme keine Adresse und kann nicht sehen, wer liest oder ob jemand geöffnet hat. Abbestellen heißt, den Eintrag zu löschen — ohne Link, ohne Bestätigungsmail, ohne mich.
