Redimensionnement d'une LV et boot impossible

bertaudmarc · 26-01-2020 19:39:42

Bonjour,
Sur un portable ayant deux disques, j'ai crée avec lvm:
Un volume group VG0 contenant boot et root sur le premier disque
Un volume group VG1 contenant home,var,tmp,swap sur le deuxime disque

pvs

/dev/sda1 VG0 ...

/dev/sdb1 VG1 ...

lvs

lv-boot VG0 ...

lv-root VG0

lv-home VG1 ...

lv-tmp VG1 ...

lv-var VG1 ...

swap VG1 ...

Tout allait bien jusqu'à un redimensionnement ...:
J'ai diminué home de 50G
J'ai aggrandi var de 50G
et j'ai du faire une mauvaise manip ou oublié qqch ?
Résultat: au boot, j'ai un message "failed to start file system check pour lv-home" et je me retrouve en maintenance.

J'ai fais :

fsck /dev/mapper/VG1-lv--home

filesystem size is 36620288 blocks

physical size of the device is 23461888 blocks

Il y donc une incohérence.
J'essaye de réduire la taille du fs à celle du device :

resize2fs /dev/mapper/VG1-lv--home 23461888

cannot read a block bitmap ...

Please run e2fsck -fy /dev/mapper/VG1-lv--home 

Je le fais:
et j'obtiens le même message qu'avec fsck

Bref, je tourne en rond

Peut-on corriger/réparer ce problème ?

Si j'efface home (dans le pire des cas, tant pis ...) par lvremove ... cela va t'il résoudre le problème ?

NB: le problème a lieu sur un portable donc obligé de retranscrire ici ce que je vois.

Merci d'avance

Dernière modification par bertaudmarc (26-01-2020 19:49:52)

raleur · 26-01-2020 20:04:22

Apparemment tu as oublié de réduire le système de fichiers ext4 dans home à la nouvelle taille avec resize2fs AVANT de réduire le volume logique avec lvresize ou lvreduce. Ce sont deux opérations bien distinctes qu'il faut impérativement faire dans l'ordre (ou utiliser l'option --resizefs de lvm).
D'après mon expérience, il n'est pas possible de faire quoi que ce soit avec un système de fichiers ext* tant que la taille de son conteneur n'est pas corrigée.

Si tu as une sauvegarde du contenu de home, le plus simple est de le reformater et d'y restaurer les données. Sinon, il faut agrandir à nouveau le volume logique, mais en faisant en sorte qu'il utilise les mêmes blocs (extents LVM) qu'avant sa réduction pour éviter une perte massive de données.

As-tu déjà agrandi le système de fichiers de var avec resize2fs ? Si non, il doit être possible de restaurer l'état des volumes logiques avant les redimensionnements grâce au contenu de /etc/lvm/archive. Si oui, il faudra réduire le système de fichiers de var à sa taille originelle (ou moins), mais l'agrandissement risque d'avoir provoqué l'écrasement des données de certains blocs qui appartenaient à home précédemment, donc tu ne t'en tireras pas sans dommage.

Question subsidiaire : pourquoi avoir réduit home ?

Dernière modification par raleur (26-01-2020 20:09:45)

bertaudmarc · 26-01-2020 21:03:16

J'ai réduit home car mes machines virtuelles situées dans /var/lib/libvirt/images avaient besoin de place.
J'ai donc aggrandi var au détriment de home sachant que la taille du disque était limitée.

Je n'ai malheureusement pas noté ce que j'ai fais et dans quel ordre.
Aggrandir home ne semble pas possible (pas assez de réserve)
J'ai déjà aggrandi var

Donc je peux faire un lvremove de home et le recrée puis récupérer son contenu d'un backup ? Qu'en penses-tu ?

raleur · 26-01-2020 21:22:59

bertaudmarc a écrit :

J'ai donc aggrandi var au détriment de home sachant que la taille du disque était limitée.

Si je comprends bien, il n'y avait pas d'espace libre dans le groupe de volumes ?
Comment se fait-il qu'il y avait autant d'espace libre dans /home et pas d'espace libre dans le groupe de volumes ?

bertaudmarc a écrit :

Je n'ai malheureusement pas noté ce que j'ai fais et dans quel ordre.

Si tu avais exécuté les commandes en root (pas sudo) depuis ce système, tu peux les retrouver dans l'historique du shell root avec la commande "history".

bertaudmarc a écrit :

Donc je peux faire un lvremove de home et le recrée puis récupérer son contenu d'un backup ? Qu'en penses-tu ?

Je ne vois pas l'intérêt de supprimer et recréer le volume logique. Il suffit de le reformater, comme je l'ai déjà écrit.

Dernière modification par raleur (26-01-2020 21:25:15)

bertaudmarc · 26-01-2020 23:07:25

Si je comprends bien, il n'y avait pas d'espace libre dans le groupe de volumes ?
Comment se fait-il qu'il y avait autant d'espace libre dans /home et pas d'espace libre dans le groupe de volumes ?

Il restait pas grand chose.
J'ai vu trop grand pour home à l'époque.

Si tu avais exécuté les commandes en root (pas sudo) depuis ce système, tu peux les retrouver dans l'historique du shell root avec la commande "history".

Je n'y avais pas pensé ...

Je vais essayer de retrouver cela demain... donc à demain et merci

Dernière modification par bertaudmarc (26-01-2020 23:20:26)

bertaudmarc · 26-01-2020 23:33:35

Apparemment j'ai fais cela en plusieurs fois et j'ai utilisé gparted pour déplacer les trous.

lvs
pvs
lvextend -L +20G ...lv-var
resize2fs ...lv-var
lvresize -l -50G ...lv-home
resize2fs ...lv-home
lvextend -L +50G ...lv-var
resize2fs ...lv-var
lvextend -L -10G lv-home

Il manque un resize2fs de lv-home à la fin ?
Si je le fais maintenant cela me donne l'erreur: can't read a block bitmap ... Please run e2fsck etc ...

Dernière modification par bertaudmarc (26-01-2020 23:41:20)

raleur · 26-01-2020 23:36:57

bertaudmarc a écrit :

J'ai vu trop grand pour home à l'époque.

Pourtant l'utilisation de LVM aurait permis d'éviter ce genre d'erreur de dimensionnement initial, en commençant avec des tailles de LV minimales et en les augmentant seulement au fur et à mesure des besoins ce qui limite au maximum le risque de manquer d'espace libre dans le VG et de devoir réduire un des LV.

bertaudmarc · 26-01-2020 23:43:09

On apprend à ses dépens !

Donc irrécupérable ?

Dernière modification par bertaudmarc (26-01-2020 23:43:52)

raleur · 26-01-2020 23:48:39

bertaudmarc a écrit :

j'ai utilisé gparted pour déplacer les trous

Que veux-tu dire par "déplacer les trous" ? Que je sache, gparted ne sait pas gérer les volumes logiques LVM.

bertaudmarc a écrit :

lvresize -l -50G ...lv-home
resize2fs ...lv-home

Si tu as exécuté les commandes dans cet ordre, ça n'a pas pu marcher. resize2fs avec la nouvelle taille doit précéder la réduction du volume logique.

bertaudmarc a écrit :

lvextend -L -10G lv-home

Euh, lvextend ne supporte pas une valeur négative de l'option -L (qui reviendrait à réduire).

bertaudmarc · 26-01-2020 23:59:17

Je pense que gparted voit les lv comme des partitions.

J'ai vérifié: j'ai bien fais lvextend -L -10G ...lv-home

raleur · 27-01-2020 00:06:31

bertaudmarc a écrit :

Donc irrécupérable ?

Comme tu as agrandi le système de fichier de lv-var avec les blocs récupérés de lv-home, il y a un risque non nul que le système ait commencé à écrire dans des blocs qui contenaient des données utiles de lv-home . Donc même si tu parvenais à réattribuer ces blocs à lv-home, rien ne garantit que leur contenu serait intact. Si tu as une sauvegarde du contenu de lv-home, il est plus sûr de reformater le volume et de restaurer les données.

bertaudmarc a écrit :

Je pense que gparted voit les lv comme des partitions.

M'étonnerait. Quand bien même, qu'as-tu fait exactement avec ?

bertaudmarc a écrit :

J'ai vérifié: j'ai bien fais lvextend -L -10G ...lv-home

Cette commande est incorrecte, elle n'a pas pu avoir le moindre effet.

bertaudmarc · 27-01-2020 13:25:10

Avec gparted, j'ai déplacé les blocs non alloués.
Pour le lvextend, j'ai peut-être pas fait attention à un message d'erreur: j'ai merdé.

Bon, je fais donc un mkfs.ext4 /dev/mapper/VG1-lv--home ?

Dernière modification par bertaudmarc (27-01-2020 13:41:19)

raleur · 27-01-2020 15:38:33

Oui, si tu as une sauvegarde des données.

Je ne comprends toujours pas ce que tu as fait avec gparted. Les blocs non alloués de quoi ? Déplacé vers où ?

bertaudmarc · 27-01-2020 17:13:41

mkfs OK
Il faut juste recréer le user

dans gparted j'avais /home libre /var /tmp libre
j'ai fais des déplacements pour avoir /home /var libre /tmp

raleur · 27-01-2020 19:12:03

Pas besoin de recréer l'utilisateur, il suffit de restaurer son répertoire personnel à partir de la sauvegarde.

Ma version de gparted ne permet pas de déplacer les volumes logiques, elle doit être trop ancienne. De toute façon je ne vois pas l'intérêt, un des avantages de LVM est justement que les volumes logiques n'ont pas besoin d'être constitués de blocs contigus contrairement aux partitions.

bertaudmarc · 27-01-2020 23:27:57

Merci pour ton soutien

Debian Alain · 27-01-2020 23:43:20

https://doc.ubuntu-fr.org/lvm#redimensionnement

çà peut pas intéresser qqun ? bertaudmarc , par exemple ?

bertaudmarc · 29-01-2020 14:50:03

Si tout est bon à prendre

Debian-facile

#1 26-01-2020 19:39:42

Redimensionnement d'une LV et boot impossible

#2 26-01-2020 20:04:22

Re : Redimensionnement d'une LV et boot impossible

#3 26-01-2020 21:03:16

Re : Redimensionnement d'une LV et boot impossible

#4 26-01-2020 21:22:59

Re : Redimensionnement d'une LV et boot impossible

#5 26-01-2020 23:07:25

Re : Redimensionnement d'une LV et boot impossible

#6 26-01-2020 23:33:35

Re : Redimensionnement d'une LV et boot impossible

#7 26-01-2020 23:36:57

Re : Redimensionnement d'une LV et boot impossible

#8 26-01-2020 23:43:09

Re : Redimensionnement d'une LV et boot impossible

#9 26-01-2020 23:48:39

Re : Redimensionnement d'une LV et boot impossible

#10 26-01-2020 23:59:17

Re : Redimensionnement d'une LV et boot impossible

#11 27-01-2020 00:06:31

Re : Redimensionnement d'une LV et boot impossible

#12 27-01-2020 13:25:10

Re : Redimensionnement d'une LV et boot impossible

#13 27-01-2020 15:38:33

Re : Redimensionnement d'une LV et boot impossible

#14 27-01-2020 17:13:41

Re : Redimensionnement d'une LV et boot impossible

#15 27-01-2020 19:12:03

Re : Redimensionnement d'une LV et boot impossible

#16 27-01-2020 23:27:57

Re : Redimensionnement d'une LV et boot impossible

#17 27-01-2020 23:43:20

Re : Redimensionnement d'une LV et boot impossible

#18 29-01-2020 14:50:03

Re : Redimensionnement d'une LV et boot impossible

Pied de page des forums