CyberSDF

Reprenez la main sur votre numérique

Rédigé par Rédaction CyberSDF /

Créer une clé USB bootable avec dd et status=progress

un poste de travail sobre vu de trois quarts, ecran eteint, clavier mecanique, carnet ouvert

La commande dd if=debian.iso of=/dev/sdb bs=4M status=progress conv=fsync recopie une image ISO sur une clé USB et réaffiche l’avancement sur la sortie d’erreur, au plus une fois par seconde. Elle demande coreutils 8.24 ou plus récent, la version qui a introduit l’opérande status=progress le 3 juillet 2015. bs=4M fixe la taille des blocs lus et écrits ; sans cet opérande, dd travaille par blocs de 512 octets, la valeur par défaut du manuel GNU. Aucune confirmation n’est demandée : le contenu précédent de la clé disparaît.

Sommaire
  1. La clé est la nouvelle ligne de lsblk, jamais le disque qui porte la racine
  2. La ligne dd complète, du démontage à la dernière statistique
  3. status=progress n’existe qu’à partir de coreutils 8.24, sorti le 3 juillet 2015
  4. Un /dev/sdb1 à la place de /dev/sdb, et la clé ne démarre plus en BIOS
  5. cp et cat écrivent aussi l’image, sans ligne d’avancement
  6. Paquet, outil, périphérique, image et récupération décident du résultat
  7. Sources

Deux vérifications décident du résultat. Le nom du périphérique dépend du port USB occupé, et un nom mal relevé envoie l’image sur un disque interne. La version de coreutils tranche ensuite entre un affichage régulier et un arrêt immédiat. Les pages Debian et Ubuntu de la rubrique Linux couvrent le reste du travail en terminal.

La clé est la nouvelle ligne de lsblk, jamais le disque qui porte la racine

La clé USB se repère avec la commande lsblk, que le manuel d’installation Debian demande de lancer avant puis après le branchement du support. Le périphérique apparu entre les deux affichages est la clé, nommé à la suite des disques déjà présents : /dev/sdb sur une machine qui n’a qu’un seul disque interne en /dev/sda. Sur une tour équipée de deux disques, la même clé prend le nom /dev/sdc. Écrire sur le mauvais nom détruit le contenu du disque visé, sans confirmation.

Le wiki Arch contourne cette instabilité avec les chemins /dev/disk/by-id/, construits à partir du fabricant et du numéro de série du support ; le nom reste identique quel que soit le port. Ses auteurs rappellent aussi que l’écriture efface irrémédiablement la clé. Un support qui contient encore des fichiers utiles se copie avant, par exemple avec une sauvegarde rsync des fichiers de la clé.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

Ce qu’on doit voir : une entrée supplémentaire de type disk, suivie de ses partitions de type part. Un chemin dans la dernière colonne signale une clé encore montée, à libérer avant d’écrire.

La ligne dd complète, du démontage à la dernière statistique

L’écriture se fait en une commande, du fichier ISO vers le périphérique de bloc, sans montage intermédiaire ; les opérandes if= et of= se lisent comme dans les commandes de base sous Linux. Le manuel d’installation Debian précise que les images de cette distribution sont fabriquées avec la technologie isohybrid, donc écrivables directement sur une clé.

L’opérande status=progress, documenté par le manuel GNU, affiche le débit et le volume transférés sur la sortie d’erreur, au plus une ligne par seconde ; ses mises à jour peuvent être retardées pendant une attente d’entrée-sortie. conv=fsync synchronise les données et les métadonnées juste avant la fin de la copie, même si des erreurs d’écriture sont survenues. Sans cet appel, le manuel GNU rappelle que le noyau peut garder les données en mémoire un moment : une clé retirée aussitôt risque d’être incomplète, et le wiki Arch conseille d’ajouter un sync après la commande pour la même raison.

  1. Libérer la clé si une partition est montée. Ce qu’on doit voir : aucun texte, la commande rendant la main quand la partition était bien montée. Une colonne MOUNTPOINT vide rend cette étape inutile. 
    sudo umount /dev/sdb1
  2. Lancer l’écriture. Ce qu’on doit voir : une ligne unique qui se réécrit chaque seconde, avec le volume copié, la durée écoulée et le débit. 
    sudo dd if=debian.iso of=/dev/sdb bs=4M status=progress conv=fsync
  3. Lire les trois lignes finales. Le manuel GNU illustre leur format sur cet exemple, où la notation 7287+1 sépare les blocs complets des blocs partiels, plus courts que la taille demandée. 
    7287+1 records in
116608+0 records out
59703296 bytes (60 MB, 57 MiB) copied, 0.0427974 s, 1.4 GB/s

    Ce qu’on doit voir : le comptage des blocs, puis le volume, la durée et le débit moyen.

  4. Vider les tampons avant de débrancher. Ce qu’on doit voir : aucune sortie, la commande rendant la main une fois les écritures en attente terminées. 
    sync

status=progress n’existe qu’à partir de coreutils 8.24, sorti le 3 juillet 2015

Une distribution antérieure à la version 8.24 de coreutils refuse l’opérande status=progress et interrompt la copie avant le premier bloc écrit. L’annonce de la version 8.24, datée du 3 juillet 2015, liste cette nouveauté : dd affiche alors ses statistiques de transfert sur la sortie d’erreur, environ une fois par seconde. Debian 8 jessie embarque coreutils 8.23-4 et ne connaît donc pas l’opérande, alors que Debian 13 trixie est passée à 9.7-3.

La version installée se lit en une ligne, et le message ci-dessous est celui d’un dd trop ancien pour comprendre l’opérande. Aucune donnée n’a été écrite sur la clé au moment où il apparaît. Debian 12 bookworm embarque coreutils 9.1-1, donc au-dessus du seuil, mais un système figé sur une version antérieure garde le comportement ancien tant que le paquet n’est pas relevé.

dd: unrecognized operand ‘status=progress’

La ligne suivante renvoie vers l’aide de la commande. Le remède consiste à retirer l’opérande fautif, puis à demander les statistiques à la main. Le manuel GNU documente la technique : sur les systèmes sans signal INFO, dd répond au signal USR1 et imprime ses compteurs avant de reprendre la copie, sauf si la variable POSIXLY_CORRECT est définie.

sudo dd if=debian.iso of=/dev/sdb bs=4M conv=fsync &
sudo kill -s USR1 $!

dd --version

Ce qu’on doit voir : une première ligne qui commence par dd (coreutils), suivie du numéro de version.

Un /dev/sdb1 à la place de /dev/sdb, et la clé ne démarre plus en BIOS

Écrire l’image dans /dev/sdb1 au lieu de /dev/sdb place les données au début de la première partition, et non au début du disque, là où le firmware lit le code d’amorçage. Le manuel d’installation Debian demande donc explicitement le périphérique disque entier, et le wiki Arch reprend la consigne sous forme de note, avec l’exemple du suffixe à ne pas ajouter.

Une clé préparée de cette façon peut encore démarrer en mode UEFI, qui cherche un fichier sur une partition FAT, et rester muette en mode BIOS. Le symptôme n’accuse pas dd : la clé est simplement absente du menu de démarrage, alors qu’un second blocage laisse un message bien visible.

dd: failed to open ‘/dev/sdb’: Device or resource busy

Ce message apparaît quand une partition de la clé est encore montée : dd n’ouvre pas le périphérique et s’arrête avant toute écriture. Le démontage de la partition concernée suffit à repartir, et lsblk indique laquelle en affichant son point de montage.

Reste une limite matérielle signalée par le wiki Arch : une image ISO 9660 s’appuie sur des secteurs de 2048 octets, et un disque dont le secteur logique est plus grand, un modèle 4Kn vendu sous le nom d’Advanced Format, ne peut pas la recevoir de cette manière. Le même wiki prévient que la clé garde ensuite une signature ISO 9660, à effacer avant tout repartitionnement.

sudo wipefs --all /dev/sdb

cp et cat écrivent aussi l’image, sans ligne d’avancement

Le manuel d’installation Debian recommande sa propre méthode pour ses images isohybrides : recopier le fichier avec cp, puis lancer sync, sans passer par dd.

Le wiki Arch va plus loin et note que dd est peut-être le moins adapté des outils de copie, cat se révélant plus rapide grâce à l’appel système splice. Les deux documentations décrivent la même opération, et la différence se joue sur l’affichage.

Quatre outils acceptent d’écrire une image ISO vers un périphérique de bloc. La colonne des versions compte : un outil absent de la machine demande une installation avant l’écriture, alors que coreutils est présent partout.

Outil Avancement affiché Version ou paquet requis Ce que la documentation en dit
dd oui, une ligne par seconde coreutils 8.24 ou plus le wiki Arch publie la ligne avec bs=4M, conv=fsync et oflag=direct
cp non coreutils recommandé par le manuel d’installation Debian, suivi de sync
cat non coreutils plus rapide que dd selon le wiki Arch, à cause de splice
pv oui, sous forme de barre paquet pv cité par le wiki Arch parmi les méthodes en ligne de commande

Une réserve termine le tableau : le manuel GNU prévient que la ligne d’avancement peut rester figée pendant une attente d’entrée-sortie, et le wiki Arch rappelle que cp comme cat écrivent la clé sans le moindre retour visuel. Un terminal silencieux ne se distingue alors pas d’un terminal bloqué.

Paquet, outil, périphérique, image et récupération décident du résultat

Cinq points tranchent le résultat d’une écriture de clé USB : la version de coreutils, le choix de l’outil, le nom du périphérique, la taille de l’image et la remise en état du support. Chacun se règle avant de lancer la commande, sauf le dernier.

Faut-il installer un paquet pour voir l’avancement de dd ?

Non. L’opérande status=progress appartient à coreutils depuis la version 8.24, publiée le 3 juillet 2015, et ce paquet est présent sur toute installation Debian. La commande dd –version affiche la version en une ligne. Sur une machine restée en Debian 8 jessie, coreutils 8.23-4 ne connaît pas l’opérande, à retirer au profit du signal USR1.

Pourquoi utiliser dd alors que la documentation Debian recommande cp ?

Pour une image isohybride Debian, cp suivi de sync écrit la clé correctement, et le manuel d’installation ne mentionne même pas dd. L’avantage de dd tient à l’affichage : sans lui, la copie reste silencieuse jusqu’à la fin. Le wiki Arch ajoute que cat termine plus vite que dd.

Comment éviter d’écrire sur le disque système ?

Le nom /dev/sdX dépend du port occupé, donc une clé branchée ailleurs peut prendre le nom d’un disque interne. Le wiki Arch conseille les chemins /dev/disk/by-id/, qui contiennent le fabricant et le numéro de série du support et ne changent pas d’un branchement à l’autre. Le même wiki mentionne le script xorriso-dd-target, fourni par libisoburn, dont le mode -plug_test réduit ce risque.

La clé ne démarre qu’en UEFI, ou pas du tout, quelle est la cause ?

Une écriture faite dans /dev/sdb1 plutôt que /dev/sdb produit ce symptôme, car le code d’amorçage BIOS doit se trouver au début du disque. Le wiki Arch cite une seconde cause matérielle : un disque dont le secteur logique dépasse les 2048 octets du secteur ISO 9660 ne peut pas recevoir l’image. Le même wiki propose de refaire l’écriture une fois si la clé reste muette, puis de mettre à jour le firmware de la carte mère.

Comment remettre la clé en service après l’écriture ?

La clé conserve la signature ISO 9660 de l’image et n’offre plus qu’une petite partition. Le wiki Arch donne la commande wipefs –all sur le périphérique, à lancer avant tout repartitionnement. Sans cette suppression de signature, les outils de partitionnement retrouvent l’empreinte de l’image et la clé reste inutilisable pour du stockage.

Sources