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

**URL:** <https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693>\
**Category:** Support Debian\
**Created:** [Juin 18, 2022, 3:09 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693 "2022-06-18T15:09:20Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Thibaut1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@Thibaut1](https://www.debian-fr.org/u/Thibaut1)\
**Post date:** [Juin 18, 2022, 3:09 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/1 "2022-06-18T15:09:20Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Juin 18, 2022, 5:55 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/2 "2022-06-18T17:55:39Z")

</div>

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 :

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

```

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

```nohighlight
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 :

```nohighlight
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 :

```nohighlight
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 :

```nohighlight
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:~# 

```

---

<div class="post-metadata">

**Author:** ![Thibaut1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@Thibaut1](https://www.debian-fr.org/u/Thibaut1)\
**Post date:** [Juin 18, 2022, 6:36 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/3 "2022-06-18T18:36:31Z")

</div>

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](https://www.debian-fr.org/uploads/default/original/2X/c/cd62453d97039d38227b0eb8f87b90ce228897ab.png)

Alors, iso corrompu ou pas?

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Juin 18, 2022, 9:08 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/4 "2022-06-18T21:08:56Z")

</div>

> [@Thibaut1](#):
>
> J’ai reformaté la clé …

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.

> [@Thibaut1](#):
>
> … j’ai lancé ta commande
> 
> ```plaintext
> 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
> 
> ```

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

> [@Thibaut1](#):
>
> … J’ai vérifié avec le logiciel GtkHash. Lui, il me dit que le sha256 est identique. …

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 :

```plaintext
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 :

```plaintext
lsb_release -a

```

Un **retour complet** , c’est par exemple :

```plaintext
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**.

---

<div class="post-metadata">

**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\
**Post date:** [Juin 19, 2022, 5:31 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/5 "2022-06-19T05:31:23Z")

</div>

> [@anon29980398](#):
>
> 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.

Ah bon ?

> [@anon29980398](#):
>
> C’est pour ça que je préfère toujours lancer une commande **sync** juste après que la commande ait fini son travail

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.

---

<div class="post-metadata">

**Author:** ![Thibaut1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@Thibaut1](https://www.debian-fr.org/u/Thibaut1)\
**Post date:** [Juin 19, 2022, 6:44 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/6 "2022-06-19T06:44:30Z")

</div>

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:~$
```

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Juin 19, 2022, 7:24 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/7 "2022-06-19T07:24:50Z")

</div>

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.12)](https://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html#sync-invocation)  
dont voici un extrait :

> [@](#):
>
> … `sync` writes any data buffered in memory out to the storage device. This can include (but is not limited to) modified superblocks, modified inodes, and delayed reads and writes. This must be implemented by the kernel; The `sync` program does nothing but exercise the `sync` , `syncfs` , `fsync` , and `fdatasync` system calls.
> 
> The kernel keeps data in memory to avoid doing (relatively slow) device reads and writes …

---

<div class="post-metadata">

**Author:** ![Thibaut1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@Thibaut1](https://www.debian-fr.org/u/Thibaut1)\
**Post date:** [Juin 19, 2022, 9:03 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/8 "2022-06-19T09:03:21Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Juin 19, 2022, 9:31 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/9 "2022-06-19T09:31:00Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Thibaut1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@Thibaut1](https://www.debian-fr.org/u/Thibaut1)\
**Post date:** [Juin 19, 2022, 10:03 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/10 "2022-06-19T10:03:25Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Thibaut1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@Thibaut1](https://www.debian-fr.org/u/Thibaut1)\
**Post date:** [Juin 19, 2022, 5:52 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/11 "2022-06-19T17:52:13Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![LibreFaso](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/4da419/32.png) [@LibreFaso](https://www.debian-fr.org/u/LibreFaso)\
**Post date:** [Septembre 2, 2023, 7:03 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/12 "2023-09-02T19:03:08Z")

</div>

> [@anon29980398](#):
>
> lance la ligne de commandes suivante :
> 
> ```auto
> sudo dd if=/dev/sdc count=50127 bs=64k | sha256sum
> 
> ```

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 «&nbsp;kernel must be loaded first&nbsp;» 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)

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Septembre 2, 2023, 8:34 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/13 "2023-09-02T20:34:11Z")

</div>

> [@LibreFaso](#):
>
> je ne comprends pas ni à quoi sert le count 50127

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.

---

<div class="post-metadata">

**Author:** ![LibreFaso](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/4da419/32.png) [@LibreFaso](https://www.debian-fr.org/u/LibreFaso)\
**Post date:** [Septembre 6, 2023, 2:14 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/15 "2023-09-06T14:14:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Septembre 6, 2023, 2:22 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/16 "2023-09-06T14:22:58Z")

</div>

> [@LibreFaso](#):
>
> Donc un cmp Primtux.iso /dev/sdb ?

Oui.

> [@LibreFaso](#):
>
> cmp voit une différence à l’octet 4194305.

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 ?

> [@LibreFaso](#):
>
> On notera que la clé porte deux partitions sdb1 (nommée Primtux) et sdb2.  
> J’ignore d’où cela vient.

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

---

<div class="post-metadata">

**Author:** ![LibreFaso](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/4da419/32.png) [@LibreFaso](https://www.debian-fr.org/u/LibreFaso)\
**Post date:** [Septembre 6, 2023, 2:33 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/17 "2023-09-06T14:33:53Z")

</div>

> [@PascalHambourg](#):
>
> Comment l’image a-t-elle été écrite sur la clé USB ?

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.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Septembre 6, 2023, 2:39 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/18 "2023-09-06T14:39:47Z")

</div>

> [@LibreFaso](#):
>
> dd avec un bs de 1024.

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

> [@LibreFaso](#):
>
> le cmp a atteint EOF sans erreur.

Et l’installateur démarre ?

---

<div class="post-metadata">

**Author:** ![LibreFaso](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/4da419/32.png) [@LibreFaso](https://www.debian-fr.org/u/LibreFaso)\
**Post date:** [Septembre 6, 2023, 2:40 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/19 "2023-09-06T14:40:54Z")

</div>

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 ?

---

<div class="post-metadata">

**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\
**Post date:** [Septembre 6, 2023, 2:45 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/20 "2023-09-06T14:45:37Z")

</div>

> [@PascalHambourg](#):
>
> > [@LibreFaso](#):
> >
> > dd avec un bs de 1024.
> 
> C’est un peu petit, la copie serait probablement plus rapide avec une talle de bloc de 4096 ou plus.

Moi, j’utilise directement 16M.

> [@gregoryroche0](#):
>
> Salut,  
> tu as quoi dans la ligne 1 et octet 2 ?

C’était de l’humour ?

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Septembre 6, 2023, 2:47 UTC](https://www.debian-fr.org/t/probleme-lors-de-lecriture-de-liso-debian-sur-cle-usb/86693/21 "2023-09-06T14:47:25Z")

</div>

> [@LibreFaso](#):
>
> Il n’est pas sensé le signaler quand il a un problème ?

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 «&nbsp;bit rot&nbsp;» (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).

> [@Almtesh](#):
>
> C’était de l’humour ?

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