Récupérer un serveur OVH/Kimsufi en mode rescue après un kernel cassé

Un serveur dédié qui ne redémarre plus après une mise à jour de kernel, c’est un grand classique. On lance un reboot confiant, on attend quelques minutes, puis rien. SSH ne répond plus. Les services sont morts. Le monitoring hurle. Ambiance feutrée.

Heureusement, OVHcloud propose un mode rescue pour les serveurs dédiés, Kimsufi et So you Start. Il démarre la machine sur un système temporaire, indépendant du système installé sur vos disques. Vous pouvez alors monter vos partitions, récupérer vos données, corriger une configuration cassée ou réparer le démarrage.

Ce guide couvre surtout le cas d’un serveur Debian qui ne démarre plus après :

• une mise à jour de noyau ratée ;
• un initramfs absent ou corrompu ;
• un GRUB mal généré ;
• une erreur dans /etc/fstab ;
• un pare-feu qui bloque SSH ;
• une mise à niveau Debian interrompue ;
• un disque ou un RAID à diagnostiquer ;
• une mauvaise manipulation dans /boot.

L’objectif est simple : reprendre la main sans réinstaller le serveur. Et, si la réparation échoue, récupérer les données proprement avant de reconstruire.

Avant de réparer : sauvegarder ce qui peut l’être

Avant de toucher au kernel, à GRUB ou aux partitions, sauvegardez les données importantes. Le mode rescue sert à réparer, oui. Mais il sert aussi à sauver les meubles avant de jouer au chirurgien système.

Depuis le rescue, vous pourrez copier vos données vers un autre serveur avec rsync, scp ou sftp. Priorisez :

• les sites web, souvent dans /home, /var/www ou /srv ;
• les bases MySQL/MariaDB si elles ne sont pas déjà sauvegardées ;
• les configurations dans /etc ;
• les certificats TLS ;
• les clés SSH ;
• les crons ;
• les fichiers applicatifs spécifiques.

Exemple de sauvegarde vers un autre serveur :

rsync -aHAXx --numeric-ids --info=progress2 /mnt/home/ backup@example.net:/backups/serveur/home/
rsync -aHAXx --numeric-ids --info=progress2 /mnt/etc/ backup@example.net:/backups/serveur/etc/Langage du code : JavaScript (javascript)

L’option -x évite de traverser d’autres systèmes de fichiers montés. C’est souvent souhaitable pendant une récupération.

Si vous hébergez WordPress ou WooCommerce, pensez aussi à sauvegarder les uploads et la base de données. Un noyau se réinstalle. Une base client perdue, beaucoup moins.

Étape 1 : passer le serveur en mode rescue OVHcloud

Dans l’espace client OVHcloud, ouvrez votre serveur dédié :

• Bare Metal Cloud ;
• Serveurs dédiés ;
• sélectionnez le serveur concerné ;
• dans les informations générales, modifiez le réglage Boot ou Netboot ;
• choisissez Booter en mode rescue ;
• sélectionnez le rescue Linux, souvent appelé Customer rescue system ;
• validez, puis redémarrez le serveur.

L’interface OVHcloud évolue régulièrement, donc les libellés exacts peuvent changer. Le principe, lui, reste le même : on change le Netboot, puis on redémarre la machine.

Après quelques minutes, OVHcloud envoie les accès au mode rescue par e-mail. Ces informations sont aussi disponibles dans l’espace client, dans les e-mails de service.

Les anciennes captures ci-dessous montrent l’ancien manager OVH. Elles restent utiles pour comprendre le principe, mais l’interface actuelle se trouve désormais dans la section Bare Metal Cloud.

Étape 2 : se connecter en SSH au mode rescue

Connectez-vous avec l’adresse IP du serveur et les identifiants temporaires fournis par OVHcloud :

ssh root@ADRESSE_IP_DU_SERVEURLangage du code : CSS (css)

Si votre client SSH affiche une alerte d’empreinte, c’est normal : le système rescue utilise son propre serveur SSH temporaire. Vous pouvez supprimer l’ancienne empreinte liée à cette IP :

ssh-keygen -R ADRESSE_IP_DU_SERVEUR

Puis reconnectez-vous :

ssh root@ADRESSE_IP_DU_SERVEURLangage du code : CSS (css)

Vous devez arriver sur un shell root du système rescue, pas sur votre Debian installée. C’est précisément ce que l’on veut.

Étape 3 : identifier les disques, partitions, RAID et LVM

Ne montez pas /dev/sda1 au hasard. Les serveurs récents utilisent souvent des disques NVMe, du RAID logiciel, du LVM, une partition EFI ou une séparation entre /, /boot et /home.

Commencez par afficher la structure des disques :

lsblk -f
blkid
fdisk -l

Exemples de noms fréquents :

Type	Exemple	Commentaire
Disque SATA/SAS	/dev/sda	Ancien nommage classique.
Partition SATA/SAS	/dev/sda1	Partition directe sur disque.
Disque NVMe	/dev/nvme0n1	Fréquent sur serveurs récents.
Partition NVMe	/dev/nvme0n1p3	Notez le p avant le numéro.
RAID logiciel	/dev/md3	À monter plutôt que la partition physique.
LVM	/dev/mapper/vg-root	Volume logique à activer avant montage.

Si vous voyez des volumes RAID, vérifiez leur état :

cat /proc/mdstat
mdadm --detail /dev/md0 2>/dev/null
mdadm --detail /dev/md1 2>/dev/null
mdadm --detail /dev/md2 2>/dev/null
mdadm --detail /dev/md3 2>/dev/nullLangage du code : JavaScript (javascript)

Si vous utilisez LVM, activez les volumes :

vgscan
vgchange -ay
lvs

Le but est d’identifier la vraie racine du système, c’est-à-dire la partition ou le volume qui contient /etc, /bin, /usr, /var et /boot, ou au moins les points de montage permettant d’y accéder.

Étape 4 : monter le système installé

Créez un point de montage si nécessaire :

mkdir -p /mnt

Montez la partition racine. Adaptez évidemment le périphérique à votre serveur :

mount /dev/md3 /mnt

Ou, sans RAID :

mount /dev/nvme0n1p3 /mnt

Vérifiez que vous êtes bien sur le système installé :

ls /mnt
cat /mnt/etc/os-release

Si vous avez une partition /boot séparée, montez-la :

mount /dev/md2 /mnt/boot

Si le serveur démarre en UEFI avec une partition EFI, montez-la aussi :

mount /dev/nvme0n1p1 /mnt/boot/efi

Si /home, /var ou d’autres points de montage sont séparés, montez-les également selon votre /mnt/etc/fstab :

cat /mnt/etc/fstab

Exemple :

mount /dev/md4 /mnt/home
mount /dev/md5 /mnt/varLangage du code : JavaScript (javascript)

Étape 5 : préparer un chroot propre

Pour réparer le système installé comme si vous aviez démarré dessus, il faut entrer dans un chroot. Mais avant, montez les pseudo-systèmes indispensables :

mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount -t proc proc /mnt/proc
mount -t sysfs sysfs /mnt/sys
mount -t tmpfs tmpfs /mnt/run

Copiez temporairement la résolution DNS du rescue si vous devez utiliser apt dans le chroot :

cp /etc/resolv.conf /mnt/etc/resolv.conf

Entrez ensuite dans le système installé :

chroot /mnt /bin/bash

Chargez un environnement minimal propre :

source /etc/profile
export PS1="(rescue-chroot) ${PS1}"Langage du code : JavaScript (javascript)

Vous êtes maintenant dans votre Debian installée, mais démarrée depuis le rescue. C’est là que la réparation sérieuse commence.

Étape 6 : diagnostiquer le problème de démarrage

Avant de tout réinstaller, regardez ce qui cloche. Commencez par identifier la version Debian et les noyaux présents :

cat /etc/os-release
dpkg -l 'linux-image*' | grep '^ii'
ls -lh /bootLangage du code : JavaScript (javascript)

Vérifiez ensuite les logs du précédent boot si systemd-journald les a conservés :

journalctl -xb -1 --no-pager
journalctl -p err -b -1 --no-pager

Si les journaux persistants ne sont pas activés, regardez les logs classiques :

ls -lh /var/log
grep -R "error\|failed\|panic\|grub\|initramfs" /var/log 2>/dev/null | tail -n 100Langage du code : JavaScript (javascript)

Vérifiez aussi fstab. Une UUID incorrecte peut bloquer le boot ou envoyer le serveur dans un mode dégradé :

cat /etc/fstab
blkid

Si le problème vient clairement du kernel ou de GRUB, passez aux étapes suivantes.

Étape 7 : réparer APT avant de réparer le kernel

Après une mise à jour interrompue, APT et dpkg peuvent rester dans un état bancal. Réparez d’abord la base des paquets :

dpkg --configure -a
apt update
apt -f install

Si vous avez des dépôts tiers cassés, commentez-les temporairement :

ls /etc/apt/sources.list.d/
nano /etc/apt/sources.list
nano /etc/apt/sources.list.d/fichier-problematique.listLangage du code : PHP (php)

Sur un serveur de production, restez sobre : moins il y a de dépôts exotiques, moins le prochain reboot ressemble à un pari sportif.

Étape 8 : réinstaller un noyau Debian propre

Sur Debian moderne, privilégiez les paquets de noyau fournis par Debian, par exemple linux-image-amd64. Les anciens noyaux OVH custom ont eu leur époque, mais ce n’est plus l’approche à recommander pour un guide maintenable.

Installez ou réinstallez le noyau générique Debian :

apt install --reinstall linux-image-amd64

Si les headers sont utiles sur votre serveur, par exemple pour certains modules DKMS :

apt install --reinstall linux-headers-amd64

Vérifiez que /boot contient bien un noyau et un initrd :

ls -lh /boot/vmlinuz-* /boot/initrd.img-* 2>/dev/nullLangage du code : JavaScript (javascript)

S’il manque l’initramfs, régénérez-le :

update-initramfs -u -k all

Pour régénérer uniquement une version précise :

update-initramfs -u -k VERSION_DU_KERNEL

Vous pouvez lister les versions disponibles ainsi :

ls /lib/modules

Étape 9 : régénérer GRUB

GRUB doit connaître les noyaux disponibles et les bons UUID. Régénérez sa configuration :

update-grub

Sur Debian, update-grub est un raccourci qui exécute grub-mkconfig -o /boot/grub/grub.cfg. C’est la commande standard pour régénérer la configuration GRUB. :contentReference[oaicite:2]{index=2}

Si GRUB lui-même doit être réinstallé, identifiez d’abord le mode de démarrage : BIOS ou UEFI.

Pour un boot BIOS classique :

grub-install /dev/sda
update-grub

Sur serveur NVMe :

grub-install /dev/nvme0n1
update-grub

En RAID logiciel avec deux disques, installez GRUB sur les deux disques physiques, pas sur /dev/mdX :

grub-install /dev/sda
grub-install /dev/sdb
update-grub

Ou avec deux NVMe :

grub-install /dev/nvme0n1
grub-install /dev/nvme1n1
update-grub

Pour un boot UEFI, assurez-vous que la partition EFI est montée sur /boot/efi, puis utilisez la cible adaptée :

mount | grep efi
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck
update-grubLangage du code : JavaScript (javascript)

Si vous n’êtes pas certain du mode de boot, ne forcez pas une commande au hasard. Vérifiez la table de partitions, la présence de /boot/efi, et les indications de l’espace client OVHcloud.

Étape 10 : corriger un fstab cassé

Un mauvais /etc/fstab peut empêcher le démarrage ou bloquer le serveur pendant de longues minutes. Comparez les UUID déclarées avec celles détectées :

cat /etc/fstab
blkid

Si une partition non essentielle bloque le boot, ajoutez temporairement nofail dans ses options :

UUID=xxxx-xxxx /mnt/data ext4 defaults,nofail 0 2

Pour une partition système, corrigez plutôt l’UUID ou le point de montage. Le nofail n’est pas une baguette magique. Sur /, il ne sauvera pas grand-chose.

Étape 11 : réparer un firewall qui bloque SSH

Le serveur démarre peut-être correctement, mais un pare-feu bloque SSH. Depuis le chroot, inspectez les règles persistantes selon votre stack.

Pour nftables :

systemctl is-enabled nftables 2>/dev/null
cat /etc/nftables.confLangage du code : JavaScript (javascript)

Pour iptables-persistent :

ls -lh /etc/iptables/
cat /etc/iptables/rules.v4 2>/dev/null
cat /etc/iptables/rules.v6 2>/dev/nullLangage du code : JavaScript (javascript)

Pour UFW :

grep -R "22\|ssh" /etc/ufw 2>/dev/null
cat /etc/ufw/ufw.confLangage du code : JavaScript (javascript)

Si vous devez désactiver temporairement un pare-feu au prochain démarrage :

systemctl disable nftables 2>/dev/null
systemctl disable netfilter-persistent 2>/dev/null
systemctl disable ufw 2>/dev/nullLangage du code : JavaScript (javascript)

Ensuite, dès que SSH revient, reconnectez-vous et remettez un pare-feu propre. Un serveur sans firewall, c’est une porte ouverte avec le paillasson “root me”. Très convivial, mais pas longtemps.

Étape 12 : vérifier SSH avant de redémarrer

Assurez-vous que le serveur SSH est installé et activé :

apt install --reinstall openssh-server
systemctl enable ssh

Vérifiez la configuration :

sshd -t

Si la commande ne renvoie rien, la syntaxe est correcte. Si elle affiche une erreur, corrigez /etc/ssh/sshd_config avant de redémarrer.

Vérifiez aussi que votre clé SSH est toujours présente si vous n’utilisez pas l’authentification par mot de passe :

ls -la /root/.ssh
cat /root/.ssh/authorized_keys

Si vous devez réinstaller une clé publique, ajoutez-la dans le bon fichier :

mkdir -p /root/.ssh
chmod 700 /root/.ssh
nano /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

Étape 13 : sortir proprement du chroot

Quand les réparations sont terminées, sortez du chroot :

exitLangage du code : PHP (php)

Démontez ensuite proprement les pseudo-systèmes et partitions :

umount /mnt/run
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev/pts
umount /mnt/dev

Démontez les partitions séparées si vous en avez monté :

umount /mnt/boot/efi 2>/dev/null
umount /mnt/boot 2>/dev/null
umount /mnt/home 2>/dev/null
umount /mnt/var 2>/dev/null
umount /mntLangage du code : JavaScript (javascript)

Si un démontage échoue, cherchez ce qui utilise encore le point de montage :

lsof +f -- /mnt 2>/dev/null
fuser -vm /mntLangage du code : JavaScript (javascript)

Étape 14 : repasser le Netboot sur le disque dur

Retournez dans l’espace client OVHcloud, puis remettez le mode de démarrage sur :

• Booter sur le disque dur ;
• ou l’équivalent dans l’interface actuelle.

OVHcloud rappelle qu’il faut remettre le Netboot en mode disque avant de redémarrer, sinon le serveur repartira simplement en rescue. C’est bête, mais c’est précisément le genre de bêtise qu’on fait à 2 h du matin. :contentReference[oaicite:3]{index=3}

Redémarrez ensuite :

reboot

Surveillez le retour SSH depuis votre machine locale :

watch -n 5 'nc -zv ADRESSE_IP_DU_SERVEUR 22'Langage du code : JavaScript (javascript)

Ou plus simplement :

ssh root@ADRESSE_IP_DU_SERVEURLangage du code : CSS (css)

Après le redémarrage : vérifier que tout est sain

Une fois le serveur revenu, vérifiez le kernel actif :

uname -a

Contrôlez les services en échec :

systemctl --failed

Inspectez les erreurs du boot courant :

journalctl -p err -b --no-pager

Vérifiez l’espace disque, surtout /boot :

df -h
dpkg -l 'linux-image*' | grep '^ii'Langage du code : JavaScript (javascript)

Si /boot est plein, purgez les anciens noyaux proprement. Ne supprimez pas les fichiers au hasard dans /boot comme un sanglier dans un datacenter.

apt autoremove --purge

Cas fréquent : “VFS unable to mount root fs”

Ce message indique souvent que le kernel ne parvient pas à monter la partition racine. Causes fréquentes :

• initramfs manquant ;
• mauvaise UUID dans GRUB ou fstab ;
• module disque absent ;
• RAID ou LVM non pris en charge dans l’initramfs ;
• noyau installé mais image initrd absente ;
• partition /boot non montée au moment de la génération.

Depuis le chroot, les commandes utiles sont :

ls -lh /boot
ls /lib/modules
blkid
cat /etc/fstab
update-initramfs -u -k all
update-grub

Si vous utilisez RAID ou LVM, vérifiez aussi :

cat /etc/mdadm/mdadm.conf 2>/dev/null
cat /etc/initramfs-tools/conf.d/resume 2>/dev/null
lvs
cat /proc/mdstatLangage du code : JavaScript (javascript)

Cas fréquent : serveur inaccessible après modification réseau

Si le serveur démarre mais reste inaccessible, inspectez la configuration réseau depuis le rescue. Selon la version de Debian, vous pouvez avoir ifupdown, systemd-networkd, NetworkManager ou une configuration spécifique à l’hébergeur.

Dans le chroot :

ip address
ip route
cat /etc/network/interfaces 2>/dev/null
networkctl list 2>/dev/null
ls /etc/systemd/network/ 2>/dev/nullLangage du code : JavaScript (javascript)

Vérifiez notamment :

• l’adresse IP principale ;
• la passerelle ;
• le masque réseau ;
• la configuration IPv6 ;
• les règles firewall ;
• les services réseau activés au démarrage.

Sur OVHcloud, les règles réseau peuvent varier selon les gammes, les Additional IP, le vRack ou l’agrégation de liens. Ne réutilisez pas aveuglément une configuration d’un autre serveur.

Cas fréquent : disque ou RAID dégradé

Si le serveur plante pendant ou après un reboot, ne blâmez pas toujours le kernel. Un disque mourant sait très bien imiter un problème logiciel.

Depuis le mode rescue, vérifiez les disques :

lsblk
cat /proc/mdstat
smartctl -a /dev/sda
smartctl -a /dev/sdb

Sur NVMe :

smartctl -a /dev/nvme0n1
smartctl -a /dev/nvme1n1

Installez smartmontools dans le rescue si nécessaire :

apt update
apt install smartmontools

Si le RAID est dégradé, sauvegardez d’abord, puis suivez la procédure OVHcloud adaptée au remplacement de disque et au type de RAID. Ne lancez pas de reconstruction sans comprendre quel disque est sain.

Checklist rapide de récupération

• Passer le serveur en mode rescue depuis le Netboot OVHcloud.
• Se connecter en SSH au rescue.
• Sauvegarder les données importantes.
• Identifier les disques avec lsblk -f, blkid et fdisk -l.
• Activer RAID/LVM si nécessaire.
• Monter la racine dans /mnt.
• Monter /boot, /boot/efi, /home ou /var si séparés.
• Bind mount /dev, /dev/pts, /proc, /sys et /run.
• Entrer dans le chroot.
• Réparer dpkg/APT.
• Réinstaller le kernel Debian.
• Régénérer initramfs.
• Régénérer ou réinstaller GRUB.
• Vérifier SSH et firewall.
• Sortir du chroot et démonter proprement.
• Remettre le Netboot sur disque dur.
• Redémarrer et vérifier les logs.

FAQ

Le mode rescue OVHcloud efface-t-il mes données ?

Non. Le mode rescue démarre un système temporaire en mémoire ou via le réseau. Vos partitions ne sont pas montées automatiquement comme système principal. En revanche, une mauvaise commande peut toujours effacer des données. Sauvegardez avant de réparer.

Pourquoi mon serveur redémarre encore en rescue ?

Parce que le Netboot est probablement resté configuré sur le mode rescue. Retournez dans l’espace client OVHcloud, remettez le boot sur le disque dur, validez, puis redémarrez.

Puis-je réparer Debian sans chroot ?

Vous pouvez copier des fichiers sans chroot, mais les réparations sérieuses comme apt, update-initramfs, update-grub ou grub-install nécessitent généralement un chroot propre.

Quelle partition dois-je monter dans /mnt ?

Montez la partition ou le volume qui contient la racine du système Debian. Sur un RAID logiciel, il s’agit souvent d’un volume /dev/mdX. Sur LVM, ce sera plutôt un volume dans /dev/mapper/. Vérifiez avec lsblk -f, blkid et /etc/fstab.

Faut-il utiliser les anciens kernels OVH ?

Pour une Debian moderne, utilisez plutôt les noyaux Debian standards, comme linux-image-amd64. Les anciens noyaux OVH custom appartiennent surtout aux installations historiques.

Que faire si GRUB ne trouve aucun système ?

Vérifiez que la partition racine, /boot et éventuellement /boot/efi sont bien montées avant d’exécuter update-grub. Ensuite, réinstallez GRUB sur le bon disque, pas sur une partition au hasard.

Articles connexes sur SkyMinds

• Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
• Créer une clé SSH pour ouvrir une session distante sans mot de passe
• Serveur dédié : choix du système d’exploitation, SSH et commandes bash
• SSH : corriger l’erreur “Missing privilege separation directory: /run/sshd”
• MySQL : résoudre l’erreur “Table is marked as crashed”
• Migration de serveur : bonjour Kimsufi 750G

Conclusion

Le mode rescue OVHcloud est l’outil à connaître quand un serveur dédié ne démarre plus. Il permet de reprendre la main, monter le système, entrer en chroot, réparer le noyau, régénérer initramfs, restaurer GRUB, corriger SSH ou récupérer les données.

La méthode moderne tient en quelques principes : identifier les disques avant de monter, sauvegarder avant de modifier, monter tous les pseudo-systèmes avant le chroot, utiliser les noyaux Debian standards, puis remettre le Netboot sur disque avant le redémarrage final.

Un serveur qui plante après une mise à jour kernel n’est pas forcément perdu. Mais il mérite une intervention calme, méthodique, et un peu moins optimiste que “ça devrait redémarrer tout seul”. L’optimisme, c’est très bien. Les sauvegardes, c’est mieux.

Sources

• OVHcloud — Activer et utiliser le mode rescue
• OVHcloud Help — Mode rescue sur un serveur dédié
• Debian — Recovering a Broken System
• Debian Manpages — update-grub

Report a typo