Discussion :

[Philippe Dpt35]

Bonjour,

Pour réaliser une image système de la carte SD d'un Raspberry Pi sur un périphérique branché en USB, j'utilise la commande suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dd if=/dev/mmcblk0 | pv  | dd of="/chemin/fichier.img" && sync

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dd if=/dev/mmcblk0 | pv  | gzip | dd of="/chemin/fichier.img" && sync

si je veux une image compressée.

Voici ce que j'ai constaté:

Avec un RPi3, avec ces paramètres par défaut, la copie se fait correctement, aussi bien avec que sans compression.
L'image disque est parfaitement lisible depuis un logiciel d'archivage sous Windows.

Avec un RPi 1B, la copie se fait correctement, mais lorsque je veux vérifier l'image avec mon logiciel sous Windows, il échoue en indiquant un .img défectueux (cela dans les 2 cas, avec ou sans compression).

J'ai tenté de modifier le paramètre bs en le passant à 4096 pour la réalisation de la copie depuis le RPi1B. Outre le fait que la copie se fait beaucoup plus rapidement (normal !), j'obtiens cette fois une image valide après vérification. Pensant avoir obtenu le beurre et l'argent du beurre (la qualité et la vitesse de la copie), je tente donc de passer le même paramètre pour la copie sur le RPi 3. Mais cette fois j'ai une image indiquée défectueuse lorsque je tente de l'ouvrir pour la vérifier !

Pour le RPi1b je copie sur un disque dur 2.5' portable datant de quelques années, pour le RPi3 sur un disque dur récupéré d'un PC portable assez ancien. Cela peut-il être l'explication du phénomène ?

Comme je réalise un script qui devra pouvoir être utilisé dans diverses configurations matérielles, quels paramètres optimaux utiliser avec la commande dd afin d'avoir une image valide dans tous les cas ?

Merci d'avance pour vos éclairages.

[Philippe Dpt35]

En utilisant cette commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dd if=/dev/mmcblk0 bs=4096 | pv | gzip -c >"$1" && sync

L'image obtenue depuis RPi3 est, cette fois, valide.

En utilisant une redirection plutôt qu'un pipe, l'image obtenue est-elle toujours bien une copie bit à bit et non une simple copie de fichiers ?
Autrement dit, en reconstruisant une carte SD depuis cette image système, aura-t-on bien un système bootable opérationnel ?

[Philippe Dpt35]

Je me réponds, tout au moins en ce qui concerne mon second message.

En relisant la man page de dd, on voit:

of=fichier
Ecrire les données dans le fichier mentionné, et
non pas sur la sortie standard.

Donc, a priori, of agit comme une simple redirection, ce qui laisse supposer que la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dd if=/dev/mmcblk0 bs=4096 | pv | gzip -c >"$1" && sync

qui fait cette redirection, est tout aussi valide et copie bien bit à bit.

[Philippe Dpt35]

En poursuivant les tests, les surprises continuent. Si je fais la même opération cette fois sans compression, c'est-à-dire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dd if=/dev/mmcblk0 bs=4096 | pv  >"$1" && sync

là l'image obtenue est reconnue comme endommagée.

[Philippe Dpt35]

Ayant fait des tests plus approfondis, j'ai constaté qu'une même commande pouvait parfois donner aussi bien une image correcte qu'une image corrompue.

La réalisation des images étant faite à chaud (sur un système en fonctionnement), j'émets l'hypothèse que l'image réalisée peut être corrompue dans le cas où le système procéderait à certaines écritures pendant la sauvegarde.
Quelqu'un peut-il confirmer ou infirmer cette hypothèse ?

Dans l'affirmative, existe-t-il des solutions permettant de "geler" le système pendant la réalisation de l'image système et de le réactiver en fin de copie ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

kill stop

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

kill cont

par exemple permettrait-il de faire cela ? Dans ce cas, comment effectuer la sélection des processus à stopper ?

[LittleWhite]

Bonjour,

La réalisation des images étant faite à chaud (sur un système en fonctionnement), j'émets l'hypothèse que l'image réalisée peut être corrompue dans le cas où le système procéderait à certaines écritures pendant la sauvegarde.
Quelqu'un peut-il confirmer ou infirmer cette hypothèse ?

Sachant que c'est la chose à laquelle j'ai pensé en lisant votre premier message, je pencherai pour cette hypothèse.

Je ne sais pas comment on pourrait bloquer toutes les écritures (et cela me semble un petit peu dangereux, dans le sens où je pense que cela freezerai le système).