Re: Comparer la copie sdb à .img pour voir si c'est ok...

[Pascal Hambourg <pascal AT plouf.fr.eu.org>]

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).