Wie erstelle ich ein Bild (.img) von der SD-Karte (aber so kompakt wie das Original)?

Ich habe es versucht:

sudo dd bs=4k if=/dev/mmcblk0 of=/media/1BAB47551C66A42B/raspbian_migs2.gz

Es wird eine .img-Datei mit 7,6 GB erstellt (Kartengröße, ABER was auf der Karte ist, hat 700 MB).

Und:

sudo dd bs=4k if=/dev/mmcblk0 | gzip > /media/1BAB47551C66A42B/raspbian_migs2.gz

Erstellt eine .gz-Datei mit 2,7 GB.

Der ursprüngliche Raspbian ( Debian 7 (Wheezy)) von http://www.raspberrypi.org/downloads hat 494,44 MiB.

Wie kann ich von der SD-Karte aus ein Bild mit einer ähnlichen Größe erstellen?

(Ich bin auf Ubuntu.)

Sie erwähnen in einem Kommentar zu RooTer, dass A) Sie die ursprüngliche Partitionsgröße mit reduziert haben gparted, aber dddennoch die gesamte Karte kopieren , und B) beide Partitionen in das Image aufnehmen möchten.

Das Problem "A" ist leicht zu erklären: Sie kopieren immer noch die gesamte Karte, da sich das darauf /dev/mmcblk0bezieht. Die einzelnen Partitionen sind natürlich /dev/mmcblk0p1und /dev/mmcblk0p2. Dies ist die Komplikation in Problem "B", aber Sie können nicht einfach ddjede Partition und die beiden Dateien zusammen verketten, da die Partitionstabelle am Anfang /dev/mmcblk0 den Anfang und die Länge jeder Partition indiziert. Ohne das wird das Bild unbrauchbar.

Sie können jedoch die Länge jeder Partition abrufen fdisk -lund damit einige Parameter für bestimmen dd. Beispielsweise:

> fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 16.1 GB, 16138633216 bytes
4 heads, 16 sectors/track, 492512 cylinders, total 31520768 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
Disk identifier: 0x00017b69

Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1    8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2  122880    26746879    13312000   83  Linux

Die Einheiten "Start" und "Ende" sind Sektoren. Beachten Sie, dass die Sektorgröße 512 Byte beträgt. Für /dev/mmcblk0p2, 26746879 (letzter Sektor) - 122880 (erster Sektor) = 26623999/2 (für 2 Sektoren pro kB) / 1024 (kB pro MB) / 1024 (MB pro GB) = 12,69, wobei ich die Partition mit gparted vergrößerte auf 12 GB, das sieht also richtig aus (eigentlich sollte ich 1000 und nicht 1024 als Divisor mit Speicher verwenden, was auf 13,31 GB hinausläuft, aber ich vermute, dass gparted und einige andere Tools auch 1024 verwenden).

Das erste, was Sie überprüfen möchten, ist, dass Ihre zweite Partition wirklich die kleinere Größe hat, auf die Sie sie eingestellt haben. Verwenden Sie als Nächstes einfach diese Zahlen mit dd; für mich wäre es:

dd if=/dev/mmcblk0 of=rpi.img bs=512 count=26746880

Ich habe dort einen zusätzlichen Sektor, um jegliche Art von Missverständnissen zu vermeiden dd. Es gibt eine einfache Möglichkeit zu überprüfen, ob dies funktioniert hat:

> fdisk -l rpi.img

Disk rpi.img: 102 MB, 102400000 bytes
255 heads, 63 sectors/track, 12 cylinders, total 200000 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
Disk identifier: 0x00017b69

Device Boot      Start         End      Blocks   Id  System
rpi.img1          8192      122879       57344    c  W95 FAT32 (LBA)
rpi.img2        122880    26746879    13312000   83  Linux

Beachten Sie, dass hier eine gewisse Diskrepanz besteht: Die Sektoren "Start" und "Ende" stimmen mit der ursprünglichen Partitionstabelle überein, aber die Gesamtgröße in der oberen Statistik beträgt nur 102 MB! Dies liegt daran, dass ich eigentlich count=200000als Parameter verwendet habe, ddweil ich mich nicht wirklich mit einer 12-GB-Kopie beschäftigen wollte (beachten Sie auch "insgesamt 200000 Sektoren"). Der Grund, warum die Tabelle unten dies nicht widerspiegelt, ist, dass fdisk seine Informationen aus den Partitionsdaten abruft, die wörtlich am Anfang des Abbilds vom Anfang der SD-Karte kopiert wurden aufrecht erhalten. Wenn ich den Rest (richtig) kopiert hätte, wären die Zahlen kopaketisch und das Bild wäre lebensfähig.

Probieren Sie das aus. :)

Ich würde vermuten, dass das Problem in einst genutzten Sektoren liegt, in denen sich noch Schmutz befindet. Sobald die Datei gelöscht ist, werden nur die Metadaten aus dem Dateisystem entfernt, nicht die Daten selbst. Dadurch bleiben einige zufällige Ein-Nullen übrig, anstatt einfach nur Null-Blöcke zu komprimieren.

Einfache Lösung, erfordert jedoch das Umschreiben des gesamten freien Speicherplatzes auf der Karte. Denken Sie daran, dass die Lebensdauer der SD-Karte durch die Anzahl der erneuten Schreibvorgänge begrenzt ist. Dies ist daher keine bevorzugte Methode.

dd bs=4M if=/dev/zero of=/root/junk
sync
rm junk

Eine aufwändigere Lösung, da Sie null kostenlos auf einem anderen Computer installieren müssen, der diese SD-Karte zurzeit nicht verwendet.

zerofree /dev/mmcblk0p2

Weitere Informationen finden Sie unter http://intgat.tigress.co.uk/rmy/uml/index.html

Was Sie sich merken müssen, ist, dass Sie mit dd von / dev / mmcblk0 das gesamte Gerät kopieren, auch wenn die Partitionen kleiner sind. Wenn Sie raspi-config verwendet haben , um die Hauptpartition zu erweitern, bevor Sie eine der oben genannten Methoden ausgeführt haben, ist dies in Ordnung.

PS Wenn es Ihnen nichts ausmacht, das Format der Bilddatei zu ändern, können Sie partimage verwenden, das für bekannte Dateisysteme freigegebene Blöcke auslässt, auch wenn sie noch Schmutz enthalten. Wiederum ist partimage am besten zu verwenden, wenn das Dateisystem nicht gemountet ist, um eine Beschädigung der Sicherung zu vermeiden. Sie könnten wahrscheinlich davonkommen, wenn Sie es nur mit Lesezugriff wieder einhängen, aber ich werde es Ihrem Ermessen überlassen.

Kurze Antwort - Verwenden Sie eine 2 GB SD-Karte.

Lange Antwort, ddhat keine Ahnung, wo die "guten" Daten enden, muss man es irgendwie sagen.

Es gibt zwei Möglichkeiten, am einfachsten ist es, eine 2 GB SD-Karte zu verwenden, die das Kopieren über 2 GB hinaus automatisch stoppt und zu einer komprimierten Datei von 500 MB führt, wie Sie es wünschen.

Die andere, kompliziertere und kompliziertere Methode besteht darin, die richtige Datengröße aus Ihrer Partitionstabelle zu berechnen und diese richtige Größe als zu ddbefehlenden Parameter anzugeben . Zu diesem Zweck können Sie die Parameter bs=XXX(Blockgröße) und count=XXX(Blockanzahl) verwenden. Sie können bs=10Mbeispielsweise eine Blockgröße von 10 MB angeben (dies würde das Kopieren im Vergleich zu 4 KB Blockgröße, die Sie in Ihren Befehlen verwenden, definitiv beschleunigen) und count=20010 MB * 200 = 2000 MB (2 GB) kopieren. Möglicherweise müssen Sie die Blockgröße und die Blockanzahl gemäß Ihrem SD-Karten-Partitionsschema anpassen .

dd - copy and convertist nicht das richtige Werkzeug, um die von Ihnen angeforderte Arbeit zu erledigen. Es ist ein sektorweises Kopier- und Konvertierungstool auf niedriger Ebene, das sich hervorragend zum Kopieren von Startsektoren, zum Formatieren von Geräten und für alle Arten von Aufgaben auf niedriger Ebene eignet. Wenn Sie verwenden dd, kopieren Sie Sektor für Sektor in das Image, auch wenn es nicht in der Dateisystemstruktur enthalten ist.

Die von der Raspberry Pi Foundation bereitgestellten Images sind speziell kompilierte Images mit Installationsskripten, Entpacken der Binärdateien und Ersteinrichtung. Danach müssen Sie ohnehin Updates aus dem Internet herunterladen.

Eine beliebte Lösung für das Kopieren von leeren Sektoren zu vermeiden ist die Verwendung eines Dateiebene Kopiersystem - und Clonezilla ist Standalone, bootfähig von einer CD, ähnlich wie ye olde Norton Ghostaber Clonezilla unterstützt die Linux (und mehr) Dateisysteme. Daher werden nur Dateien kopiert, die gerade verwendet werden, und es wird nur aus diesen Dateien ein Container erstellt. Reduziert die Größe erheblich!

• Hier ist eine Anleitung, die zeigt, wie Sie von einer bootfähigen CD den Pi von der SD sichern können

Ich hatte genau die gleiche Frage und wollte ein einfach zu bedienendes Tool. Nachdem ich einen gesucht und nicht gefunden hatte, schrieb ich mkimg.sh . Ich skizziere den von mir verwendeten Prozess unter: /raspberrypi//a/37899/32585