Clonage clé usb avec dd

Support Debian
#1

Bonjour,
j’ai un stock de clés usb identiques (même marque, même capacité, achetées en même temps). J’ai fabriqué une liveusb et je les clone toutes avec dd. J’en ai deux ou trois qui me font une erreur:

dd: erreur d'écriture de «/dev/sdc»: Aucun espace disponible sur le périphérique 479745+0 enregistrements lus 479744+0 enregistrements écrits 7860125696 octets (7,9 GB) copiés, 828,012 s, 9,5 MB/s

Pourquoi donc? Elles ne sont pas parfaitement identiques? Il manque quelques blocs?
Y a t-il une solution? une option à passer à dd?

Ou alors il faut que je crée la clé originale avec une de celle-là que je clone ensuite… Mais c’est pas cool car j’en ai déjà fait 15 comme ça et je n’ai pas envie de recommencer… :slightly_smiling:

Merci

#2

Salut,

Je saute d’un fil, expliques nous cette histoire de 15 clefs, identiques …

[quote=“totola”]je les clone toutes avec dd.

une option à passer à dd?

[/quote]

Quelle est la commande lancée ?
Avec quelles options ?

#3

Ben j’ai en fait 18 clés Lexar 8G.
Je les veux toutes avec debian wheezy en liveusb persistant. Du coup je les clones avec dd id=/dev/sdb of=/dev/sdc bs=16384
Ça marche pour 15 d’entre elle, mais j’en ai trois récalcitrante qui font l’erreur ci dessus…
J’ai essayé avec d’autres valeurs de bs mais sans succès…

#4

Tu as vérifié et comparé leur capacité ?

#5

Bonjour,
mon grain de sel,
a la fin de la commande je rajoute ;sync
il se peut que le dernier bloc de 16384 octets ne soit pas encore écrit
et que le démontage à eu lieu
c’est bien le cas ici avec les valeur lu/ecrit
A+
JB1

#6

Tu as vérifié et comparé leur capacité ?[/quote]

En effet, c’est pas une mauvaise idée! :slightly_smiling:

Voilà:

[code]Disque /dev/sde : 7860 Mo, 7860125696 octets
242 têtes, 62 secteurs/piste, 1023 cylindres, total 15351808 secteurs
…

Disque /dev/sdf : 7876 Mo, 7876902912 octets
243 têtes, 62 secteurs/piste, 1021 cylindres, total 15384576 secteurs
…[/code]

C’est bizarre, j’aurais pensé le contraire… Mon erreur arrive lorsque je clone sde sur sdf, et ici sdf est plus grand que sde, non? J’aurais imaginé le contraire…??

[EDIT]: Je me suis emmelé les pinceaux, c’est bien le contraire, toutes les clés qui fonctionnent font 7876 Mo et l’erreur arrive avec celles de 7860…!! Ce qui paraît logique…
Du coup j’ai une idée: je réduis ma dernière partition avec gparted de 20Mo sur une clé fonctionnelle que j’utilise pour cloner mes trois dernières… ça devrait marcher non? Mais c’est un peu pénible quand même :s

#7

[quote=“jb1”]Bonjour,
mon grain de sel,
a la fin de la commande je rajoute ;sync
il se peut que le dernier bloc de 16384 octets ne soit pas encore écrit
et que le démontage à eu lieu
c’est bien le cas ici avec les valeur lu/ecrit
A+
JB1[/quote]
Bonjour,
grain de sel intéressant!
J’essaie avec conv=sync à la fin —> même problème
avec conv=sync,noerror —> même problème

#8

Salut,

[mono]dd if=source of=destination[/mono]

[mono]dd[/mono], utilisé avec ces options présentement, exige que le support de [mono]destination[/mono] soit d’égal ou de capacité supérieure au support [mono]source[/mono].

#9

[quote=“BelZéButh”]Salut,

[mono]dd if=source of=destination[/mono]

[mono]dd[/mono], utilisé avec ces options présentement, exige que le support de [mono]destination[/mono] soit d’égal ou de capacité supérieure au support [mono]source[/mono].[/quote]

Oui… C’est pour ça que je viens d’en réduire une de 20Mo et l’erreur reste écrite au clonage, mais la clé fonctionne bien pourtant (l’erreur porte sur des secteurs non alloués et plus sur la partition sdx2 persistence). Du coup ça marche comme ça, et s’il n’y a pas d’autres solutions, il faut faire gaffe à la taille des clés avant de se lancer dans un clonage en série… ça peut servir de leçons pour d’autres! :slightly_smiling:
Ou alors, au moment du partitionnement pour créer la clé originale, prévoir de laisser libre une vingtaine de Mo libre au cas où…

#10

Oui, à condition que la clé source ne soit pas au format GPT dont la table de partition secondaire est située à la toute fin du disque. Accessoirement, un problème similaire (mais moins grave) se produirait en sens inverse lors de la copie vers une clé de plus grande capacité : la table de partition secondaire ne serait plus située à la fin du disque. C’est un des inconvénients du format GPT, on ne peut plus se contenter de jste faire du clonage brut sur un disque plus gros, il faut ajuster ensuite avec parted, gdisk ou fixparts. Néanmoins aucune de ces situations ne devrait empêcher le bon fonctionnement de la clé dans la plupart des cas. Sans parler de la faible probabilité qu’une clé USB par essence de faible capacité soit au format GPT.

[quote=“jb1”]a la fin de la commande je rajoute ;sync
il se peut que le dernier bloc de 16384 octets ne soit pas encore écrit
et que le démontage à eu lieu
c’est bien le cas ici avec les valeur lu/ecrit[/quote]
Certes, sync est utile pour vidanger les données pas encore écrites après la fin de l’exécution de dd, avant de débrancher la clé. Mais cela n’a rien à voir avec le message, et il faudrait être taré pour débrancher la clé avant la fin de l’exécution de dd. Le dernier bloc lu n’a pas été écrit tout simplement parce qu’il n’y a pas la place sur le périphérique de destination.

Non, dd n’exige rien du tout. Il s’arrête quand il arrive à la fin du fichier source ou destination, tout simplement. C’est notamment le cas quand le fichier source est illimité comme /dev/zero ou /dev/urandom (très utile pour effacer un disque) alors que le fichier de destination est limité.