Kein Lebenszeichen vom Raspberry ...
-
@dr-pie sagte in Kein Lebenszeichen vom Raspberry ...:
Also nix mit Nullen .
was für Nullen?
Es steht doch in der Anleitung, dass Es auch sein kann, dass "nur" ein starker Rückgang in der Dateigröße möglich ist
Man schaut wann zuerst 'auffällige' Dateien mit Dateigröße 0 oder auffälligem Schwund zwischen zwei Dateien auftauchen, wie hier:
-
@homoran In der Anleitung steht ja
- Man schaut wann zuerst 'auffällige' Dateien mit Dateigröße 0 oder auffälligem Schwund zwischen zwei Dateien auftauchen, wie hier:
-
Es steht ja auch
Man schaut wann zuerst 'auffällige' Dateien mit Dateigröße 0 oder auffälligem Schwund zwischen zwei Dateien
da. Nicht das es immer eine Null-Datei gibt. Und die 'objects' sind bei dir ja auch in Ordnung, die 'states' ist kaputt. Also musst du dir diese Dateien anschauen.
ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep states -
@thomas-braun dann kommt das hier:
pi@raspberrypi:~ $ ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep states -rw-rwxr--+ 1 iobroker iobroker 207K 25. Feb 21:50 2022-02-25_21-50_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 25. Feb 23:50 2022-02-25_23-50_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 01:50 2022-02-26_01-50_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 03:51 2022-02-26_03-51_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 05:51 2022-02-26_05-51_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 07:52 2022-02-26_07-52_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 09:52 2022-02-26_09-52_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 11:52 2022-02-26_11-52_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 206K 26. Feb 13:53 2022-02-26_13-53_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 15:53 2022-02-26_15-53_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 17:53 2022-02-26_17-53_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 19:54 2022-02-26_19-54_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 21:54 2022-02-26_21-54_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 26. Feb 23:55 2022-02-26_23-55_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 01:55 2022-02-27_01-55_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 03:55 2022-02-27_03-55_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 05:55 2022-02-27_05-55_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 07:56 2022-02-27_07-56_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 09:56 2022-02-27_09-56_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 11:57 2022-02-27_11-57_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 13:57 2022-02-27_13-57_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 15:57 2022-02-27_15-57_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 17:58 2022-02-27_17-58_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 206K 27. Feb 19:51 2022-02-27_19-51_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 207K 27. Feb 20:13 2022-02-27_20-13_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 208K 27. Feb 20:16 2022-02-27_20-16_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 208K 27. Feb 20:17 2022-02-27_20-17_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 208K 27. Feb 20:19 2022-02-27_20-19_states.json.gz -rw-rw-r--+ 1 iobroker iobroker 219K 27. Mai 08:54 2022-05-27_08-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 219K 27. Mai 10:54 2022-05-27_10-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 219K 27. Mai 12:54 2022-05-27_12-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 219K 27. Mai 14:54 2022-05-27_14-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 214K 27. Mai 16:54 2022-05-27_16-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 214K 27. Mai 18:54 2022-05-27_18-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 214K 27. Mai 20:54 2022-05-27_20-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 214K 27. Mai 22:54 2022-05-27_22-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 214K 28. Mai 00:54 2022-05-28_00-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 214K 28. Mai 02:54 2022-05-28_02-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 214K 28. Mai 04:54 2022-05-28_04-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 213K 28. Mai 06:54 2022-05-28_06-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 213K 28. Mai 08:54 2022-05-28_08-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 213K 28. Mai 10:54 2022-05-28_10-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 213K 28. Mai 12:54 2022-05-28_12-54_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 199K 28. Mai 16:14 2022-05-28_16-14_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 200K 28. Mai 18:14 2022-05-28_18-14_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 199K 28. Mai 20:14 2022-05-28_20-14_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 200K 28. Mai 22:14 2022-05-28_22-14_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 200K 29. Mai 00:14 2022-05-29_00-14_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 200K 29. Mai 02:14 2022-05-29_02-14_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 199K 29. Mai 04:14 2022-05-29_04-14_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 200K 29. Mai 06:14 2022-05-29_06-14_states.jsonl.gz -rw-rw-r--+ 1 iobroker iobroker 199K 29. Mai 08:14 2022-05-29_08-14_states.jsonl.gz pi@raspberrypi:~ $ -
@dr-pie sagte in Kein Lebenszeichen vom Raspberry ...:
@thomas-braun dann kommt das hier:
dann war dein Crash wohl schon vor dem 15. Februar, wobei ichetwas erstaunt bin, dass nach dem 27. Februar direkt der 27. Mai kommt
-
@homoran Bis gestern Morgen lief alles wie gewohnt ..
Gestern wolle ich noch einiges in der Vis ändern und kam schon nicht mehr auf den Raspberry drauf
Firefox kann keine Verbindung zu dem Server unter 192.168.178.23:8081 aufbauen. -
@homoran
Der Zeit-Sprung wundert mich jetzt auch...@Dr-Pie
Schuß ins Blaue:
Knöpf dir die Datei2022-02-27_19-51_states.json.gzvor uns spiel die zurück. Ist nur zufällig gewählt, kann auch sein dass die alle 'kaputt' sind. -
reicht es denn dann so ?
iobroker stop cd /opt/iobroker/iobroker-data/ mv states.json states.json.old cd backup-objects/ gunzip -ck 2022-02-27_19-51_states.json.gz > /opt/iobroker/iobroker-data/states.json iobroker start -
Wieder mal ein perfektes Beispiel für mich, warum große Speichermedien für mich keinen Sinn machen. Lieber kleiner und öfter mal ein Image gezogen als eine root Partition, die zu 8% belegt ist. Nur mal zum Nachdenken.
-
Ja, müsste so funktionieren. Wenn die Quelldatei nicht auch schon kaputt ist.
-
pi@raspberrypi:~ $ iobroker stop cd /opt/iobroker/iobroker-data/ mv states.json states.json.old cd backup-objects/ gunzip -ck 2022-02-27_19-51_states.json.gz > /opt/iobroker/iobroker-data/states. json iobroker start mv: der Aufruf von stat für 'states.json' ist nicht möglich: Datei oder Verzeich nis nicht gefunden pi@raspberrypi:/opt/iobroker/iobroker-data/backup-objects $ -
@mickym sagte in Kein Lebenszeichen vom Raspberry ...:
Wieder mal ein perfektes Beispiel für mich, warum große Speichermedien für mich keinen Sinn machen. Lieber kleiner und öfter mal ein Image gezogen als eine root Partition, die zu 8% belegt ist. Nur mal zum Nachdenken.
Das kann man so eben nicht sagen!
eine zerstörte Karte kann es bei jeder Größe geben.Solange man nicht weiß warum das hier passiert ist, ist es müßig zu diskutieren.
8.7GB belegt sind allerdings sehr wenig -
Da ist von Februar auf Mai von json auf jsonl umgestellt worden.
iobroker stop cd /opt/iobroker/iobroker-data/backup-objects/ gunzip -ck 2022-05-27_08-54_states.jsonl.gz > /opt/iobroker/iobroker-data/states. jsonl iobroker start -
@homoran sagte in Kein Lebenszeichen vom Raspberry ...:
@mickym sagte in Kein Lebenszeichen vom Raspberry ...:
Wieder mal ein perfektes Beispiel für mich, warum große Speichermedien für mich keinen Sinn machen. Lieber kleiner und öfter mal ein Image gezogen als eine root Partition, die zu 8% belegt ist. Nur mal zum Nachdenken.
Das kann man so eben nicht sagen!
eine zerstörte Karte kann es bei jeder Größe geben.Solange man nicht weiß warum das hier passiert ist, ist es müßig zu diskutieren.
8.7GB belegt sind allerdings sehr wenigKlar kann es bei jeder Größe eine zerstörte Karte geben. Aber es ist halt einfacher ein IMAGE (ja ich weiß ihr mögt das nicht) von einer 16GB Partition zu ziehen, als von 128 GB. Und wenn man dann feststellt, dass nur 8% belegt sind, dann wollte ich das trotzdem mal als Denkanstoss geben. Wenn der arme @Dr-Pie es nun nicht mehr zum Laufen bringt, dann muss er das System sowieso neu aufbauen. Wenn er jedoch hin und wieder ein Image von einem funktionierenden System ziehen kann .... - Ich habe ja nur gesagt, mal zum Nachdenken. .....
-
@mickym sagte in Kein Lebenszeichen vom Raspberry ...:
128 GB
ich benutze die 128 GB nur weil ich jede Menge davon besitze ...
-
@dr-pie Mit einem Partition-Manager kann man auch die Partitionen wieder kleiner machen, unabhängig von der physischen Größe des Speichermediums. Damit wäre auch das Argument - dass immer die gleichen Zellen beschrieben werden hinfällig, da man dann einfach die Partition verschiebt. Wie gesagt - wenn Du nicht umhin kommst, das System neu aufzubauen, würde ich es mir überlegen.
-
@mickym said in Kein Lebenszeichen vom Raspberry ...:
Damit wäre auch das Argument - dass immer die gleichen Zellen beschrieben werden hinfällig
Kategorie: Mumpitz. Bei Flashspeichern gibt es keinerlei Möglichkeit die zu beschreibende Zelle zu beeinflussen. Diese Aufgabe übernimmt ausschließlich der Flashcontroller welcher im besten Fall versucht die Abnutzung aller Zellen möglichst zu leveln.
Wieder mal ein perfektes Beispiel für mich, warum große Speichermedien für mich keinen Sinn machen
Die Empfehlung kleine Flashspeicher (statt große) zu verwende halte ich übrigens für ziemlich Kontraproduktiv. Ein höheres "over provisioning" führt zwangsläufig zu einer längerer Lebensdauer von Flashstorage.
Eine 8 mal kleiner Karte als die 128GB, sprich die "empfohlenen" 16GB wird bei identischer Schreiblast eben auch nur 1/8 so lange halten
Aber es ist halt einfacher ein IMAGE (ja ich weiß ihr mögt das nicht) von einer 16GB Partition zu ziehen, als von 128 GB
Nur wenn man die Holzhackermethode
verwendet und unbeschriebenen Speicherplatz sichert. Glücklicherweise bietet jede anständige Lösung aber auch an nur den benutzen Speicher (natürlich inklusive aller Partitionsinformationen) zu sichern. 
Und selbst wer die Holzhackermethode
(z.B. dd) verwendet wird doch dann gleich noch "on the fly" komprimieren
was allerdings trotzdem ziemlicher Mist ist wenn es an den restore geht 
Das Vorgehen "stumpf" die ganze SD-Karte in ein image zu sichern lässt einen Flashsspeicher beim zurückspielen übrigens noch schneller/unnötigerweise altern
. Der geeignete Nutzer der deine "spezial Tipps" anwendet sorgt so für einen hausgemachten extra hohen WAF und schneller Tot 
seines Speichers. Zusätzlich kommt auch noch der Fakt hinzu das diese images wahrscheinlich mehr oder minder "gut" gealtert sind und als erstes mal eine Updateorgie (neue Schreiblasten für den armen flash
) nötig sind.Einfacher und nachhaltiger wird es sein einfach ein aktuelles OS neu aufzuspielen und eine aktuelle Sicherung des gewünschten Programms zurückzuspielen.
Mit einem Partition-Manager kann man auch die Partitionen wieder kleiner machen
Das sollte eine halbwegsmoderne software auch beim restore "on the fly" schaffen, ich glaube clonezilla kann das wahrscheinlich schon seit 10 Jahren oder mehr...
Ich habe ja nur gesagt, mal zum Nachdenken. .....
Über was genau?
Über das Bullshit-Asymmetrie-Prinzip? 
