Beiträge von RTFM

    Wenn dd schon zu schreiben begonnen hat, ist zumindest einmal die ursprüngliche Partition Table weg, bzw. mit den dd Daten überschrieben. Wenn es eine GPT war, sollte sich am Plattenende eine Kopie davon befinden.

    Wenn nur eine Partition vorhanden war, muss man den Anfangssektor vorerst raten (1024, 2048 ?).

    Wenn es eine Windows System-HD war, befinden sich vor der eigentlichen "Datenpartitione" noch weitere kleinere. Dann könnte man mit parted nach einem Partitionsanfang suchen, und den in die Partitionstabelle übernehmen. NTFS hat, wie EXT4 (und FAT auch) übrigens zwei Metadatenblöcke. Der zweite (Reserve-)Block beginnt bei NTFS mit einem ziemlich grossen Offset vom Startsektor entfernt. Wenn der erste Sektor der NTFS Partition bekannt ist, kann mit den mitinstallierten NTFS Tools versucht werden mit dem zweiten Metadatenblock zu starten.

    Wenn dd auch den zweiten Metadatenblock überschrieben hat, sollte es noch möglich sein mit Sleuthkit & CO die Daten, die noch von dd verschont blieben, wiederherzustellen.

    Servus !

    Bis das richtige Netzteil eintrifft kannst Du ja versuchen den Pi4 mit angestecktem USB-Stick zu starten. Dann verlagert sich der Anschaltstromstoss in den Bootablauf vor dem Einlesen der SD, und der Pi könnte den Spannungsabfall überleben.

    Servus !

    Edit: Oder Du schaltest WLAN und BT ab, dann bleibt auch mehr Strom für den Stick übrig.

    Die SD war noch nicht "komlett" voll, aber ziemlich voll, wobei versucht wird, grössere Files zunächst zusammenhängend abzuspeichern und dabei die letzten Sektoren des Filesystems erreicht wurden.

    Erst danach werden Sektoren zum Abspeichern eines grösseren Files herangezogen, die verstreut über den ganzen Speicherbereich liegen was einen grösseren Verwaltungsaufwand in den Metadaten erfordert.

    Wenn Du selbst nichts formatiert, oder Partitionen verändert, oder vergrössert hast, dann liegt der Fehler in der Distribution des Images, der aber bei denselben Umständen (fast volles FS) wieder auftreten wird.

    Wie das mit dem Löschen der Bilder funktionieren soll,weiß ich nicht, da ich MotionEyeOS nicht kenne. Ich weiß nur, dass man zum Löschen Schreibrechte braucht.


    Servus !

    Der "Fehler" ist dadurch entstanden, als bei der Rücksicherung eines Imagefiles eine um einen Sektor kleinere 8 GB SD Karte verwendet wurde, als das Image File (Speicherabbild) gross war. Das sollte bei der Rücksicherung auf die nunmehrige SD eigentlich als Fehlermeldung angezeigt worden sein. Jetzt wird versucht, beim Mounten der Partition 3 den letzten Sektor, der auf der SD nicht mehr vorhanden ist, zu verwenden, was natürlich nicht gelingt.

    Da die SD sowieso sehr merkwürdig partitioniert ist (P2 endet bei Sektor 655.359, P3 beginnt bei Sektor 2.097.152 und zwischen P1 und P2 ist auch ein Loch), kannst Du versuchen die ganze /dev/sdd3 in ein Partitions-Image-File zu sichern, die Partition 3 mit einem kleineren Sektoranfang neu zu erstellen (irgendwo zwischen 655.360 und 2.097.151 Anfang /dev/sdd3) und in die neue Partition das Partitions Image File zurückzusichern. Danach das Filsystem vergrössern (mit resize2fs) und allenfalls auch e4defrag verwenden.

    Info: dd if=/dev/sdd3 of=/Pfad/zum/sicherungsfile/p3tmp.img [input File= output File=] für Partition 3

    dumpe2fs zeigt die EXT4-Metadaten in lesbarer Form an.

    fdisk. parted, cfdisk, sfdisk sind installierte Partitionsprogramme, auch interktiv verwendbar.


    Servus !

    PS: Ich bleibe dabei: Die SD selbst ist nicht kaputt.

    Wegen dem einen Block brauchst Du nicht abbrechen.

    Du kannst ja auch einen dry-run vornehmen, wenn Du fürchtest, dass der Pi explodiert.

    Mit < e2fsck -nfv /dev/sdd3 > werden alle Systemanfragen mit nein beantwortet und vorerst keine Änderungen vorgenommen, mit -y (statt -n) wird jede Anfrage vom Programm mit yes automatisch beantwortet.

    Was auch immer repariert wurde, Du solltest danach nocheinmal mit -pfv das e2fsck durchlaufen lassen.

    Servus !

    Geht garnicht anders als am Linux Laptop.

    Vorraussetzung:

    Kenntnisse der Unterschiede von Partitionstabelle, Partition und Filesystem.

    Reihenfolge:

    [1. Allfälliges e2fsck auf die ungemountete root Partition ]

    2. Verkleinern (shrinken) des EXT4 root Filesystems mit resize2fs (und "undo"- Option bei fehlender Datensicherung)

    3. Verkleinern der root Partition auf das neue Partitionsende mit z.B. (G)parted, ausserhalb des Filesystemendes.

    4. Mit resize2fs root Partition auf die neue Partitionsgröße ausdehnen.

    [5. sync nicht vergessen]

    Jeder genannte Befehl hat eine Man-Page.


    Servus !

    Wenn Du ein USB Gerät ansteckst, wird nicht immer dieselbe Devicekennung vergeben. Die SD im Kartenleser kann beim neuerlichen Anstecken auch unter /dev/sdc, oder /dev/sdf erscheinen. Mit "list Blockdevices" < lsblk > kannst Dir die aktuelle Kennung aller Blockdevices anzeigen lassen.

    Meine Kopfrechenkünste sind ziemlich Mau. Bei den 128 GB habe ich mich ordenlich verrechnet.

    Servus !

    Hoppala, ich habe eigentlich den Fehler von #2 gemeint.

    Mir fehlen aber die Gerätedateien.

    Kannst Du noch die Ausgabe des EXT4 Metadaten-Headers posten ?

    root# < tune2fs -l /dev/sdd2 >

    Und danach könntest Du die Partition nochmals mit der Badblockprüfung durchlaufen lassen. Dauert aber wesentlich länger. root # < e2fsck -pfcv /dev/sdd2 >

    Die SD ist ziemlich voll (für eine 128 GB SD ).

    Servus !

    PS: Eine SD ist für mich erst dann defekt, wenn Du zwei Teile davon in der Hand hast, oder der Bereich über dem Kartenkontroller verschmorrt/geschmolzen ist. Dann würden die Programme aber garnicht funktionieren.