**Récupération d'un système Linux**

Un ''kernel panic'' peut arriver au démarrage par exemple si une machine virtuelle est brutalement coupé de ses fichiers du à une coupure SAN. Dans notre cas, le système de fichiers est complètement corrompu et logiquement la partition qui contient le kernel aussi.


====== Deux options pour récupérer un système de fichiers ======

Solution 1
  * La solution d’arrêter la machine défaillante et d’essayer de monter le disque dur sur un autre système Linux si c'est pour possible pour le checker avec e2fsck.

Solution 2
  * La seconde solution est d’utiliser un System Rescue CD (SRCD). Ce CD Live est téléchargeable ici : http://www.sysresccd.org/Index.fr.php

Procédure
Arrêter brutalement la machine avec un jolie bouton rouge.

Pour booter sur le CD, il faudra peut-être passer par le BIOS pour booter d’abord sur le CD avant le disque dur.

Après appuie sur la touche F2, mettre l’option du haut en fonction de l’architecture du système. (32 bits = rescuecd, 64 bits = rescue64).

Pour afficher les disques visibles sur le système.
<code>
fdisk -l
</code>

Visualiser les montages effectués.
<code>
mount
</code>

Démonter avec umount les volumes à vérifier.

Prendre le premier volume (ici la partition de ''/boot'') et le vérifier avec la commande e2fsck.
<code>
e2fsck -f /dev/sda1
</code>

Cette commande vérifie l’intégrité du système de fichiers. L’option -f l’oblige à checker la partition même si elle semble propre. 5 phases se déroulent. Si aucun message d’erreur ne s’affiche, le système de fichiers doit fonctionner.

Avec l’option -y
Passons maintenant au volume racine du système Red Hat. C’est ce volume qui a le plus de chance d’être cassé. Pour éviter d’avoir à donner une réponse pour chaque fichier, on peut lui spécifier de répondre oui à chacune de ces interrogations (c’est le –y). Cette commande n’est pas à faire si on veut avoir la maitrise du processus. 
<code>
e2fsck -f -y /dev/rootvg/rootlv
</code>

Pour vérifier qu’on est bon est que tous les tests sont passés.
<code>
e2fsck -f /dev/rootvg/rootlv
</code>

Sans l’option -y
J’ai fait le test sans l’option -y pour être sûr de ce que cela fait.
Avec la commande sans le -y, des demandes de réparation sont affichées pour chaque bloc. Cf. les 5 screenshots suivants pour voir ce que j’ai réalisé et ce que ca donne.

On nous demande si on veut réparer. C’est ce que nous voulons.
Il est très verbeux parce que rien est à sa place !

Viens ensuite un message nous demandant de mettre les fichiers à 0. Dans ma première passe, j’ai mis yes aux fichiers de /root car ils sont moins important. Ils peuvent être perdus et ils sont sauvegardés ailleurs.

Mais, arrivé aux fichiers importants comme dans /lib/modules, par sécurité, j’ai mis non pour les mises à zero des fichiers.

A force de maintenir la touche non, j’ai mis non aux dernières valeurs auxquelles il fallait que je mette yes.

Pour être sur que le fait de mettre yes de partout ne détruit pas les fichiers, j’ai relancé la commande suivante.
<code>
e2fsck -f -y /dev/rootvg/rootlv
</code>

Tout à été mis à yes et aucun des fichiers n’a été supprimés. Le système de fichiers a été nettoyé.
J’ai revérifié avec la commande suivante pour être sûr de l’absence de messages d’erreurs.
<code>
e2fsck -f /dev/rootvg/rootlv
</code>

Au final pour la racine, utiliser le –y en premier mais refaire un check sans après.


Même manipulation avec les autres volumes.
<code>
e2fsck -f /dev/rootvg/usrlv
e2fsck -f /dev/rootvg/tmplv
e2fsck -f /dev/rootvg/varlv
</code>


Si une partition de données est présente, la checker aussi. Elle devait être montée lorsque la coupure s’est produite. Elle est surement en LVM.
<code>
e2fsck -f /dev/data/data
ou 
e2fsck -f /dev/datavg/datalv
</code>

Ensuite les opérations de maintenance sont terminées.
Arrêter le SRCD et l’enlever du démarrage de la même manière que vous l’avez mis.

Il faut redémarrer le système qui était abîmé. Il doit rebooter normalement.

Surveiller le boot du système et si une option  de vérification apparaît, (appuyer sur la touche Y), faîtes-la.

Après on a un système fonctionnel. On espère juste que la panne ne revienne pas dans les prochains jours...

Cas d’un volume LVM endommagé ! http://kbase.redhat.com/faq/FAQ_96_11472.shtm

Dans un shell lvm :
<code>
# lvm
	# pvsan
	# vgscan
	# lvscan
	# vgchange -ay
	# exit

# e2fsck /dev/datavg/datalv
</code>