J’ai déjà fait dans le sens
if plus petit que of
mais là, je teste l’inverse, et il me semble que c’est bien long, déjà 2h30 et ça tourne encore.
Mon disque if fait 650 Gb
Mon disque of fait 500 Gb
Ma commande, classique :
Bien sûr, j’ai vérifié sda et sdb.
j’ai passé la commande à partir de sda, sans ne plus rien toucher ensuite sur cette machine.
Merci
Si tu laisses la taille de bloc par défaut (512 octets), c’est effectivement très long. D’après mon expérience, il faut au minimum bs=4k pour atteindre le débit séquentiel normal des disques.
La copie va être tronquée lorsque la fin du disque de destination sera atteinte. Il vaut mieux que la partie du disque source qui dépasse ne soit pas utilisée ni référencée : pas de partition définie, même vide, pas de système de fichiers, pas de PV LVM, pas de table de partition GPT…[quote=“ricardo, post:1, topic:73902”]
j’ai passé la commande à partir de sda
[/quote]
Tu veux dire à partir d’un système installé sur le disque source ? Mauvaise idée si des partitions sont montées en lecture-écriture, car leur contenu lors de la copie risque d’être incohérent. Même si tu ne touches rien, il y a des démons qui tournent, des logs qui s’écrivent…
PS : l’option notrunc est inutile lorsque la destination est un périphérique bloc comme un disque puisque sa taille ne peut être modifiée contrairement à un fichier.
Si tu mets l’option noerror, tu veux probablement aussi l’option sync pour remplacer les données illisibles de la source par des zéros, sinon ça va décaler les données.
ll me semble que dd s’arrête dès qu’il n’en peut plus : d’un côté comme de l’autre.
Pour le temps mis, ça dépend du disque le plus lent et/ou de l’interface la plus lente.
Je crois que j’ai faux partout, donc :
Table de partition = GPT
Je ne me souviens plus si la dernière partition du disque source va au delà des 500 Gb.
Est-ce qu’il ne vaudrait pas mieux que je suspende tout, en espérant qu’il n’y ait pas de dégâts sur le disque source (j’ai les sauvegardes), et que je recommence le processus ?
Dans l’affirmative, comment pratiquer au mieux, à partir de quoi ?
merci
Suite du précédent message :
En fait, ce disque source (650 Gb) est issu de la copie avec ‘dd’ d’un disque SSD de 120 Gb. La table de partition n’a pas été modifiée ensuite, ni aucune partition ajoutée ou modifiée.
MAIS il s’agit bien d’une table GPT.
J’avais eu la bonne idée, pour une fois, de copier le ‘parted -l’ de ce disque.
Merci
Oui, il vaut mieux arrêter et réfléchir à un plan d’action.
Il n’y a pas de raison que dd ait altéré le contenu du disque source.
Pour la table de partition GPT, ce n’est pas très grave car elle peut être corrigée sur le disque de destination pour tenir compte de la nouvelle taille, et la table de partition secondaire peut être recréée à la fin du disque s’il y a suffisamment d’espace libre (il faut 13 secteurs pour une table de taille standard avec 128 partitions maxi).
Par contre c’est beaucoup plus gênant si une ou plusieurs partitions dépassent.
Que contient le disque source ?
Quel est le but de la copie ?
Si la table de partition n’a pas été modifiée et a encore la taille d’origine de 120 Go, alors il n’y aura pas de problème de troncature. La table de partition secondaire sera au mauvais endroit puisqu’elle ne sera pas à la fin du disque, mais c’était déjà le cas sur le disque actuel.
Par contre il ne faut pas exécuter la copie alors que des partitions sont montées en lecture-écriture. Le mode dépannage ne suffit pas car les partitions sont montées en lecture-écriture et certains services sont déjà démarrés. Il y a plusieurs méthodes, par exemple
utiliser un autre système (live ou installé sur un autre disque)
passer au noyau l’option break pour utiliser le shell de l’initramfs avant que la racine soit montée.
passer au noyau les options ro init=/bin/bash pour lancer bash au lieu de l’init normal avec la racine en lecture seule.
D’après ce que je te mets dans mon second message, il semblerait que non.
Disque source = une Jessie complète, avec
’/’ = 25 Gb
Swap = 8 Gb
Bios_Grub = 1049 Kb
/home = 80 Gb
J’avais copié ce disque en réserve, avant de ripper le SSD en Stretch, et j’avais bien fait car Stretch me pose des problèmes avec le noyau 4.9 (le 3.26 va bien)
je pense que c’est le plus facile pour moi.
Pour arrêter le processus actuel, quelle commande est la plus sure ?
Ctrl+c
Merci, je fais.
Je vais quand même, par curiosité, voir ce qui a été copié sur le disque destination.
Ensuite, je recommencerai à partir une disque externe Jessie qui va parfaitement.
EDIT :
Résultat après le Ctrl+c
ricardo@dd3-5:~$ sudo dd if=/dev/sda of=/dev/sdb conv=notrunc,noerror
^C821491945+0 enregistrements lus
821491944+0 enregistrements écrits
420603875328 octets (421 GB) copiés, 15460,6 s, 27,2 MB/s
ricardo@dd3-5:~$
~ 4h20 
Avec la taille de bloc qui va bien ça devrait aller au moins 4 fois plus vite.
PS : attention à ne pas te tromper dans les noms de périphérique des disques, il peuvent changer d’un démarrage à l’autre.
que dois-je ajouter à la commande ?
Oui, pour les périphériques, je me méfie toujours.
bs=1M conv=sync,noerror
Merci, j’en tiendrai compte.
Pas de problèmes apparents sur le disque source, que je viens de tester.
Copie terminée.
Des erreurs annoncées sur le cloné :
ricardo@serveur:~$ sudo dd if=/dev/sda of=/dev/sdb bs=1M conv=sync,noerror
dd: erreur d’écriture de « /dev/sdb »: Aucun espace disponible sur le périphérique
476941+0 enregistrements lus
476940+0 enregistrements écrits
500107862016 octets (500 GB) copiés, 6480,67 s, 77,2 MB/s
ricardo@serveur:~$
fdisk -l : en gras ce qui est en rouge sur la console
Mauvaise concordance des tailles de partition du secteur d’amorçage GPT (1250263727 != 976773167), elle seront corrigées par la commande w (écriture).
Disque /dev/sdb : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d’E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d’étiquette de disque : dos
Identifiant de disque : 0x2de92de8
Device Boot Start End Sectors Size Id Type
/dev/sdb1 1 1250263727 1250263727 596,2G ee GPT
La partition 2 ne commence pas sur une frontière de cylindre physique.
Normal, la fin du disque de destination est atteinte avant la fin du disque source.
Ah c’est vrai, j’avais oublié qu’en plus il faudrait corriger la taille de la partition de protection GPT du MBR qui va du secteur 1 à la fin du disque.
Quant à son alignement, on s’en fiche.
(et il y a toujours ce bug d’affichage de fdisk qui décale de 1 le numéro de la partition censée ne pas être alignée)
Note que fdisk a affiché la table de partition DOS/MBR qui ne contient que la partition de protection GPT factice. Après correction, il faudra relancer fdisk pour vérifier qu’il affiche bien la table de partition GPT qui contient les véritables partitions.
Je pense qu’il va me falloir modifier Grub, car il ne prend pas en compte l’UUID de ce nouveau disque. Le clonage a bien été complet, y-compris pour les UUID de disque.
Si je ne laisse que le seul disque nouveau de connecté, j’ai l’alerte :
/dev/disk/by-uuid/57dxxxxxxxxxxxxxxxxxxxed does not exist
uuid qui est celle du disque mère.
Est-ce que je dois faire un update-grub avec les deux disques connectés, et à partir du disque mère ?
Avant de faire des bêtises, je préfère attendre ta réponse.
Retour lundi pas avant 11 heures.
A quel moment cette alerte se produit-elle ? Bloque-t-elle le démarrage ?
A quoi cet UUID correspond-il sur le disque d’origine ? A voir avec blkid ou dans /dev/disk/by-uuid.
Il faut éviter de démarrer avec les deux disques connectés car ils sont censés contenir les mêmes UUID, ce qui va perturber libblkid et donc udev.
Oui, pas de démarrage du tout.
Grub charge normalement et après quelques secondes d’attente, j’ai cette alerte :
…does not exist
BusyBox…
/bin/sh can’t access tty…
(initramfs)
Le disque cloné est seul présent.
Impossible d’en voir plus car même en recovery, après des lignes de :
"Begin : Running /scripts/local-block…done."
je retrouve la même alerte :
.
.
.
(initramfs)
EDIT :
L’UUID refusée est celle du disque mère