VPS bloqué après une mise à jour du kernel : que faire ?

Que faire en premier lorsqu’un VPS ne redémarre plus après une mise à jour du kernel

Un VPS qui ne redémarre plus après une mise à jour du kernel est généralement récupérable en quelques minutes, car la mise à jour n’a pas supprimé le kernel qui fonctionnait la veille. Ubuntu installe un nouveau kernel à côté de l’ancien et modifie uniquement l’entrée que GRUB démarre par défaut. La première étape n’est donc pas une réparation. Sélectionnez l’ancien kernel dans le menu de démarrage, retrouvez une invite de connexion, puis diagnostiquez le problème depuis un système en fonctionnement.

La procédure est différente sur un serveur et sur un ordinateur portable, car aucun clavier n’est connecté et aucun écran n’affiche le kernel panic. SSH ne répondra pas non plus, puisque la machine n’a jamais atteint le stade où sshd démarre. Toutes les opérations ci-dessous passent par la console de votre fournisseur.

Consultez votre propre console avant de modifier quoi que ce soit. Le texte affiché à l’écran détermine la catégorie de panne, et deux serveurs qui « ne redémarrent pas » peuvent nécessiter des corrections opposées.

Comment accéder à la console lorsque SSH ne fonctionne plus ?

Ouvrez le panneau de contrôle de votre fournisseur et recherchez une console. Les appellations courantes sont VNC console, web console, noVNC et serial console. Si les deux options sont disponibles, préférez la serial console : elle fournit du vrai texte que vous pouvez faire défiler et copier, alors qu’une vue VNC n’est qu’une image de l’écran. Repérez cette fonction maintenant, pendant que la machine fonctionne correctement, et vérifiez qu’elle s’ouvre. La chercher pendant une panne vous prive du calme nécessaire. Cette vérification fait partie des dix premières minutes sur un nouveau VPS, au même titre que les règles du pare-feu et les clés SSH.

La plupart des panneaux proposent également un rescue mode ou une recovery image. Ce mode démarre un système minimal depuis le réseau du fournisseur et attache votre disque comme périphérique supplémentaire, de sorte qu’aucun élément présent sur votre disque ne s’exécute. Le rescue mode sert de solution de secours lorsque GRUB est lui-même endommagé. Il permet aussi de copier les données depuis un serveur que vous avez décidé de ne pas sauvegarder.

Vous devrez généralement effectuer un hard reset depuis le panneau pour accéder au menu de démarrage, puisque vous ne pouvez pas exécuter sudo reboot sur une machine à laquelle vous ne pouvez pas vous connecter. Un hard reset revient à couper l’alimentation. Les systèmes de fichiers subissent alors un arrêt incorrect. Prévoyez donc un contrôle du système de fichiers au démarrage suivant.

Comment sélectionner un ancien kernel dans le menu GRUB ?

Surveillez la console dès que vous appuyez sur le bouton de réinitialisation. Appuyez plusieurs fois sur Esc pendant les premières secondes, ou maintenez la touche Shift sur une machine qui démarre en mode BIOS legacy. La fenêtre est courte et le visualiseur de console met souvent une seconde à se connecter. Commencez donc à appuyer tôt et continuez.

Lorsque le menu s’affiche, sélectionnez « Advanced options for Ubuntu ». Ce sous-menu répertorie tous les kernels installés, du plus récent au plus ancien, avec une entrée en mode recovery pour chacun. Sélectionnez la deuxième entrée normale, c’est-à-dire le kernel qui précède le plus récent, puis appuyez sur Entrée. Le mode recovery est différent : il démarre un système minimal en mode single user. Il sert aux opérations de réparation, pas à remettre vos services en ligne.

Si l’ancien kernel démarre, votre serveur fonctionne de nouveau. Vérifiez le kernel utilisé et notez les numéros.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

La sortie de dpkg correspond à la liste des kernels installés. Si elle ne contient qu’une seule ligne, vous n’avez aucun fallback. C’est le premier problème à corriger.

Le menu GRUB ne s’affiche jamais. Que faire ?

Les images cloud sont fournies avec une configuration qui masque le menu. Les images Ubuntu définissent généralement le délai sur 0 dans un fichier situé sous /etc/default/grub.d/. Le dernier kernel démarre donc immédiatement et aucune touche n’est disponible.

Le cas inverse existe aussi : le menu reste affiché et attend une action, ce qui peut faire penser à un blocage. GRUB enregistre un échec du boot et, au démarrage suivant, peut maintenir le menu ouvert jusqu’à ce qu’une personne appuie sur une touche. Sur une machine sans clavier, cette attente ne se termine jamais. Si la console affiche un menu qui n’avance pas, c’est ce qui s’est produit. Sélectionnez une entrée et poursuivez.

Corrigez ces deux problèmes lorsque la machine fonctionne encore. Modifiez /etc/default/grub :

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Appliquez ensuite la modification et vérifiez qu’elle a bien été conservée, car les fichiers situés sous /etc/default/grub.d/ sont lus après /etc/default/grub et peuvent remplacer vos réglages.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" envoie le menu vers la console graphique et le port série. Il s’affiche donc dans le viewer fourni par votre panneau. Les arguments du kernel console= font de même pour les messages de boot qui suivent. Dix secondes de délai à chaque boot constituent un faible prix à payer pour disposer d’un menu réellement accessible à 2 h du matin.

Sur quelle classe de panne suis-je tombé ?

Lisez les vingt dernières lignes avant que la console cesse de défiler. Quatre scénarios couvrent la plupart des problèmes qui surviennent après une mise à jour du kernel.

GRUB ne trouve pas ses propres fichiers. Vous obtenez une invite grub rescue>, ou une erreur concernant une partition ou un fichier inexistant, et aucun message du kernel n’apparaît. Le kernel n’est pas encore intervenu. Ce problème survient après une modification du disque ou des partitions, ou lorsque le bootloader a été écrit sur le mauvais périphérique. Il n’est généralement pas causé par le seul paquet du kernel.

Le kernel démarre, mais ne peut pas monter la racine. Les messages du kernel défilent, puis vous arrivez dans un shell busybox dont l’invite est (initramfs), ou le boot se termine par un panic indiquant que le filesystem root ne peut pas être monté. Le kernel a bien été chargé. L’initramfs, qui est la petite racine temporaire chargée de trouver et de monter votre véritable filesystem root, n’a pas trouvé le disque. Sur Ubuntu, ce shell est généralement précédé d’un message indiquant que le système a cessé d’attendre le périphérique root, avec l’UUID recherché. Copiez cet UUID et comparez-le ensuite à la sortie de blkid.

Un logical volume n’apparaît jamais. Il s’agit de la classe précédente, avec une cause précise. À l’invite (initramfs), exécutez ls /dev/mapper. Si la seule entrée est control, aucun volume LVM (logical volume manager) n’a été activé. Le périphérique root n’existe donc pas encore. Activez les volume groups manuellement :

lvm vgchange -ay
ls /dev/mapper
exit

exit rend la main au script de l’initramfs, qui réessaie de monter le filesystem. Si le système démarre ensuite, le nouvel initramfs ne contient pas les composants LVM. Il faut alors reconstruire cette image, et non modifier le kernel.

Aucun Linux ne démarre. La console affiche des messages du firmware, un shell UEFI (unified extensible firmware interface), un écran vide sans sortie du kernel ou une boucle de redémarrage. La panne survient avant le lancement de Linux. Vérifiez le mode réellement utilisé par votre serveur une fois le système de nouveau disponible, car de nombreuses instances VPS démarrent en mode BIOS legacy et n’utilisent jamais le chemin EFI :

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

Un /boot/efi non monté pendant la mise à niveau est une cause fréquente sur les machines UEFI. Les paquets qui gèrent la partition système EFI écrivent alors dans un répertoire vide ordinaire. Le firmware continue de lancer l’ancienne entrée de boot jusqu’à ce qu’elle ne corresponde plus au contenu du disque.

Un autre scénario ne correspond pas à une panne de boot. Si vous atteignez un shell root indiquant que le système est en mode emergency, le kernel a démarré, puis l’espace utilisateur s’est arrêté. Cela signifie généralement qu’une ligne incorrecte se trouve dans /etc/fstab, ou qu’un filesystem n’a pas réussi son contrôle. Exécutez journalctl -xb dans ce shell et lisez le nom de l’unité qui a échoué.

Le paquet du kernel est-il défectueux ou est-ce l’initramfs ?

Ces deux problèmes se ressemblent depuis la console, mais leur résolution est différente. Démarrez sur l’ancien kernel, puis comparez les fichiers.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

Vous devez avoir un vmlinuz- et un initrd.img- correspondant pour chaque version installée, avec une taille plausible. Un initrd absent, ou nettement plus petit que les autres, indique un échec de la génération de l’initramfs. La cause habituelle est un /boot plein. Les éléments de preuve se trouvent dans les journaux des paquets :

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log indique également quels paquets ont été installés lors des dernières exécutions et à quel moment. Cela permet de déterminer précisément ce qui a changé.

Commencez par libérer de l’espace si /boot est plein. Reconstruisez ensuite l’image pour la version nécessaire, puis actualisez le menu. Reprenez la chaîne de version depuis votre propre sortie ls, car l’emplacement réservé ci-dessous ne correspond pas à une version réelle :

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

Ce dernier ls permet d’effectuer la vérification. Un fichier de taille normale indique que l’image est maintenant présente. Si l’image du kernel elle-même est endommagée, ou si dpkg -l indique un état autre que ii pour le paquet, réinstallez celui-ci :

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Réparer depuis le mode rescue lorsqu’aucun kernel ne démarre

Si toutes les entrées du menu échouent, démarrez l’image rescue du fournisseur et réparez le disque depuis l’extérieur. Votre disque apparaît comme un périphérique non monté. Rien n’y est donc en cours d’exécution et aucun processus ne peut vous bloquer.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

Tester un nouveau kernel sans risquer le prochain démarrage

GRUB peut démarrer une entrée une seule fois, puis revenir à la valeur par défaut choisie. Définissez par défaut un kernel fiable, puis lancez le nouveau pour un seul démarrage. En cas d’échec, un hard reset depuis le panel vous ramène au bon kernel, sans devoir intervenir dans la console au bon moment.

Définissez GRUB_DEFAULT=saved dans /etc/default/grub, exécutez sudo update-grub, puis affichez les titres des entrées afin de pouvoir en désigner une exactement :

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list doit afficher le titre choisi sous la forme saved_entry. Cette sortie confirme que le mécanisme fonctionne, car l’enregistrement nécessite un /boot/grub/grubenv accessible en écriture, ce qui n’est pas toujours le cas selon la disposition. L’entrée 0 correspond à la première entrée du menu, c’est-à-dire au kernel le plus récent. Les titres sont plus fiables que les numéros ici, car les numéros changent chaque fois qu’un kernel est installé ou supprimé.

Pourquoi autoremove est risqué sur un serveur sans interface locale

APT conserve une liste des paquets de noyau qu’il ne doit pas supprimer automatiquement. Affichez la vôtre :

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

Ce fichier est régénéré chaque fois que les paquets de noyau changent. Il protège le noyau en cours d’exécution ainsi que les plus récents. Le piège tient au moment où vous lancez la commande. Exécutez sudo apt autoremove --purge juste après avoir redémarré sur un nouveau noyau : la liste des noyaux protégés a déjà été mise à jour, et l’ancien noyau sur lequel vous comptiez n’est plus protégé. Sur une machine équipée d’un clavier, c’est un désagrément. Sur un serveur sans interface locale, c’est la différence entre sélectionner une entrée dans un menu et monter votre disque depuis une image de secours.

Conservez au moins deux noyaux, et trois lorsque /boot en a la capacité. Supprimez les anciens noyaux par leur nom après avoir vérifié uname -r, afin de ne jamais supprimer celui que vous utilisez :

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

Réexécutez ensuite la dernière commande. Passer de trois à deux noyaux correspond à un nettoyage. Passer à un seul noyau annonce une interruption de service au prochain redémarrage.

Prendre un snapshot avant la mise à niveau

Un snapshot pris avant apt upgrade est le seul moyen de récupération qui ne dépend pas du démarrage d’un système. Sa restauration remet le disque dans l’état où l’ancien kernel était la version par défaut. Vous pouvez ensuite réessayer la mise à niveau avec la console déjà ouverte. Les snapshots d’une machine en fonctionnement sont cohérents après incident. Ils capturent le disque comme si l’alimentation avait été coupée. Arrêtez donc d’abord le serveur lorsque votre fournisseur prend en charge les snapshots hors ligne. Un snapshot n’est pas non plus une sauvegarde, car il se trouve généralement sur la même infrastructure que le volume copié. Comprendre la différence entre les snapshots de VPS et les vraies sauvegardes permet de déterminer lequel vous sauvera lorsque la panne dépasse le simple problème de kernel.

Cela est particulièrement important lors d’une mise à niveau de version. Le kernel, les outils initramfs, le bootloader et la configuration GRUB sont alors modifiés en une seule opération. Prenez le snapshot immédiatement avant de commencer une mise à niveau d’Ubuntu 24.04 vers 26.04, et non la veille au soir. Le point de restauration correspondra ainsi à la machine que vous êtes sur le point de modifier. Si cette mise à niveau n’est pas encore proposée sur votre serveur, la cause est liée au calendrier et non à une configuration défectueuse. En effet, une mise à niveau d’une version LTS vers une autre ne devient disponible qu’à la première version intermédiaire, 26.04.1.

Traitement des paquets du noyau par unattended-upgrades

Les mises à jour unattended-upgrades d’Ubuntu installent les mises à jour de sécurité sans demander de confirmation. Les paquets du noyau arrivent par le security pocket, comme les autres paquets. Deux conséquences en découlent.

Premièrement, le nouveau noyau est installé, mais il n’est pas en cours d’exécution. Un noyau ne prend effet qu’au démarrage. Le fichier /var/run/reboot-required apparaît, et /var/run/reboot-required.pkgs indique ce qui a demandé le redémarrage. Cependant, rien ne redémarre tant que vous n’avez pas activé Unattended-Upgrade::Automatic-Reboot dans /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

Deuxièmement, ce délai masque la cause. Un serveur peut installer un noyau en mars, puis redémarrer en juin pour une raison totalement différente et ne plus démarrer correctement. La modification qui a empêché le démarrage date alors de trois mois. Rien de ce que vous avez fait ce jour-là n’explique donc la panne. /var/log/apt/history.log permet de trouver l’exécution qui a installé le noyau avec lequel le serveur échoue maintenant.

Redémarrez volontairement, le jour que vous avez choisi, avec la console déjà ouverte. Cette simple habitude transforme une panne inexpliquée en une sélection de deux minutes dans un menu. Si vous voulez automatiser les installations sans subir de redémarrage imprévu, laissez les installations automatiques activées et les redémarrages automatiques désactivés. Consultez la configuration de unattended-upgrades sur Ubuntu pour connaître les paramètres exacts. Bloquer les paquets du noyau avec sudo apt-mark hold linux-image-generic les empêche complètement de s’installer, ce qui bloque aussi les correctifs de sécurité du noyau. Considérez donc cette option comme un compromis que vous avez choisi, et non comme une mesure de sécurité.

FAQ

Comment démarrer sur un ancien noyau sur un VPS sans clavier ?

Ouvrez la console du fournisseur (VNC ou série), puis déclenchez une réinitialisation matérielle depuis le panneau de contrôle, car vous ne pouvez pas vous connecter pour redémarrer proprement. Au redémarrage de la machine, appuyez plusieurs fois sur Esc ou maintenez Shift lors d’un démarrage avec un BIOS ancien, afin de conserver le menu GRUB à l’écran. Sélectionnez « Advanced options for Ubuntu », puis choisissez l’entrée située juste sous le noyau le plus récent. Une fois l’invite de connexion affichée, exécutez uname -r pour confirmer le noyau utilisé et dpkg -l 'linux-image-*' pour voir les autres noyaux installés. Effectuez le diagnostic uniquement une fois le système de nouveau opérationnel.

Pourquoi mon VPS n’affiche-t-il aucun menu GRUB ?

Les images cloud définissent souvent le délai d’attente de GRUB sur 0 dans un fichier situé sous /etc/default/grub.d/. Le noyau le plus récent démarre alors sans laisser le temps d’intervenir. Définissez GRUB_TIMEOUT=10 et GRUB_TIMEOUT_STYLE=menu dans /etc/default/grub, ajoutez GRUB_TERMINAL="console serial" afin que le menu soit également accessible sur une console série, puis exécutez sudo update-grub. Vérifiez avec grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, car les fichiers de ce répertoire sont lus après le fichier principal et peuvent remplacer vos modifications.

Dois-je supprimer les anciens noyaux pour libérer de l’espace dans /boot ?

Supprimez les plus anciens et conservez-en au moins deux. Un /boot plein constitue un mode de panne distinct : la génération de l’initramfs échoue alors et vous vous retrouvez avec un noyau sans image fonctionnelle. Purgez les noyaux en indiquant le nom exact du paquet après avoir vérifié uname -r, afin que le noyau en cours d’exécution ne soit jamais sélectionné. Évitez d’exécuter sudo apt autoremove --purge sans autre précaution sur une machine sans accès clavier, car la liste des noyaux protégés est régénérée à chaque changement de noyau et une exécution au mauvais moment peut vous laisser avec un seul noyau et aucune entrée de secours dans le menu.

Les mises à niveau automatiques peuvent-elles empêcher le démarrage ?

Elles peuvent installer un noyau qui ne démarrera pas ensuite, mais elles ne redémarrent pas la machine sauf si Unattended-Upgrade::Automatic-Reboot est défini sur true dans /etc/apt/apt.conf.d/50unattended-upgrades. Le scénario habituel est une panne différée : le noyau est installé lors d’une exécution automatique, /var/run/reboot-required apparaît, puis le problème ne se manifeste qu’au redémarrage suivant, plusieurs semaines plus tard. Redémarrez volontairement avec la console déjà ouverte et consultez /var/log/apt/history.log pour déterminer quelle exécution a installé le noyau utilisé pour démarrer la machine.