[Abandonné]LVM>Démarrage impossible après extension de /root

Support Debian
#1

Bonjour à tous,

Je m’appelle Nicolas, c’est la première fois que je poste sur ce forum, et j’espère, qu’il ne s’agit pas d’un quelconque doublon !

Je travaille sous une Debian Wheezy (kernel 3.2 / 3.7, amd64), fraichement installée depuis quelques semaines.
J’ai utilisé le système de gestion des disques LVM avec un seul groupe de volumes et 6 partitions :

/root
/tmp
/var
/home
/swap
/usr

qui sont toutes des volumes logique au sein de cette configuration LVM.
Cette configuration a été proposé par l’assistant lors de l’insation de l’OS.

Sur le SSD du portable du boulot, de 256Go, seulement 333 Mo était alloué au volume /root, et j’ai eu besoin d’augmenter sa taille.
Du coup, n’ayant plus de place dans le groupe de volume j’ai supprimé 10Go à mon /home pour en récupérer 2Go que j’ai mis à mon /root.

J’ai suivi des tutos sur internet et j’ai fait les commandes suivantes :

Enlever 10Go à mon /home, en mode console

umount /home
e2fsck -f /dev/mapper/volume_group/home
resize2fs /dev/mapper/volume_group/home 200G // (210 Go initiallement)
lvreduce -L 200G /dev/mapper/volume_group/home

Ensuite j’ai rajouté 2Go à mon /root (sans le démonter)

e2fsck -f /dev/mapper/volume_group/root
lvextends -L+2G /dev/mapper/volume_group/root
resize2fs /dev/mapper/volume_group/root

Après redémarrage de l’ordinateur, grub se lance et ensuite je tombe sur une console (pas d’invité graphique pour ouvrir une session) et je ne parviens pas à me logguer. Et cela quelque soit le noyau linux (3.2 / 3.7) / recovery mode …
Sans doute que la partition /root n’est pas montée.

Je me demande si j’ai fait une fausse manip, ou bien si j’ai oublié quelque chose ? Si un pro du LVM sous Debian / Linux pourrait m’éclairer, je suis preneur ! C’est l’ordi de mon boulot, et j’espère que je n’aurais pas à le réinstaller en entier.

D’avance, je vous remercie pour vos conseils …
Nicolas.

#2

Salut,

Dommage de ne pas avoir utilisé les commandes lvreduce,lvextent avant resize2fs !

#3

Quelle console ? Est-ce le shell de grub (signe qu’il n’a pas pu charger le noyau), le shell de secours de l’initramfs (signe que la racine n’a pu être montée), le shell root de récupération (single user)… ? Quelles sont les lignes et l’erreur qui s’affichent juste avant ?

Je ne comprends pas ta remarque. L’OP a bien réduit le système de fichiers avec resize2fs avant de réduire le LV avec lvreduce (et non l’inverse), puis agrandi l’autre LV avec lvextend avant d’ajuster le système de fichiers avec resize2fs.

Par contre j’aurais évité le e2fsck -f sur un système de fichiers monté…

#4

Salut,

[quote]Je ne comprends pas ta remarque. L’OP a bien réduit le système de fichiers avec resize2fs avant de réduire le LV avec lvreduce (et non l’inverse), puis agrandi l’autre LV avec lvextend avant d’ajuster le système de fichiers avec resize2fs.
[/quote]

Personnellement j’aurai fait le reduce du volume avant le resize du système de fichier, mais je peux me tromper !

#5

Surtout pas ! En faisant cela tu tronques la fin du système de fichiers, rendant impossible le déplacement vers le début des données qui se trouvaient à la fin.

On réduit d’abord le contenu et ensuite le contenant.
On agrandit d’abord le contenant et ensuite le contenu.

Contenant = volume, partition
Contenu = système de fichiers

#6

Re,

Comme d’habitude, merci Pascal :blush:

#7

Bonjour vous deux,

Merci pour vos réponses,
Alors, oui je rejoins Pascal sur cet avis (super explication by the way :wink: ), et il me semble que c’est ce que j’ai fais. “Il me semble” car, j’ai suivi des tutos sur internet pour faire la manip et je n’ai fait un reboot que quelques heures plus tard. Comme les tutos étaient sur le portable maintenant planté, je ne suis pas certains que je l’ai fait dans cet ordre. Mais bon, la plupart d’entre nous et le bon sens veulent que cela ne soit pas ça :slightly_smiling:

Sinon, pour vous donner un peu plus de précision, grub se lance bien, et lorsque je charge un noyau linux normalement, j’obtiens l’erreur suivante :

Ensuite je tombe sur une console, qui ne me semble pas de grub, ni de root (car il est impossible de se logger).
C’est les même consoles que tu as quand tu passes en Alt+F1 (je ne connais plus leur nom …).
Elles affichent :

Voici pour le mode normal, je regarde le mode “recovery” si j’obtiens plus d’information, et vous tiens au courant.

Merci en tout cas,
Nicolas.

Au fait, est-il possible de réinstaller seulement une partition lvm avec le disque d’installation ?
Par exemple remettre à neuf la partition /root dans mon cas ?
Merci.

#8

Voilà la stacktrace du démarrage sur le noyau 3.7 en mode recovery.
Cliquer dessus pour un plein écran

Y’a un beau segfault à la fin, mais on voit qu’il cherche à monter /root …

Est-ce que cela vous parle ?

Nico.

#9

Note : Il n’était pas utile de poster l’image avec une si haute résolution ; même en réduisant 20 fois sa taille, le texte serait resté parfaitement lisible.

En tout cas on voit que la racine est montée, init est lancé et on arrive à la demande du mot de passe root pour le shell de maintenance. Par contre il y a effectivement une erreur de segmentation qui se produit semble-t-il dans la libc lors de l’exécution du script /etc/init.d/rc, qui est appelé par init lors du changement de runlevel pour exécuter les scripts de démarrage et d’arrêt de services correspondants. C’est peut-être pour cela qu’en mode normal l’interface graphique ne démarre pas. Une erreur de segmentation peut être le signe d’une mémoire défectueuse ou d’un fichier corrompu.

En revanche je ne vois pas l’erreur concernant firmware-ohci que tu as mentionnée.

Que se passe-t-il si tu entres le mot de passe root pour ouvrir le shell de maintenance ou bien si tu essaies d’ouvrir une session utilisateur ou root dans une console virtuelle en mode normal ?

#10

Tu peux essayer de monter ta partition depuis un live-cd ou le mode rescue du cd de debian?

#11

Hello,

Je suis d’accord pour la résolution de l’image, je ne me suis pas pris la tête et je ne l’ai pas redimensionné, histoire d’être sur, mais bonne remarque :slightly_smiling:

Tu m’impressionnes sur tes connaissances ! Le portable est un dell precision M4700 (belle machine). J’ai lancé un test bas niveau hardware, un truc dell fourni par défaut avec le bios. Tous les tests sont bons, je pense qu’il s’agit plus d’un problème logiciel : fichier corrompus.

Je ne parviens pas à me logguer ! Aucun mot de passe ne fonctionne, que ce soit le mien ou celui de root.
Donc, bien qu’il demande d’accéder en root à la machine pour sa maintenance, cela ne m’est pas d’une grande aide ! :unamused:

Alors, oui je l’ai fait. J’ai utilisé le cd d’installation de la Wheezy (installation par le net), et j’ai utilisé le rescue mode.
J’ai pu monté la partition /root et ouvrir un terminal à partir de celle-ci. Mais que faire ?
Vous avez une idée des commandes que je pourrais lancer ? J’ai à ma disposition les outils de bases de la debian, notamment les outils de lvm. Je me suis dis que je pourrais refaire dans l’autre sens ma manipulation (enlevé 2Go à /root) …

Merci en tout cas de votre aide, c’est très sympa !
Nico.

#12

Je commencerais par vérifier le système de fichiers racine avec fsck.

#13

Hum, je viens de le faire avec le rescue cd, à priori c’est bon.
Par contre, mon mes partitions sont en ext4, l’utilisation de e2fsck auparavant était peut être mal venue du coup, vu que ce dernier ne check que ext2 …

Sinon, est-ce qu’il est possible, d’après vous de réinstaller seulement la partition /root avec le cd d’install ?

Merci d’avance,
Nico.

#14

Non, malgré son nom e2fsck traite aussi bien ext2, ext3 et ext4. Comme resize2fs. Si ça te tranquillise tu peux utiliser l’alias fsck.ext4.

$ ls -li /sbin/fsck.ext* /sbin/e2fsck 209874 -rwxr-xr-x 5 root root 172396 Jun 18 2011 /sbin/e2fsck 209874 -rwxr-xr-x 5 root root 172396 Jun 18 2011 /sbin/fsck.ext2 209874 -rwxr-xr-x 5 root root 172396 Jun 18 2011 /sbin/fsck.ext3 209874 -rwxr-xr-x 5 root root 172396 Jun 18 2011 /sbin/fsck.ext4 209874 -rwxr-xr-x 5 root root 172396 Jun 18 2011 /sbin/fsck.ext4dev
On peut voir que c’est le même inode, donc le même exécutable.

Pas que je sache. La réinstallation affecterait toute l’arborescence. On peut probablement réinstaller le contenu de paquets avec dpkg-deb dans /bin, /sbin, /lib… mais ce n’est pas une réinstallation.
Par contre il doit y avoir un outil pour vérifier que les fichiers correspondent bien au contenu des paquets, mais je ne me souviens plus de son nom…
EDIT: debsums doit faire l’affaire.

#15

Merci Pascal pour tes réponses et les infos que tu me donnes, c’est toujours intéressant (le coup des inodes sur le binaires etc …).

J’ai regardé ce que je pouvais faire avec le rescue cd, en ouvrant un terminal et en montant les partitions, mais les binaires dpkg-deb et debsums sont introuvables , ou alors j’ai pas regardé où il faut (dans le système rescue ou dans /root/(s)bin)

Je pensais qu’il y aurait un outils, qui s’orienterait plus vers la configuration LVM dans mon cas (vu que je pense qu’il s’agit d’un problème lié à ce dernier). Du coup, j’ai testé d’enlever à nouveau les 2G à ma partition /root en prenant soin de faire le resize2fs avant puis un lvreduce -L-2G, ce qui a bien fonctionné mais n’a pas restaurer le système correctement.

Sinon, petit correctif, le message d’erreur “firmware_ohci” était en fait “firewire_ohci” qui stipulait “registration failed” (j’avais mal lu). Et je ne pense pas que le firewire ait assez de pouvoir pour planter aussi drastiquement l’ordi.
Enfin, j’avais installé et lancé, avant que ça plante, apache2 sur la machine (afin de gérer l’édition d’un site internet), et je n’avais pas éteint le serveur avant de redémarrer l’ordi. Mais là aussi, il y a peu de chances que apache puisse faire planter la machine comme cela …

Bref, tout ça pour dire, que je suis un peu blasé de ne pas avoir réussi, au moins, à identifier plus clairement le problème. Et là, vu que je vais avoir besoin de l’ordinateur pour le boulot, j’envisage de le réinstaller, en virant LVM (candidat le plus probable de ce plantage).
Mais Si quelqu’un a une autre idée, je reste toujours ouvert :slightly_smiling:

En tout cas merci de vos idées, c’est sympa !
Bonne soirée.

Nicolas.

#16

dpkg-deb fait partie du paquet dpkg, il devrait être dans /usr/bin du système installé. Quant à debsums, il faut installer le paquet de même nom.

Tu n’as pas dit ce qui se passe si tu entres le mot de passe root pour ouvrir le shell de maintenance ou bien si tu essaies d’ouvrir une session utilisateur ou root dans une console virtuelle en mode normal.

#17

Salut Pascal,

Je vais regarder pour dpkg et debsums avec ce que tu proposes, je me suis donné jusqu’à aujourd’hui 19h pour essayer de récupérer mon système.

Pour répondre à ta deuxième remarque, je ne peux pas ouvrir de shell quelque soit le noyau chargé (mode recovery ou non), aucuns logins, root ou le mien n’est reconnus. Du coup, je peux seulement travailler à partir d’un live cd.

Par ailleurs, j’ai utilisé la dernière GParterd Live pour checker le disque, et voici l’ensemble des partitions (de mon disque /dev/sda)

/dev/sda1 / (avec le flag boot) en ext2
/dev/sda2 étendue
/dev/sda5 LVM contenant le groupe de volume dont j'ai détaillé les partitions au début de mon post.

Voilà, la table de partition semble correct la commande

fdisk -l /dev/sda

ne me renvoit pas d’erreur dans la table de partitions.

Du coup, est-ce que tu penses Pascal qu’il serait possible de réinstaller seulement la partition /dev/sda1 avec l’arborescence tout en conservant /home, /usr etc. contenu dans mon /dev/sda5 ?

D’avance, je te remercie et je te tiens au courant de mes tests.

Nicolas.

#18

Hello,

Bon j’ai tout monté sans problème et j’ai trouvé dpkg-deb. Malheureusement, je n’ai pas trouvé l’option pour réinstaller correctement les binaires (cet executable demande un .deb en entrée).
Je n’ai pas pu non plus checké avec debsums car il ne parvenait pas à l’installer (par internet).
Du coup, j’ai essayé de faire un

dpkg-reconfigure -a

malheuresement, il n’arrivait pas à accéder à des fichier de configuration dans /var …

Enfin, j’ai essayé de réinstaller seulement la partition / de base, tout en gardant mes partitions de ma LVM, ce qui s’est soldé également par un echec (impossible d’installer le système de base).

Voilà, la deadline est arrivée pour moi, j’ai décidé de tout réinstaller en sauvegardant mon /home sur un disque dur externe.
Cette fois ci j’ai fait deux partitions (/ et /home) sans LVM.

Dommage de ne pas avoir trouvé d’où venait le problème exactement, merci à tous pour votre participation.

Nicolas.