Manip sur LVM et "resize2fs can't read an block bitmap while trying to resize"
Me voici bien embarrassé (je veux rester poli): lorsque je suis sur des disques de faible capacité (comme des SSD) j'installe mes Linux sur des partitions/volumes logiques (LV). Cela me permet de redimensionner en cas de besoin. C'est ce qui s'est passé aujourd'hui, bien sûr j'ai m**dé et j'ai cru perdre mon système. Hé bien non ! Linux, y a pas à dire c'est quand même bien. L'article qui suit retrace cet épisode.
Avertissement: ce qui suit reste très technique et le risque de perdre votre système est réel. Donc à lire pour information et à suivre/adapter éventuellement que si la situation est désespérée. Mais dans ce cas vous restez seul responsable de ce que vous faites. Par ailleurs je l'ai fait de mémoire, et il est possible que quelques erreurs se soit glissées.
0 - Tout d'abord le contexte:
- une LMDE (Linux Mint Debian Edition) installée sur un SSD découpé en 3 Volumes Logiques (LV): lvboot, lvroot, lvhome.
- une mise à jour importante (UP8) qui demande plus de 1Go d'espace mémoire alors qu'il me reste sur lvroot ~500Mo, ce qui même pour une mise à jour minimale s'avère insuffisant (bien évidemment j'ai essayé de faire du ménage comme conseillé sur cette page Debian mais mon système était 'clean').
Donc il est temps pour moi de redimensionner mes LV (et non seulement augmenter lvroot) car j'ai réparti toute ma capacité disque sur mes 3 volumes. Il me faut donc et dans cet ordre:
- réduire lvhome
- augmenter lvroot
Ma page Comment gérer son espace mémoire avec LVM (Logical Volume Manager) ? sera mon guide, notamment son paragraphe 5 intitulé "Quelques commandes d'administration"
Une augmentation de LV peut se faire à "chaud", c.a.d LV monté mais pas l'inverse la réduction. Comme il s'agit ici de réduire lvhome cela peut se faire sans avoir recours à un liveCD. Il suffit de lancer le mode dépannage et/ou de se retrouver en mode console (le serveur X n'est pas lancé) administrateur.
Je suis donc ma fameuse page, mais je suis un peu perturbé :
- par une non correspondance entre la taille de mon home affichée 'avant' en mode graphique par mon moniteur système 54G et le volume que j'affiche maintenant avec un lvdisplay 50.52G
- et aussi un peu par ma petite fille (il faut bien que je me trouve des excuses :-)
J'ai libéré 1Go de PE que j'ai réattribué à lvroot et j'arrive donc à l'étape où il me faut remonter mon lvhome retaillé à 49.52G. Et là outre des grossièretés de type Warning "la taille de mon file system (fs) est supérieure à celle de mon volume", ou encore "le superbloc ou la table des partitions est peut-être corrompu !", j'ai un message qui va me suivre pendant quelques temps: "resize2fs can't read an block bitmap while trying to resize" car il reviendra en boucle.
Sur le net vous trouverez un bon nombre de situations similaires et souvent désespérées. Par contre cet article décrit une situation très semblable à celle que j'ai rencontrée, mais dont sa résolution passe par l'utilisation de parted que ... curieusement je n'ai pas sur ma machine (alors que j'ai gparted) !
En résumé ma situation est le résultat des commandes suivantes:
# umount /home # lvreduce -L -1g /dev/vgmint/lvhome # Grossière ERREUR il fallait d'abord lancer un resize2fs # lvextend -L +1g /dev/vgmint/lvroot # resize2fs /dev/vgmint/lvroot # Je ne suis plus si sûr de l'avoir fait
La catastrophe se révèle lors:
# mount /dev/vgmint/lvhome /home
qui me retourne quelque chose comme: Erreur, mauvaise géométrie (Wrong bad geometry) j'essaie de monter un fs de 13183337 blocks sur un volume de 12982272. (Pourtant le 13183337 a été obtenu par soustraction de 256 blocks, soit 1G, au nombre initial ?!)
A ce moment là on se dit que rien n'est perdu, redimensionnons le fs ! Sauf que j'ai alors mon fameux message "resize2fs can't read an block bitmap while trying to resize".
Là on se dit qu'on est mal parti !
J'ai fait plein de manip avant de trouver la bonne séquence qui m'a sortie de ce mauvais pas.
1 - Remettre la situation initiale, donc récupérer mes 1G de lvroot pour les remettre sur lvhome
# lvreduce -L -1g /dev/vgmint/lvroot
Là cela va râler car bien évidemment le LV n'est pas démonté (vous ne pouvez pas car vous travaillez dessus !) et vous demande si vous êtes sûr de vouloir faire cela en sachant qu'il y a un risque de perdre des données. Cela fait peur, mais il n'y a pas d'autre moyen que de continuer (et par ailleurs au cas précis je n'ai modifié que les pointeurs des fs et des lv mais je n'ai absolument pas touché aux données, donc en croisant les doigts ...)
Un # pvdisplay confirmera la libération de ces 1G sous la forme d'un nombre de "Free PE".
2 - Maintenant nous allons ré affecter ces 1G à lvhome
# lvextend -L +1g /dev/vgmint/lvhome # resize2fs /dev/vgmint/lvhome
A ce stade je suis revenu à la situation initiale, je peux monter /dev/vgmint/lvhome sur /home et lancer le PC. Mais ce n'est pas ce que je vais faire puisque il me faut toujours agrandir lvroot !
3 - On redimensionne le fs et on diminue la taille de lvhome (démonté)
Pour diminuer un LV, il est impératif de démonter le LV, de redimensionner le fs et enfin de réduire le LV.
# umount /home # resize2fs /dev/vgmint/lvhome 12982272
Le 12982272 est celui obtenu précédemment (Cf. Contexte) je n'ai pas cherché à comprendre ce chiffre qui me donne un équivalent de 53,17Go !?
# lvreduce -L -1g /dev/vgmint/lvhome
On s'assure que tout est correct par un :
# e2fsck -f /dev/vgmint/lvhome
Le lvhome peut être remonté.
# mount /dev/vgmint/lvhome /home
4 - Reste à augmenter la taille de lvroot, l'objectif principal de cette manip
Pour augmenter un LV, point besoin de le démonter mais l'ordre est inverse de celui de la diminution: on étend le LV et ensuite on redimensionne le fs.
# lvextend -L +1g /dev/vgmint/lvroot # resize2fs /dev/vgmint/lvroot
Et voilà, tout est en ordre, comme pourra le confirmer un lvdisplay, pvdisplay, ou encore un dumpe2fs /dev/vgmint/lv??? | grep ^Block. Il ne reste plus qu'à sortir du mode console (Ctrl+d chez moi) et/ou redémarrer.