Problème lors de l'écriture de l'iso Debian sur clé usb

Support Debian
#1

Bonjour,

J’ai téléchargé le nouveau Debian et je l’ai écrit sur une clé usb.
J’ai vérifié si tout a été correctement copié et il me dit qu’ils sont différents. J’ai réessayé l’installation plusieurs fois et j’ai toujours le même résultat.

sudo cmp -n `stat -c '%s' debian-live-11.3.0-amd64-xfce+nonfree.iso` debian-live-11.3.0-amd64-xfce+nonfree.iso /dev/sdc
debian-live-11.3.0-amd64-xfce+nonfree.iso /dev/sdc sont différents: octet 31751899, ligne 113444

Pour info, j’ai écrit l’iso sur la clé en suivant cette commande:
dd if=debian-live-11.3.0-amd64-xfce+nonfree.iso of=/dev/sdc

Que dois-je faire?
Merci

#2

Bonjour

Avec la clef USB connectée,
et si elle a été associée au fichier de périphérique /dev/sdc
lance la ligne de commandes suivante :

sudo dd if=/dev/sdc count=50127 bs=64k | sha256sum

ce qui devrait te retourner une somme sha256 dont la valeur est :

a70c21895f7fb854d2c3c5868907a2602b7e2f3282d0a97a699cf714d6a5d09e

j’ai spécifié à la commande dd une taille de blocs de 64Kio pour que la lecture aille un peu plus vite qu’en lisant par blocs de 512 octets (512 octets est la valeur par défaut pour la taille de blocs de la commande dd)

Si la valeur de la somme sha256 retournée est différente,
c’est que la copie sur la clef USB s’est mal passée,
ou/et que le fichier source de la copie a été corrompu lors de son téléchargement :

le fichier debian-live-11.3.0-amd64-xfce+nonfree.iso
devrait avoir une taille de : 3285123072 octets
et avoir la même somme sha256 que celle citée plus haut
ce que tu peux vérifier en lançant
la ligne de commande suivante :

sha256sum debian-live-11.3.0-amd64-xfce+nonfree.iso

NOTE :
Quand on lance une copie avec la commande dd vers un périphérique un peu lent (clef USB),
il arrive parfois que la commande dd retourne le prompt avant que tous les tampons de copie aient été effectivement transférés sur la clef USB.
Du coup, l’utilisateur voyant revenir le prompt croit que la copie est terminée alors qu’elle ne l’est pas.

C’est pour ça que je préfère toujours lancer une commande sync juste après que la commande ait fini son travail :

sudo dd if=debian-live-11.3.0-amd64-xfce+nonfree.iso of=/dev/sdc bs=64k && sync

avec ça, quand la commande sync a finit son travail et que le prompt s’affiche à nouveau,
on peut être sûr que tout a bien été transféré sur la clef USB.

Sur mon système, la ligne de commande cmp que tu as utilisée me confirme que la comparaison entre le fichier image ISO original et sa copie sur la clef USB sont identiques :

root@debbull:~# cmp -n `stat -c '%s' /home/michel/machVirt/isosInstall/debian-live-11.3.0-amd64-xfce+nonfree.iso` /home/michel/machVirt/isosInstall/debian-live-11.3.0-amd64-xfce+nonfree.iso /dev/sdc
root@debbull:~# echo $?
0
root@debbull:~#
1 J'aime
#3

J’ai reformaté la clé et j’ai lancé ta commande

sudo dd if=debian-live-11.3.0-amd64-xfce+nonfree.iso of=/dev/sdc bs=64k count=50127 && sync 
484+1 enregistrements lus
484+1 enregistrements écrits
31751898 bytes (32 MB, 30 MiB) copied, 4,33397 s, 7,3 MB/s

Ensuite j’ai donc revérifié la clé:

sudo dd if=/dev/sdc count=50127 bs=64k | sha256sum
50127+0 enregistrements lus
50127+0 enregistrements écrits
3285123072 bytes (3,3 GB, 3,1 GiB) copied, 212,283 s, 15,5 MB/s
3fc34a5a27fcb74478377880bfbdfd7354a4788e5dfb49706bf4caf5ff79e9e0

La somme sha256 n’est pas la même, donc la copie s’est mal passée.

Pour ce qui est du fichier original debian-live-11.3.0-amd64-xfce+nonfree.iso, la taille est de 3.285.123.072 octets. Donc, là c’est correct.
Par contre pour le sha, il y a un problème:

sha256sum debian-live-11.3.0-amd64-xfce+nonfree.iso
c7b66fd119be8ed793b46395c027374cbc35b57e65f32fcaab14577f11c68f75  debian-live-11.3.0-amd64-xfce+nonfree.iso

J’ai vérifié avec le logiciel GtkHash. Lui, il me dit que le sha256 est identique.
Capture d’écran_2022-06-18_20-33-24

Alors, iso corrompu ou pas?

#4

Le formatage est inutile puisque le fichier est copié dans la clef et PAS dans le système de fichiers d’une partition de la clef.

La copie semble s’être arrêtée après n’avoir seulement copié que 30 MiB sur 3132 MiB
donc ce n’est pas la peine d’aller plus loin : il n’y a eu qu’un dixième du fichier qui a été copié.

Je n’ai aucune idée de ce qui pourrait être la cause de ces problèmes, car il y a plus qu’un seul problème d’écriture sur une clef USB :

  • la commande dd n’a pas pu lire plus de 32MB
    du fichier debian-live-11.3.0-amd64-xfce+nonfree.iso,

  • la commande sha256sum n’a pas non plus pu fonctionner.

Avec la clef USB connectée,
lance la ligne de commandes suivante :

sudo dd if=/dev/zero of=/dev/sdc bs=64k count=50127 && sync

et, suite à l’exécution de cette commande,
s’il y a bien eu 3285123072 bytes écrits sur la clef,

alors c’est que ce n’est PAS un problème d’écriture sur la clef USB,

mais que c’est plutôt un problème de lecture du fichier :
debian-live-11.3.0-amd64-xfce+nonfree.iso

Ce qui expliquerait pourquoi la commande dd et la commande sha256sum
n’ont pas pu donner le résultat attendu.

Je ne sais pas du tout quel système d’exploitation tu utilises.
Donne le retour complet de la ligne de commande suivante :

lsb_release -a

Un retour complet, c’est par exemple :

michel@debbull:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye
michel@debbull:~$

donc, un retour complet, ça comprend :

  • le prompt de départ avec la ligne de commande entrée,
  • suivit de tout ce que l’exécution de la ligne de commande(s) a retourné
    (même s’il n’y a absolument rien),
  • jusqu’au prompt de retour inclus.
#5

Ah bon ?

C’est inquiétant, parce que la commande sync ne sert pas à ce cas d’utilisation.
Cette commande sert à synchroniser les système de fichiers avec le stockage persistent, à savoir, effectuer les écritures de fichiers non faites immédiatement sur un système de fichier monté en asynchrone.
Le problème, c’est que /dev/sdc est généralement un périphérique bloc, il n’est donc pas concerné par cette écriture asynchrone.

#6

Bonjour,

Voici le retour des commandes:

sudo dd if=/dev/zero of=/dev/sdc bs=64k count=50127 && sync
50127+0 enregistrements lus
50127+0 enregistrements écrits
3285123072 bytes (3,3 GB, 3,1 GiB) copied, 134,498 s, 24,4 MB/s

Je suis sous Xubuntu.

thibaut@LAPTOP:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.6 LTS
Release:	18.04
Codename:	bionic
thibaut@LAPTOP:~$
#7

L’écriture sur la clef USB s’est passée sans aucun problème, donc le problème ne vient pas de l’écriture mais plutôt de la lecture du fichier image ISO.

@Almetch

Quand j’aurais le temps, (il faudrait que je remonte la machine, mais j’ai vraiment pas le courage avec ce temps) je te montrerai une vidéo de la fenêtre de terminal dans laquelle je lance une copie d’un fichier que quelques Go vers une clef USB : le prompt revient dans la fenêtre de terminal alors que la copie n’est pas terminée, et pendant ce temps, le voyant d’activité de la clef USB continue de clignoter pendant plus de 30 secondes.

Si je lance la commande sync juste après la copie, le prompt ne revient pas tant que la copie n’est pas réellement terminée.

C’est pour ça aussi que tu vois le début des copies de gros fichiers se faire très très rapidement, puis ralentir très fortement au bout d’un certain temps : quand les tampons ont tous été remplis par la lecture, mais n’ont pas encore été effectivement vidés => écrits sur le support.

Je pense que c’était lié au fait que la machine que j’utilisais à l’époque (Asus G53SW) avait 32 GB de RAM et que le noyau profitait de tout cet espace RAM disponible pour y créer des tampons DMA plus gros ou/et plus nombreux pour les transferts vers et depuis les disques (entre autres).

Mais c’est un fait : le prompt revient alors que la copie n’est pas terminée, alors qu’après avoir lancé la commande sync, la copie est effectivement terminée quand le prompt revient.

Voir aussi : sync invocation (GNU Coreutils 9.1)
dont voici un extrait :

#8

Que dois-je faire alors?
Dois-je retélécharger l’iso?

#9

Je n’ai aucune idée de la cause de ce problème, ça ne m’est jamais arrivé, et je ne vois pas du tout ce qui pourrait en être la cause, c’est la première fois que je vois ça, et je ne connais que très peu toutes les particularités d’ubuntu.

Quoi qu’il en soit, ce n’est pas un problème causé par le fichier image lui même, puisque ton application GtkHash a bien confirmé que la somme sha256 de ce fichier est correcte.

Peut-être que quelqu’un connaissant assez bien ubuntu pourra proposer une solution, ou du moins des pistes à explorer.

Tu devrais peut-être ouvrir un fil de discussion sur un forum ubuntu, en leur donnant un lien vers ce fil de discussion.

#10

OK mais j’ai quand même essayé avec le logiciel UNetbootin. La copie s’est faite jusqu’au bout. Et j’ai même pu booter dessus sans problème. Mais lorsque je vérifie si tout est correctement copié, il me dit encore qu’ils sont différents pourtant j’arrive à booter dessus!

sudo cmp -n `stat -c '%s' debian-live-11.3.0-amd64-xfce+nonfree.iso` debian-live-11.3.0-amd64-xfce+nonfree.iso /dev/sdc
debian-live-11.3.0-amd64-xfce+nonfree.iso /dev/sdc sont différents: octet 2, ligne 1

sudo dd if=/dev/sdc count=50127 bs=64k | sha256sum
50127+0 enregistrements lus
50127+0 enregistrements écrits
3285123072 bytes (3,3 GB, 3,1 GiB) copied, 181,999 s, 18,1 MB/s
9d0d2afef9fd02ea3a93150c801ea6eca1fb96da830a71737440e3c4f2b27978  -

Je suppose que je ne peux pas installer Debian même si j’arrive à booter dessus?

#11

J’ai abandonné l’usb et j’ai essayé de graver l’iso sur un dvd avec Xfburn. Cela a fonctionné mais lorsque je vérifie l’iso, il est différent de l’iso original.

md5sum /dev/cdrom
2eab1357cb2c74cc3e9bd27590e7e848  /dev/cdrom

md5sum debian-live-11.3.0-amd64-xfce+nonfree.iso
0242cd2bc2b5f3ce6982e1dc5c24e7a0  debian-live-11.3.0-amd64-xfce+nonfree.iso

Voilà, ça ne fonctionne ni sur usb ni sur dvd.

Je vais essayer de graver l’iso à partir d’un autre système d’exploitation. Et ensuite, si ça ne fonctionne toujours pas, je vais suivre votre conseil et aller sur un forum Ubuntu.

#12

Bonjour.
J’ai une clé USB de 4 Go rendue bootable par le dd d’une l’ISO Primtux de 3,5 Go.
Lorsque je mets cette ISO sur une clé Ventoy, elle boote sans problème.
Mais la clé de 4 Go me dit « kernel must be loaded first » lorsque j’essaie de booter dessus.

J’ai voulu commencer par vérifier que la copie avait été complète avec votre méthode mais je ne comprends pas ni à quoi sert le count 50127 (ni si je dois changer la valeur ou la garder) ni avec quoi comparer le résultat (j’imagine que le hash que vous donnez n’a aucune raison de correspondre au hash que devrait donner ma clé).

En tous cas dd if=/dev/sdb count=50127 bs=64k | sha256sum me retourne

5f3da70edde571cad6f5d5a9eabb3ba0ab3f5c2ecfc7f243887e4d4ee9e77f18  -
50127+0 enregistrements lus
50127+0 enregistrements écrits
3285123072 octets (3,3 GB, 3,1 GiB) copiés, 170,516 s, 19,3 MB/s

tandis que sha256sum PrimTux7-amd64-2022-10.iso me retourne 53063296a02c45ec293a2d59f843c48c5d45ad44e128d77d52fb496cef87845a

Est-ce que c’est le signe que la copie a échouée ou est-ce juste que le test que j’ai fait n’a aucun sens ?

On notera que ls -l me donne 3523215360 octets pour l’ISO (et 3,3 G avec ls -lh)

#13

Cela sert à limiter le calcul de la somme de contrôle sur la clé USB à la taille de l’image ISO, sinon la somme sera calculée sur toute la clé et ne correspondra pas à l’image. Evidemment il est différent pour chaque image ISO. Ce nombre est obtenu en divisant la taille de l’image en octets par la taille de bloc spécifiée par bs (64k = 65536). Le quotient doit être entier, sinon diviser la taille de bloc par 2 jusqu’à ce que.le quotient soit entier. En principe une image ISO contient un nombre entier de blocs de 2048 octets, donc la taille de bloc minimale devrait être 2048 (2k).
Avec la taille de ton image : count=53760 bs=64k

Mais le plus simple est de comparer le contenu de la clé et de l’image avec la commande cmp. Si la comparaison atteint la fin du fichier ISO (erreur EOF) sans avoir trouvé de différence, alors la clé est bonne.

1 J'aime
#15

Donc un cmp Primtux.iso /dev/sdb ?
Si c’est ça cmp voit une différence à l’octet 4194305.
Je retente un dd donc.

On notera que la clé porte deux partitions sdb1 (nommée Primtux) et sdb2.
J’ignore d’où cela vient.

#16

Oui.

Soit exactement 4 Mio + 1. C’est trop remarquable pour être une coïncidence. Comment l’image a-t-elle été écrite sur la clé USB ?

Dun contenu de l’image ISO, si tu l’as copié correctement sur la clé.

#17

dd avec un bs de 1024.
J’aurais pas dû ?
Je viens de le refaire et le cmp ne me signale pas d’erreur pour l’instant (lancé depuis plusieurs minutes).
Edit : le cmp a atteint EOF sans erreur.

#18

C’est un peu petit, la copie serait probablement plus rapide avec une talle de bloc de 4096 ou plus.

Et l’installateur démarre ?

#19

Oui, merci donc pour ton aide.
Le problème semble bien avoir été un dd défectueux.
Il n’est pas sensé le signaler quand il a un problème ?

#20

Moi, j’utilise directement 16M.

C’était de l’humour ?

#21

dd ne vérifie pas ce qu’il a écrit, donc si le système ne lui signale pas d’erreur d’écriture, ça lui suffit.
La clé est peut-être défectueuse et soumise au « bit rot » (dégradation des données écrites au cours du temps).
Note : tout système de fichiers présent sur la clé doit impérativement être démonté avant de commencer la copie, sinon il y a un risque d’écriture intempestive qui pourrait corrompre la copie (sans compter le risque de plantage du système).

Je dirais plutôt une lecture trop rapide des messages précédents sans regarder l’auteur ni la data.

1 J'aime