Le 05/04/2024 à 17:59, Albert ARIBAUD (via linux-31 Mailing List) a écrit :
Le vendredi 05 avril 2024 à 10:58 +0200, Pascal Hambourg a écrit :- quand on copie un img vers un device, les MD5 de l'img et du device ne correspondront pas, parce que le device est (très certainement) plus grand que l'img, et son MD5 se fera sur toute sa longueur ;On peut limiter le calcul de la somme de contrôle à la taille du fichier image original.... mais md5sum n'a pas d'option pour limiter la longueur de fichier traitée ; il faut donc faire un dd depuis le device (en spécifiant bs et count tels que leur produit égale la longueur de l'img à vérifier) et piper le résultat vers `md5sum -`
Oui, et dd est exactement prévu pour ça. Contrairement à une croyance répandue, dd ne sert pas à copier depuis ou vers un périphérique bloc : cp suffit largement pour ça.
et donc, il faut s'être assuré de la bonne extraction de l'img (puisqu'ici il est copié depuis le device).
Non puisqu'on copie depuis une image, pas l'inverse.
- et quand on copie un device vers un img, selon la valeur donnée à bs, l'image ne sera pas *exactement* de la même taille que le device, et là encore, les MD5 ne seront pas égaux.Si, la taille du fichier résultant est la même que la taille du périphérique source quelle que soit la taille de bloc spécifiée à dd.Exact aussi -- à condition d'avoir spécifié une paire bs et count viable.
On n'a pas besoin de spécifier le nombre de blocs (count), à moins de savoir à l'avance que la taille à copier est inférieure à la taille du périphérique.
Quant à la taille de bloc (bs), je n'ai pas l'impression qu'elle influe sur l'image résultante, seulement sur la vitesse de copie pour les très petites valeurs (inférieures à 4096) ou peut-être les valeurs non multiples de la taille de bloc physique (pas testé, à vérifier).