[erledigt] SD-Karte duplizieren: Probleme mit dd

[GregorS]

Hallo allerseits!

Zum Testen und Experimentieren habe ich mir einen zweiten Raspberry Pi 3 gekauft und möchte nun die SD-Karte des ersten RPi für den Test-Pi kopieren.

Problem: Die Ursprungs-SD-Karte ist ein paar Byte größer als die SD-Karte des neuen Pi. Wenn ich das dd-Backup der Ursprungs-SD-Karte mit dd auf die neue Karte schreibe, bricht dd am Ende mit Fehler ab und gparted teilt mir mit, dass es keine Partition „außerhalb“ der Disk behandeln kann - die SD-Karte wird mit 100% nicht zugeteiltem Speicher angezeigt und im Pi bekomme ich nur ein „Kernel panic“ angezeigt.

Kann ich mit gparted oder einem anderen Tool die Ursprungs-Kopie (mit dd erstellt) so ändern, dass ich sie auf eine „kleinere“ (beide Karten haben 16 GB) schreiben kann?

Vielen Dank vorweg!

Gregor

[wolfn]

Ich habe schon mal ganz frech mit gparted die Partition einfach 'hinten zusammengeschoben', setzt natürlich voraus, daß da nicht irgendwas steht!

Sauberer ist auf alle Fälle, die Sys-Partition auf der Ziel-Karte frisch anzulegen, und den Inhalt dann per tar reinzukopieren.

Solltest aber in jedem Fall eine dd-Kopie der Original-SD vorher machen(darf nicht gemounted sein!!!).

Mit der aktuellen dd-Kopie wird nicht viel gehen, außer die neue Karte bietet mindestens genausoviel Platz.

[Tintom]

Eigentlich ist gparted schon richtig. Du musst halt nur die ursprüngliche SD-Karte nehmen und die Partition am Ende ein wenig verkleinern, damit sie die gleiche Größe erreicht wie die neue Karte. Nach dem Übertragen muss das Dateisystem auf der neuen (kleineren) Karte noch überprüft werden und das sollte es gewesen sein.

//edit: Bevor die Partition verkleinert wird muss das Dateisystem noch verkleinert werden, für ext* macht das resize2fs.

[wolfn]

Ja, er hat aber dabei das Risiko, das Dateisystem der Original-Karte auch zu demolieren, d.h. beim nächsten Booten von der Original-Karte ist wahrscheinlich mindestens ein fsck fällig...
Deswegen wollte ich lieber das Kopieren mit tar empfehlen, geht auf alle Fälle, ist halt umständlicher.

edit: warst schneller - so dürfte es auch gehen.

[GregorS]

Danke schonmal für Eure Antworten.

Das Original-Backup kleiner zu machen, ist keine schlechte Idee. Nur scheint gparted nur tatsächlich vorhandene *Geräte* zu erkennen. Wie ich das Programm dazu bringen könnte, die Backup-Datei zu bearbeiten, ist mir ein Rätsel. Hat jemand eine Idee hierfür?

Die Ursprungs-SD-Karte zu ändern könnte ich zwar machen, da ich ja ein dd-Backup habe, aber wohl fühlen würde ich mich dabei nicht.

Gruß

Gregor

[DeletedUserReAsG]

Nur scheint gparted nur tatsächlich vorhandene *Geräte* zu erkennen. Hat jemand eine Idee hierfür?

Wenn es mit parted nicht funktionieren sollte, bleibt noch der manuelle Weg.

[MSfree]

Problem: Die Ursprungs-SD-Karte ist ein paar Byte größer als die SD-Karte des neuen Pi.

Du kannst mit resize2fs das Dateisystem deiner Ursprungskarte ein paar kByte verkleinern und dann mit fdisk die Partitionsgröße der zweiten Partition um die verkleinerten kBytes anpassen. Danach kannst du mit dd ein entsprechend verkleinertes Image ziehen und auf die neue SD-Karte kopieren.

[owl102]

//edit: Bevor die Partition verkleinert wird muss das Dateisystem noch verkleinert werden, für ext* macht das resize2fs.

Das macht GParted schon alles von alleine (und zeigt das auch im Log an). Das Verkleinern mit GParted ist also IMHO eine gute Idee und benötigt keine Vorbereitung, wenn man mal von einem vorherigen Sicherheits-Backup der Karte (in eine Datei) absieht.

[GregorS]

Nochmal danke für Eure Antworten!

Ich komme wohl nicht darum herum, die Ursprungs-SD-Karte zu manipulieren. Nunja ... ein besseres Backup als eine dd-Kopie kann ich mir kaum vorstellen. Da kann ich mounten (-o loop), wie es mir gefällt, d. h. auf Sachen in /home oder /usr/local habe ich jederzeit Zugriff.

Gruß

Gregor

[debianoli]

Da kommst du schon herum, das geht.

Vor allem kannst du alle Änderungen an dem Image durchführen. Ich schreib dir später wie das geht

[debianoli]

So kannst du ein Image ändern:

Mit kpartx bindest du das Image als loop-Devices unter /dev/mapper ein:

Code: Alles auswählen

kpartx- av raspi.img

Jetzt kommt eine Ausgabe wie diese:

add map loop1p1 (254:3): 0 204800 linear /dev/loop1 2048
add map loop1p2 (254:4): 0 204800 linear /dev/loop1 206848
add map loop1p3 (254:5): 0 61440 linear /dev/loop1 411648
add map loop1p4 (254:6): 0 61440 linear /dev/loop1 473088
add map loop1p5 (254:7): 0 2048 linear /dev/loop1 534528
add map loop1p6 (254:8): 0 32768 linear /dev/loop1 536576
add map loop1p7 (254:9): 0 4194304 linear /dev/loop1 569344
add map loop1p8 (254:10): 0 2097152 linear /dev/loop1 4763648
add map loop1p9 (254:11): 0 14680064 linear /dev/loop1 6860800
add map loop1p10 (254:12): 0 2048 linear /dev/loop1 21540864
add map loop1p11 (254:13): 0 16384 linear /dev/loop1 21542912
add map loop1p12 (254:14): 0 204800 linear /dev/loop1 21559296
add map loop1p13 (254:15): 0 32768 linear /dev/loop1 21764096
add map loop1p14 (254:16): 0 37437440 linear /dev/loop1 21796864
add map loop1p15 (254:17): 0 1843200 linear /dev/loop1 59234304

Da sieht man, dass /dev/loop1 das virtuelle "Gerät" ist, also diese loop-Device entspricht deinem Image. Du kannst zB mit fdisk -l /dev/loop1 die Partitionen des Imgages abfragen.

fdisk -l /dev/loop1

Disk /dev/loop1: 29,1 GiB, 31272730624 bytes, 61079552 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3E3EC30D-26B4-11E5-B8E4-806E6F6E6963

Device Start End Sectors Size Type
/dev/loop1p1 2048 206847 204800 100M Microsoft basic data
/dev/loop1p2 206848 411647 204800 100M EFI System
/dev/loop1p3 411648 473087 61440 30M unknown
/dev/loop1p4 473088 534527 61440 30M unknown
/dev/loop1p5 534528 536575 2048 1M unknown
/dev/loop1p6 536576 569343 32768 16M unknown
/dev/loop1p7 569344 4763647 4194304 2G Linux filesystem
/dev/loop1p8 4763648 6860799 2097152 1G Linux filesystem
/dev/loop1p9 6860800 21540863 14680064 7G Linux filesystem
/dev/loop1p10 21540864 21542911 2048 1M Linux filesystem
/dev/loop1p11 21542912 21559295 16384 8M Linux filesystem
/dev/loop1p12 21559296 21764095 204800 100M EFI System
/dev/loop1p13 21764096 21796863 32768 16M Microsoft reserved
/dev/loop1p14 21796864 59234303 37437440 17,9G Microsoft basic data
/dev/loop1p15 59234304 61077503 1843200 900M Windows recovery environment

Zur Info: Das Image hier ist der per dd gesicherte Speicher eines Double-Boot Tablets. Per blkid erfährst du dann Infos zu den Dateisystemen etc.

Nun kannst du ganz normal per resize2fs und fdisk das Image ändern.

WICHTIG: Das machst du bei dem Ausgangs-Loop-Device. Also in dem Beispiel hier /dev/loop1

Bei den Partitionen machst du es wie hier beschrieben: https://geekpeek.net/resize-filesystem-fdisk-resize2fs/

Dann einfach das Gesamt-Image per dd auf die neue SD schieben. Evtl gibt es eine Fehlermeldung, aber die kann eigentlich egal sein. Du kannst später per fdisk/parted etc. die Partitions-Tabelle an die leichte Verkleinerung anpassen.

[GregorS]

So kannst du ein Image ändern: ...

Danke für die ausführliche Antwort!

Gruß

Gregor

[jph]

Auch wenn's erledigt ist, hier ein alternativer (und m.E. einfacherer Ansatz):

• Der Teil der SD-Karte vom ersten Sektor bis zum letzten Sektor der ersten Partition wird mit dd geklont. Damit sind MBR, Bootloader und FAT-Dateisystem auf der ersten Partition erledigt und das System grundsätzlich bootfähig.
• Danach passt man die Größe der zweiten Partition auf der Ziel-SD-Karte mit fdisk an.
• Das Dateisystem der zweiten Partition wird mit fsarchiver geklont.

Fertig.

[GregorS]

Auch wenn's erledigt ist, hier ein alternativer (und m.E. einfacherer Ansatz):

Danke! Genau so werde ich das bei nächster Gelegenheit machen.

Gruß

Gregor