Ce post a été publié sur LinuxFr.org. Vous pouvez le lire là bas, ainsi que les commentaires associés
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.
Notes post-publication : Les commentaires sur LinuxFr.org ont suggéré d’intéressants outils pour migrer les partitions d’un disque à l’autre:
- évidemment la doc ArchLinux sur LVM,
- les commandes
pvmove,pvresize,vgextend, toujours pour LVM, - une doc sur la copie du système
entier
avec
rsync,grub-install, etc.