Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH

J’ai lamentablement fait planter le serveur en voulant mettre le kernel à jour…

Heureusement, il existe le mode rescue chez OVH qui permet d’installer un linux provisoire sur le serveur et d’initier une connexion SSH pour que l’on puisse réparer le système.

Si jamais cela vous arrive, voici la marche à suivre.

Passage en mode rescue depuis le manager OVH

1. Aller sur le manager OVH > Dedicated > Infrastructure > clic sur votre serveur > clic sur l’onglet Server Status.

Vous obtenez quelque chose comme :

System (OS) : Debian 6.0 oldstable LTS (Squeeze)
Boot :   hd (Boot from hard drive (no netboot)) 

2. Nous allons temporairement booter en mode rescue donc cliquez sur Modifier. Vous obtenez cet écran :

Sélectionnez Boot on rescue mode puis rescue-pro. On vous demande de confirmer :

3. Confirmez. La fenêtre se ferme. Dans le manager, en haut à droite, cliquez sur Restart pour redémarrer votre serveur.

4. Armez-vous de patience : OVH installe un linux temporaire sur le serveur, cela prend du temps.

Quand l’installation du mode rescue est terminée, vous recevez un email intitulé “Paramètres d’accès au mode RESCUE” qui contient les informations nécessaires pour se connecter en SSH au serveur :

Bonjour,

Votre serveur a redémarré en mode ‘Rescue’ ; cela signifie qu’un
Linux/BSD est lancé sur votre serveur via le réseau. Il ne s’agit pas
du système qui est normalement installé sur votre serveur, aucune
de vos partitions n’est d’ailleurs montée.

Une interface web est disponible pour vous permettre d’effectuer un
diagnostique de votre serveur (disque dur, raid, ram, CPU) et de
parcourir l’arborescence de votre système de fichiers:
http://xxx.xxx.xxx.xxx:81
– nom d’utilisateur : root
– mot de passe : XXXXXX

Vous pouvez également vous connecter en SSH à votre serveur
avec les paramètres suivants:
– user : root
– mot de passe : XXXXXXX

Vous pouvez dès à présent effectuer les opérations de maintenance
nécessaires au rétablissement de votre serveur, à titre d’exemple,
vous pouvez:
– vérifier et mettre à jour vos fichiers de configuration réseau,
– vérifier et éventuellement désactiver votre firewall,
– vérifier et mettre à jour votre LILO
– procéder à la vérification manuelle de votre système de fichiers,
– effectuer une sauvegarde ou une restauration de données,
– etc.

Connexion en SSH et chroot du système

5. Nous allons utiliser SSH exclusivement. On se loggue avec :

ssh root@IP

et on rentre le mot de passe donné dans le mail. On obtient ceci :

Linux rescue.ovh.net 3.10.23-xxxx-std-ipv6-64-rescue #1 SMP Tue Mar 18 15:06:38 CET 2014 x86_64

Nous sommes bien dans le mode rescue.

6. On commence par lister nos partitions :

fdisk -l

Cela nous permet de savoir quel est le nom du disque dur à monter. Dans mon cas, il n’y en a qu’un, c’est /dev/sda et la partition système se trouve sur /dev/sda1.

7. On monte le disque :

mount /dev/sda1 /mnt/

A ce stade, il est en lecture seule donc il faut utiliser la commande chroot :

chroot /mnt/

Mise à jour du kernel

8. Je supprime les fichiers du kernel que j’avais tenté d’installer et je remets les anciens. Heureusement, je les avais sauvegardé dans un répertoire sous /boot.

Toujours penser à faire des sauvegardes ou à placer une copie des fichiers sensibles dans un répertoire.

Mes fichiers kernel se trouvent dans /boot/3.8.13, je les remets dans /boot

cp /boot/3.8.13/* /boot

9. Je tente un premier update-grub2 :

update-grub2

qui me renvoie :

Generating grub.cfg ...
Found linux image: /boot/bzImage-3.8.13-xxxx-grs-ipv6-64
grep: /proc/mounts: No such file or directory
Cannot find list of partitions!  (Try mounting /sys.)
done

puis :

grep: /proc/mounts: No such file or directory
  /proc/mounts: _get_sysfs_dir fopen failed: No such file or directory
  /proc/devices: fopen failed: No such file or directory
  Failed to set up list of device-mapper major numbers
  /proc/devices: fopen failed: No such file or directory
  Failed to create lvm type filter
warning: failed to read mtab
umount: /var/lib/os-prober/mount: not mounted
warning: failed to read mtab
umount: /var/lib/os-prober/mount: not mounted
done

D’autres répertoires importants sont donc à chrooter également :

mount sysfs /sys -t sysfs
mount -o bind /dev /dev
mount -o bind /dev/pts /dev/pts
mount -o bind /tmp /tmp

On relance update-grub2. Résultats :

Generating grub.cfg ...
Found linux image: /boot/bzImage-3.8.13-xxxx-grs-ipv6-64
  No volume groups found
umount: /var/lib/os-prober/mount: not mounted
done

et, par acquis de conscience :

grub-mkconfig

qui renvoie :

Generating grub.cfg ...
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function load_video {
  insmod vbe
  insmod vga
  insmod video_bochs
  insmod video_cirrus
}

insmod part_msdos
insmod ext2
set root='(/dev/sda,msdos1)'
search --no-floppy --fs-uuid --set=root acb31c4f-318c-4733-8770-b58cd94da69b
if loadfont /usr/share/grub/unicode.pf2 ; then
  set gfxmode=640x480
  load_video
  insmod gfxterm
  insmod part_msdos
  insmod ext2
  set root='(/dev/sda,msdos1)'
  search --no-floppy --fs-uuid --set=root acb31c4f-318c-4733-8770-b58cd94da69b
  set locale_dir=($root)/boot/grub/locale
  set lang=fr_FR
  insmod gettext
fi
terminal_output gfxterm
set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/06_OVHkernel ###
Found linux image: /boot/bzImage-3.8.13-xxxx-grs-ipv6-64
menuentry "Debian GNU/Linux, OVH kernel 3.8.13-xxxx-grs-ipv6-64" {
	insmod part_msdos
	insmod ext2
	set root='(/dev/sda,msdos1)'
	search --no-floppy --fs-uuid --set=root acb31c4f-318c-4733-8770-b58cd94da69b
	linux	/boot/bzImage-3.8.13-xxxx-grs-ipv6-64 root=/dev/sda1 ro  quiet
}
### END /etc/grub.d/06_OVHkernel ###

### BEGIN /etc/grub.d/10_linux ###
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
  No volume groups found
umount: /var/lib/os-prober/mount: not mounted
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
done

Pour l’erreur “No volume groups found” avec os-prober, c’est normal. C’est un programme qui détecte les autres systèmes d’exploitation sur la machine.

Comme c’est un serveur, il n’y a qu’un seul OS donc aucune information à remonter.

Redémarrage du serveur sur le disque dur

10. Il ne vous reste plus qu’à rebooter le serveur. Le soft reboot (/sbin/reboot ou reboot) via SSH ne fonctionnant pas, j’ai redémarré le serveur via le manager OVH en sélectionnant Boot on the hard-disk.

Après quelques (longues) minutes d’attente, le serveur est revenu à lui. Tous les services étaient alors fonctionnels.

Ouf, merci le mode rescue !

Articles conseillés :

• Bash : réparer les tables MySQL en cas de crash
• Créer une clé SSH pour ouvrir une session distante sans mot de passe
• Migration de serveur : bonjour Kimsufi 750G
• MySQL : résoudre l’erreur “Table is marked as crashed and last (automatic?) repair failed”
• Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
• Résoudre le non-redémarrage du serveur MySQL : le manque d’espace sur une partition disque