Journal Une méthode inefficace pour remplacer un disque dur

Sommaire

• dd
• resize2fs
• Device UUID
• rsync
• grub-install
• update-initramfs
• Conclusion

Bonjour 'nal,

J'étais tranquille en train de m'occuper de mes propres affaires quand soudain il n'y avait plus beaucoup de place sur le disque du NAS à la maison. Cela faisait des mois et des mois que l'on se battait pour gratter un giga par ici, un gigot par là, et force est de constater que la situation ne s'améliorait pas. 500 GB remplis à ras bord et plus grand chose à supprimer.

Bon allez je cède, je commande un SSD 1 TB en remplacement, et tant qu'a faire je vais changer les disques mécaniques des autres ordis. Allez hop, c'est parti pour le grand remplacement.

dd

Le NAS est en réalité un vieil Eee PC dans lequel le disque n'est pas facilement accessible. Il faut démonter le clavier, puis dévisser et retirer le cache, et enfin débrancher une nappe pour pouvoir retirer le support sur lequel le disque est vissé. J'en ai profité au passage pour casser une prise de la nappe, non sans m'étonner qu'il faille forcer autant pour la décoincer. Bah en fait il ne fallait pas forcer, comme pour les huit milles fois où j'ai abîmé un truc en forçant… C'est une leçon qui a du mal à rentrer.

Heureusement dans ce cas j'ai pu remettre la nappe en place, bien fixée. La petite nappe du touchpad, quant à elle, refuse de tenir en place dans son slot fendu, vestige d'une époque où je démontais les ordis en forçant. Heureusement cette époque est révolue. Mais bon, on s'en fiche, qui a besoin d'un touchpad sur un NAS ?

J'ai donc sorti l'ancien disque, et comme je n'avais pas envie de me refaire une installation du système je me suis dit, pas bête, que j'allais simplement transférer les données de l'ancien disque au nouveau à coup de dd. Je suis un vrai hacker, tellement malin et ingénieux. Il s'avère après coup que c'était en fait la pire idée.

Les deux disques branchés via des boîtiers USB sur un autre ordi, je lance la commande. Ça prend un peu plus de 5 h à 30 MB/s. sans surprise. On en a déjà parlé lors d'une précédente anecdote, l'USB en pratique n'est pas aussi efficace qu'en théorie.

Une fois la copie terminée je lance GParted. Il me sort un message au sujet d'un backup GPT incorrect que je ne comprends pas et me propose de corriger lui-même le problème. Allez, fais donc ça. Ensuite il me présente bien les trois partitions : GPT, /boot, et / ; cette dernière étant chiffrée. J'étends / pour occuper tout l'espace puis je remets le disque dans le NAS.

Ça démarre sans problème. J'entre le mot de passe du disque, ça passe, puis le boot se termine correctement. J'entre le login et le mot de passe, puis je vérifie que l'opération a bien donné le résultat attendu.

$ df --human-readable
Filesystem             Size  Used  Avail  Capacity  Mounted on
/dev/sda2                1G  430M   570M       42%  /boot
/dev/mapper/ubuntu-vg  500G  498G     2M       99%  /

Bah ! Où qu'il est mon tera ?

resize2fs

Un coup de fdisk --list indique que les partitions ont bien la taille attendue ; tout le disque est occupé. Tout ? Tout. Je ne sais pas ce qu'il se passe et je fais l'hypothèse qu'il y a une différence entre la taille telle qu'indiquée dans la table des partitions et celle vue par ext4. À moins que ce soit le LVM entre les deux ? Nouvelle stratégie :

$ resize2fs /dev/mapper/ubuntu-vg
resize2fs: New size results in too many block group descriptors.

Ah mais c'est pas vrai, il n'y a rien qui marche à la fin ! Après une petite recherche sur le web je trouve un internaute prétendant que je fais n'importe quoi. Pfff, qu'est-ce qu'il y connaît ce tytso ?

Bon, okay, je remballe ma fierté… Ça fait pas loin de huit heures que je jongle avec des étrons sans le savoir.

Device UUID

Tant pis, me dis-je, je vais formater le disque correctement et transférer les données d'un disque à l'autre avec rsync. Comme je n'ai pas envie de bosser sur le NAS poussif je sors à nouveau le disque, je le remets dans un boitier USB et je rebranche tout sur l'autre ordi. Il s'avère après coup que c'était en fait la pire idée.

Sur l'autre ordi, c'est le bazar. GParted n'arrive pas à créer les partitions. Il me sort toujours l'erreur au sujet de GPT. Je lance fdisk mais celui-ci me sort la même erreur. Un internaute me conseille de supprimer et recréer les partitions aux mêmes offsets, sans effacer les données. C'est rigolo, et un peu flippant, mais ça ne change rien.

Et soudain la lumière. Je vois dans la sortie de fdisk que les deux disques ont le même UUID. J'en débranche un, et hop plus de problème de GPT. Il semblerait que le système n'y voit plus très clair quand deux ressources ont le même Universally Unique IDentifier. Qui aurait pu prévoir ?

Après avoir changé l'UUID du disque grâce à l'aide du web (bien pratique ce recueil de connaissances) je remets d'équerre la partition chiffrée. Je monte la partition, tout à l'air okay. Je rebranche le second disque, 🎵touc-ta🎵ta-touc🎵 (sons de GNOME qui monte puis démonte le disque). Tiens tiens, me dis-je, on dirait que Nautilus buggue. M'en fiche, je n'ai pas besoin de l'UI, je vais monter la partition dans le terminal.

mount: unknown filesystem type 'LVM2_member'

Vazyyyyyy keskya encore ? À nouveau, une petite recherche sur le web me donne rapidement la réponse (décidément ce web est sacrément pratique). Il s'avère que les deux disques externes ont chacun un groupe de volumes, et que ces groupes ont le même nom. Ça devient compliqué pour le système. Quelle bonne idée d'avoir fait un dd !

rsync

Finalement je renomme le groupe de volumes, ce qui me permet de monter les deux disques. Un coup de rsync --archive et six heures plus tard je peux remettre le disque dans le NAS. Ça boute, reste à entrer le mot de passe pour déchiffrer le disque.

Not enough available memory to open a keyslot.

Bon okay, je dois être installé sur un cimetière indien ou un truc dans le genre. Nouvelle recherche sur le web (bien pratique cet outil), j'y apprends que le chiffrement appliqué par Luks dépend des ressources du système, alors évidemment il s'est basé sur l'ordi sur lequel j'ai fait les manips, plus puissant que l'Eee PC. Là où j'avais branché les disques en externe. Pour. Gagner. Du. Temps.

grub-install

Allez allez, on perd pas le moral. Je remets le disque dans le NAS et je démarre sur une distribution live pour refaire tout le partitionnement. Aucun souci ici si ce n'est que les menus en texte du live d'Ubuntu Server sont en blanc sur fond jaune. C'est illisible mais en plissant les yeux j'arrive à faire mes manips. Je sors ensuite à nouveau le disque que je branche en externe sur l'autre ordi. Le disque apparaît correctement partitionné et il est maintenant vierge et bien monté. Je peux voir les deux disques externes en même temps. Je copie les données de l'un à l'autre avec rsync et il ne reste plus qu'à remettre GRUB. Ça franchement c'est fastoche, je l'ai fait plein de fois.

$ cryptsetup luksOpen /dev/sdb3
$ mount /dev/mapper/nas-vg /mnt
$ mount /dev/sdb2 /mnt/boot
$ mount --bind /dev /mnt/dev
$ mount --bind /proc /mnt/proc
$ mount --bind /sys /mnt/sys
$ chroot /mnt
$ grub-install /dev/sdb

Ceci terminé je remets le disque dans le NAS, je l'allume, eeeeeeeeeeeet… pas de GRUB. Enfin si, mais il me dit qu'il ne sait pas quoi faire.

update-initramfs

Après une courte recherche (je te laisse deviner où j'ai trouvé l'info) j'apprends que j'aurais dû lancer update-initramfs -u -k all à la suite des commandes précédentes. Pas de souci, je fais ça à partir du système live.

cryptsetup: WARNING: failed to detect canonical device of overlayfs
cryptsetup: WARNING: could not determine root device from /etc/fstab

Rhô là là ça sent pas bon encore. Après un petit tour sur le web. Je comprends qu'il y a une incohérence entre les UUIDs des partitions tels qu'indiqués par lsblk --fs et ceux notés dans /etc/fstab et /etc/crypttab. Quelle bonne idée d'avoir fait un rsync !

Après avoir aligné ces deux derniers avec la sortie de lsblk je relance update-initramfs qui se termine sans erreur ni avertissement. Je redémarre le NAS, entre la clé du disque… tout se passe bien.

$ df --human-readable
Filesystem          Size  Used Avail Use% Mounted on
/dev/mapper/nas-vg  914G  434G  434G  51% /
/dev/sda2           2.0G  181M  1.7G  10% /boot

C'était vraiment trop facile.

Conclusion

Des fois on pense gagner du temps en étant malin et finalement ce n'est que de la perte. On essaye alors de sauver la face en se disant qu'on a appris des trucs.

Des fois ont fait des trucs alors qu'on sait très bien que c'est une mauvaise idée. Parfois on s'y est même déjà brûlé plusieurs fois (RIP la nappe du touchpad).

Cette histoire illustre ce qui peut arriver quand on combine les deux : un enchaînement de mauvaises idées et de prises de décision en étant mal informé, le tout pour une perte de temps maximale. Si j'étais payé à l'énergie dépensée j'aurais fait fortune.

Pour les autres ordis j'ai opté pour un formatage complet suivi d'un rsync de $HOME uniquement. J'ai quand même eu quelques pépins mais rien d'aussi pénible qu'ici.

Un grand merci à tous les usagers du web qui prennent le temps d'expliquer leurs problèmes et à ceux qui se donnent la peine de proposer des solutions. J'espère que cet espace d'échanges ouverts va conserver cet état d'esprit et ne va pas se faire pourrir par des parasites.

Au moins j'aurai appris des trucs.