"bad superblock" nach Kopierversuch

Wenn Du die originale SSD noch läuft, würde ich nochmals bei null anfangen und dieses mal die Partitionen anlegen und dann rsync (insoweit Du damit sicher bist) statt dd verwenden.

ODER mit rpi-clone die SSD clonen und nachträglich mit gparted die Grenzen verschieben.

Quote from pisel

dd /dev/sda1 auf /dev/sdb1

wenn du so kopierst, kopierst du alles dieses Volumes, auch die Partitionsinformationen.

So wie du es auch mit dem Ziel /dev/sdb2 und /dev/sdb3 gemacht hast.

Sinnvoller wäre ein wirkliches kopieren der Dateien gewesen, nicht die Partitionsinhalte.

tar cf - Quellverzeichnis | ( cd Zielverzeichnis;tar xf -)

Und die beiden können natürlich auch Mount-Points sein, was, beim so kopieren auch deshalb mit /dev/sda* nicht als Dateisysteme mit einen darin laufenden Linux sein sollten.

Ein Ansatz ist, ein Backup mit raspiBackup zu erstellen, und dann mit der Option -0 den Backup auf das vorher vorpartitionierte Device zu restoren.

Quote from pisel

Es geht um ~1TB und es wäre nur schön, wenn ich das nicht alles noch einmal kopieren müsste.

Dann ist das offenbar jetzt die Lektion für Dich, dass man Daten und System nicht auf ein und den selben Datenträger haben sollte. Genau das ist einer der Gründe dafür. Mit (jeweils) einem Backup wäre das an diesem Punkt kein Problem auf andere Datenträger umzusteigen oder einfach die "root"-Partition zu vergrößern.

Mir ist klar, dass Dir das jetzt nicht weiterhilft, aber zumindest könnte Dir das einen Denkanstoß für die Zukunft geben.

Quote from hyle

nicht auf ein und den selben Datenträger haben sollte.

Hm ... verstehe ich nicht. Ich verstehe den TE so, dass er ein existierendes System hat wo eine Parition zu klein ist und er die vergößern will. Also alles auf ein weiteres Device bringen wo die entsprechende Parition größer ist. Das geht händisch über verschiedene Umwege oder mit raspiBackup. Und das hat nichts mit

Quote from hyle

dass man Daten und System nicht auf ein und den selben Datenträger haben sollte.

zu tun.

Quote from framp

Hm ... verstehe ich nicht.

Quote from pisel

Dann habe ich mit dd /dev/sda1 auf /dev/sdb1 kopiert, /dev/sda2 auf /dev/sdb2 und /dev/sda3 auf /dev/sdb3.

Quote from pisel

Es geht um ~1TB

sda3 kann dann also nur eine Partition mit Daten sein.

Quote from pisel

Klar, der Superblock passt nicht zur Partitionstabelle.
Lässt sich das reparieren?

Wenn Du mit dd Partitionen kopierst, bleibt der Superblock an derselben Stelle auch am Ziel. Auf sdb2 musst Du aber das Filesystem bis zum neuen Ende der Partition ausdehnen.

Auf sdb3 könntest Du auch ein neues Filesystem erstellen und mit rsync die Quelldateien von sda3 dort hinein übertragen,

oder das Filesystem auf sda3 verkleinern (shrinken) und die Blöcke des geshrinkten Filesystems mit dd auf die sdb3 übertragen. Danach sda3 und sdb3 wieder bis zum Partitionsende das FS ausdehnen.

Siehe "man resize2fs"

Servus !

Quote from hyle

sda3 kann dann also nur eine Partition mit Daten sein.

Jupp. Aber warum ist es so verwerflich die Daten auf eine andere Partition zu legen? Es ist good practice - aber nicht mandatory. ... Dann alles auf ein neues Device zu kopieren mit dd ist ... Bullshit ... aber man kann wenn die Partitionen auf dem neuen Targetdevice entsprechend angelegt wurden mit rsync oder tar die existierenden Daten manuell kopieren. Oder eben, wie von mir erwähnt, einfach mit raspiBackup und Option -0

... Wobei mir gerade einfällt ... rpi-clone könnte das wohl auch direkt ohne den Umweg über ein raspiBackup. Das habe ich aber noch nie ausprobiert.

Quote from framp

Aber warum ist es so verwerflich die Daten auf eine andere Partition zu legen?

Verwerflich ist es nicht, aber mindestens unpraktisch. Wenn man z.B. bei einem neuen Release sein System neu aufsetzt, stört die dritte Partition, weil man nicht einfach das neue Image auf den Datenträger schreiben kann. Hinzu kommt noch, das der Datenträger ansich, auf dem das System liegt, höher beansprucht wird und damit die Ausfallrate höher sein dürfte, als bei einem Datenträger, auf dem nur ab und an Daten gelesen oder geschrieben werden.

Was Backups betrifft, brauche ich Dir ja nicht erklären. Von meinem Sytem-Datenträger mache ich wöchentlich ein Backup und vom Daten-Laufwerk reicht mir das monatlich.

Wenn man nur Partitionen vergrössern/verkleinern möchte, geht das eigentlich recht einfach mit (g)parted. Daten herum kopieren muss man nicht.

daxb Naja, man muss nicht, aber ich fühle mich bei solchen Aktionen wohler, wenn ich vorher eine Sicherheitskopie gemacht habe.

Quote from pisel

Quote from daxb

Wenn man nur Partitionen vergrössern/verkleinern möchte, geht das eigentlich recht einfach mit (g)parted. Daten herum kopieren muss man nicht.

Dazu hätte ich /dev/sda3 verkleinern und verschieben müssen. Dazu war ich zu feige.

Nun ja, es ist weit mutiger ne größere Partition "in ein kleineres Gefäß zu zwängen"...

von daher: wenn die sda3 genug freien Speicher hat, setz den Vorschlag von daxb um, verkleiner sda3 auf dem Quell-Datenträger und übertrag dann per dd die Partitonen und pass deren größen als dritter Schritt wieder an.