Comment créer une image (.img) à partir de ce qui se trouve sur la carte SD (mais aussi compacte que l'original)?

J'ai essayé:

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

Il crée un fichier .img avec 7,6 Go (taille de la carte, MAIS ce qui est sur la carte a 700 Mo).

Et:

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

crée un fichier .gz de 2,7 Go.

Le Raspbian original ( Debian 7 (Wheezy)) de http://www.raspberrypi.org/downloads a 494,44 MiB.

À partir de ce qui se trouve sur la carte SD, comment puis-je créer une image de taille similaire?

(Je suis sur Ubuntu.)

Vous mentionnez dans un commentaire à RooTer que A) vous avez réduit la taille de partition initiale avec gparted, mais ddcopie toujours la carte entière, et B) que vous souhaitez inclure les deux partitions dans l'image.

Le problème "A" est facile à expliquer: vous copiez toujours la carte entière parce que c'est ce /dev/mmcblk0à quoi il fait référence. Les partitions individuelles sont bien sûr /dev/mmcblk0p1et /dev/mmcblk0p2. Il s'agit de la complication du problème "B", mais vous ne pouvez pas simplement ddchaque partition et concaténer les deux fichiers ensemble, en raison de la table de partition au début /dev/mmcblk0 qui indexe le début et la longueur de chaque partition. Sans cela, l'image sera inutilisable.

Cependant, vous pouvez obtenir la longueur de chaque partition fdisk -let l'utiliser pour déterminer certains paramètres pour dd. Par exemple:

> 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

Les unités "Début" et "Fin" sont des secteurs, et notez que la taille du secteur est donnée, 512 octets. Pour /dev/mmcblk0p2, 26746879 (le dernier secteur) - 122880 (le premier secteur) = 26623999/2 (pour 2 secteurs par Ko) / 1024 (Ko par Mo) / 1024 (Mo par Go) = 12,69, dont j'ai augmenté la partition en utilisant gparted à 12 Go, donc cela semble correct (vraiment, je devrais utiliser 1000 et non 1024 comme diviseur avec stockage, ce qui équivaut à 13,31 Go, mais je soupçonne gparted et certains autres outils utilisent également 1024).

Donc, la première chose que vous voulez vérifier est que votre deuxième partition est vraiment la taille la plus petite à laquelle vous la définissez. Ensuite, utilisez simplement ces chiffres avec dd; pour moi ce serait:

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

J'ai un secteur supplémentaire là-bas pour éviter toute sorte de coupure par un malentendu sur le ddfonctionnement. Il existe un moyen simple de vérifier si cela a fonctionné:

> 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

Notez qu'il y a un peu de différence ici: les secteurs "Début" et "Fin" correspondent à la table de partition d'origine, mais la taille totale dans les statistiques en haut n'est que de 102 Mo! C'est parce que je l'ai utilisé count=200000comme paramètre ddparce que je ne voulais pas vraiment me soucier d'une copie de 12 Go (notez également "200000 secteurs au total"). La raison pour laquelle le tableau en bas ne reflète pas cela est que fdisk obtient ses informations des données de partition copiées textuellement au début de l'image depuis le début de la carte SD, ce qui, comme je l'ai mentionné dans le deuxième paragraphe, est vital Maintenir. Si j'avais (correctement) copié le reste, les chiffres seraient copacétiques et l'image serait viable.

Essayez ça. :)

Je suppose que le problème réside dans des secteurs autrefois utilisés qui contiennent encore de la saleté. Une fois le fichier supprimé, seules les métadonnées sont supprimées du système de fichiers, pas les données elles-mêmes, laissant ainsi des zéros aléatoires au lieu de compresser facilement des blocs contenant uniquement des zéros.

Solution facile, mais nécessite de réécrire tout l'espace libre sur la carte. N'oubliez pas que la durée de vie de la carte SD est limitée par le nombre de réécritures, ce n'est donc pas la méthode préférée.

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

Solution plus impliquée, car vous devez installer zerofree sur un autre ordinateur qui n'utilisera pas cette carte SD à l'époque.

zerofree /dev/mmcblk0p2

Pour plus d'informations sur http://intgat.tigress.co.uk/rmy/uml/index.html

Ce que vous devez vous rappeler, c'est qu'en faisant dd de / dev / mmcblk0 vous copiez le périphérique entier, même si les partitions sont plus petites. Si vous avez utilisé raspi-config pour étendre la partition principale avant de faire l'une des méthodes ci-dessus, tout ira bien.

PS Si cela ne vous dérange pas de changer le fichier d'image au format, vous pouvez utiliser partimage qui, pour les systèmes de fichiers connus, omet les blocs libérés même s'ils contiennent encore de la saleté. Encore une fois, il est préférable d'utiliser partimage lorsque le système de fichiers n'est pas monté pour éviter la corruption de la sauvegarde. Vous pourriez probablement vous en sortir en le remontant en lecture seule, mais je le laisserai à votre discrétion.

Réponse courte - utilisez une carte SD de 2 Go.

Réponse longue, ddn'a aucune idée où se terminent les "bonnes" données, vous devez le dire en quelque sorte.

Il existe deux façons, la plus simple est d'utiliser une carte SD de 2 Go, qui arrêtera automatiquement la copie au-delà de 2 Go et générera un fichier compressé de 500 Mo comme vous le souhaitez.

L'autre façon, plus compliquée que celle impliquée, consiste à calculer la taille de données correcte à partir de votre table de partition et à spécifier cette taille correcte en tant que paramètres à ddcommander. Vous pouvez utiliser les paramètres bs=XXX(taille de bloc) et count=XXX(nombre de blocs) à cette fin. Par exemple, vous pouvez spécifier bs=10Mune taille de bloc de 10 Mo (ce qui rendrait certainement la copie beaucoup plus rapide par rapport à la taille de bloc de 4 Ko que vous utilisez dans vos commandes) et count=200copier 10 Mo * 200 = 2000 Mo (2 Go). Vous devrez peut-être ajuster la taille et le nombre de blocs en fonction du schéma de partition de votre carte SD .

dd - copy and convertn'est pas le bon outil pour faire le travail que vous avez demandé. Il s'agit d'un outil de copie (et de conversion) de bas niveau, secteur par secteur, idéal pour copier des secteurs de démarrage, formater des périphériques et toutes sortes de tâches de bas niveau. Lorsque vous utilisez, ddvous copiez secteur par secteur sur l'image, même si elle n'est pas incluse dans la structure du système de fichiers.

Les images fournies par la fondation Raspberry Pi sont des images spécialement compilées avec des scripts d'installation, la décompression des binaires et la configuration initiale, après quoi vous devez obtenir des mises à jour sur Internet de toute façon - ce qui est délibéré mais tout de même une tâche pour le faire fonctionner comme ceci.

Une solution populaire pour éviter de copier des secteurs vides consiste à utiliser un système de copie de niveau fichier - et CloneZilla est autonome, amorçable à partir d'un CD, similaire ye olde Norton Ghostmais clonezilla prend en charge les systèmes de fichiers Linux (et plus). Ainsi, il ne copiera que les fichiers en cours d'utilisation et créera un conteneur à partir de ces fichiers uniquement. Réduit considérablement la taille!

• Voici un guide qui démontre à partir d'un CD amorçable pour sauvegarder le Pi à partir de la SD

J'avais cette même question exacte et je voulais un outil facile à utiliser. Après avoir recherché et non trouvé un, j'ai écrit mkimg.sh . Je décris le processus que j'ai utilisé sur: /raspberrypi//a/37899/32585