VPS ne démarre plus après mise à jour du noyau

Que faire en premier lorsqu'un VPS ne démarre plus après une mise à jour du noyau

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

Réparer cela sur un serveur diffère de la réparation d'un ordinateur portable, car aucun clavier n'est branché et aucun écran n'affiche le panic. SSH ne répondra pas non plus, puisque la machine n'a jamais atteint le point où sshd démarre. Tout ce qui suit s'effectue via la console de votre fournisseur.

Lisez votre propre console avant de modifier quoi que ce soit. Le texte affiché sur cet écran détermine la classe de panne dans laquelle vous vous trouvez, et deux serveurs qui "ne démarrent plus" peuvent nécessiter des correctifs opposés.

Comment accéder à la console si SSH ne répond plus ?

Ouvrez le panneau de contrôle de votre fournisseur et cherchez une console. Les noms courants sont console VNC, console web, noVNC et console série. Privilégiez la console série si les deux sont disponibles, car elle fournit du texte brut que vous pouvez faire défiler et copier, alors qu'une vue VNC n'est qu'une image de l'écran. Localisez cette option dès maintenant, pendant que la machine est opérationnelle, et vérifiez qu'elle s'ouvre. Chercher cette option en plein incident vous fera perdre le calme nécessaire. Cette vérification doit être effectuée lors de les dix premières minutes sur un nouveau VPS, au même titre que les règles de pare-feu et les clés SSH.

La plupart des panneaux proposent également un mode rescue ou une image de récupération. Cela démarre un système minimal depuis le réseau du fournisseur et monte votre disque comme un périphérique supplémentaire, sans exécuter aucun processus présent sur votre disque. Le mode rescue est la solution de repli lorsque GRUB lui-même est corrompu, et c'est aussi la méthode pour récupérer des données sur un serveur que vous avez décidé de ne pas restaurer.

Vous devrez généralement effectuer un hard reset depuis le panneau pour atteindre le menu de démarrage, car vous ne pouvez pas exécuter sudo reboot sur une machine à laquelle vous ne pouvez pas vous connecter. Un hard reset équivaut à une coupure de courant. Les systèmes de fichiers subissent un arrêt non propre, attendez-vous donc à une vérification du système de fichiers au démarrage suivant.

Comment choisir un ancien noyau dans le menu GRUB ?

Surveillez la console dès que vous appuyez sur le bouton de réinitialisation. Appuyez sur Esc de manière répétée durant les premières secondes, ou maintenez Shift sur une machine démarrant en mode BIOS hérité. La fenêtre de tir est courte et la console met souvent une seconde à se connecter ; commencez donc à appuyer tôt et maintenez la pression.

Lorsque le menu apparaît, choisissez "Advanced options for Ubuntu". Ce sous-menu liste tous les noyaux installés, du plus récent au plus ancien, avec une entrée en mode de récupération pour chacun. Sélectionnez la deuxième entrée normale, qui correspond au noyau précédant le plus récent, puis appuyez sur Entrée. Le mode de récupération est différent : il démarre un système minimal en mode utilisateur unique et sert aux opérations de réparation, pas à remettre vos services en ligne.

Si l'ancien noyau démarre, votre serveur est de nouveau opérationnel. Confirmez la version utilisée et notez les numéros.

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

La sortie de dpkg constitue votre liste de noyaux installés. Si elle ne contient qu'une seule ligne, vous n'avez aucune solution de secours, ce qui doit être votre priorité de correction.

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

Les images cloud intègrent une configuration qui masque le menu. Les images Ubuntu règlent généralement le délai d'attente à 0 dans un fichier situé sous /etc/default/grub.d/, de sorte que le noyau le plus récent démarre immédiatement sans laisser de temps pour une intervention.

Il existe également le cas inverse, où le menu reste affiché en attente, donnant l'impression d'un blocage. GRUB enregistre un échec de démarrage et, au démarrage suivant, peut maintenir le menu ouvert jusqu'à ce qu'une touche soit pressée. Sur une machine sans clavier, cette attente ne finit jamais. Si votre console affiche un menu immobile, c'est ce qui s'est produit. Sélectionnez une entrée pour continuer.

Corrigez ces deux points pendant que la machine est opérationnelle. 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 les changements et vérifiez que votre modification a été prise en compte, car les fichiers dans /etc/default/grub.d/ sont lus après /etc/default/grub et peuvent écraser 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 vers le port série, afin qu'il apparaisse dans l'interface fournie par votre panneau de contrôle. Les arguments noyau console= font de même pour les messages de démarrage qui suivent. Dix secondes de délai par démarrage sont un faible prix à payer pour disposer d'un menu accessible à 2 heures du matin.

À quelle classe de défaillance suis-je confronté ?

Lisez les vingt dernières lignes avant que la console ne se fige. Quatre modèles couvrent la plupart des cas survenant après une mise à jour du noyau.

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 noyau n'apparaît. Le noyau n'est pas encore impliqué. Cela fait suite à une modification de disque ou de partition, ou à un chargeur d'amorçage écrit sur le mauvais périphérique, plutôt qu'à un paquet de noyau en soi.

Le noyau démarre mais ne peut pas monter la racine. Les messages du noyau défilent, puis vous atterrissez dans un shell busybox dont l'invite affiche (initramfs), ou le démarrage se termine par un panic indiquant l'impossibilité de monter le système de fichiers racine. Le noyau s'est chargé. L'initramfs, qui est la petite racine temporaire chargée de trouver et de monter votre système de fichiers racine réel, n'a pas trouvé le disque. Sur Ubuntu, ce shell est normalement précédé d'un message indiquant l'abandon de l'attente du périphérique racine, et il nomme l'UUID recherché. Copiez cet UUID et comparez-le plus tard avec la sortie de blkid.

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

lvm vgchange -ay
ls /dev/mapper
exit

exit redonne le contrôle au script initramfs, qui tente à nouveau le montage. Si le système démarre alors, c'est que l'initramfs actuel manque des composants LVM ; la réparation consiste à reconstruire cette image plutôt qu'à toucher au noyau.

Rien ne provient de Linux. La console affiche du texte du firmware, un shell UEFI (unified extensible firmware interface), un écran noir sans sortie du noyau, ou une boucle de redémarrage. La défaillance survient avant l'exécution de Linux. Vérifiez quel mode votre serveur utilise réellement une fois que vous aurez retrouvé l'accès, car de nombreuses instances VPS démarrent en mode BIOS hérité 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 à jour est une cause fréquente sur les machines UEFI, car les paquets qui gèrent la partition système EFI ont alors écrit dans un répertoire vide ordinaire. Le firmware continue de démarrer l'ancienne entrée de boot jusqu'à ce que cette entrée ne corresponde plus à ce qui se trouve sur le disque.

Un autre modèle n'est pas du tout une défaillance de démarrage. Si vous atteignez un shell root indiquant que le système est en mode secours (emergency mode), le noyau a démarré mais l'espace utilisateur s'est arrêté. Cela signifie généralement une ligne erronée dans /etc/fstab ou un système de fichiers ayant échoué lors de sa vérification. Exécutez journalctl -xb dans ce shell et lisez le nom de l'unité qui a échoué.

Le paquet du noyau est-il corrompu, ou l'initramfs ?

Ces deux problèmes semblent identiques depuis la console et nécessitent des réparations différentes. Démarrez sur l'ancien noyau, 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, chacun avec une taille cohérente. Un initrd manquant, ou beaucoup plus petit que ses voisins, signifie que la génération de l'initramfs a échoué. La cause habituelle est un /boot saturé, et la preuve se trouve 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 liste également précisément quels paquets les dernières exécutions ont installés et quand, ce qui règle tout débat sur ce qui a été modifié.

Libérez de l'espace en premier si /boot est plein, puis reconstruisez l'image pour la version dont vous avez besoin et rafraîchissez le menu. Utilisez la chaîne de version issue de votre propre sortie ls, car l'espace réservé ci-dessous n'est 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 sert de vérification. Un fichier de taille normale signifie que l'image est désormais présente. Si, au contraire, l'image du noyau elle-même est endommagée, ou si dpkg -l indique que le paquet est dans un état autre que ii, réinstallez le paquet :

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

Réparation depuis le mode rescue quand aucun noyau ne démarre

Si toutes les entrées du menu échouent, démarrez sur l'image rescue de votre fournisseur et réparez le disque depuis l'extérieur. Votre disque apparaît comme un périphérique non monté ; rien ne s'exécute dessus et aucun processus ne peut entrer en conflit avec vos opérations.

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 noyau sans compromettre le prochain démarrage

GRUB peut démarrer une entrée une seule fois avant de revenir à votre valeur par défaut. Configurez la valeur par défaut sur un noyau fiable, puis lancez le nouveau pour un seul démarrage. En cas d'échec, un redémarrage forcé depuis le panneau de contrôle vous ramène au noyau fonctionnel sans avoir à gérer le timing de la console.

Définissez GRUB_DEFAULT=saved dans /etc/default/grub, exécutez sudo update-grub, puis listez les titres des entrées pour pouvoir en nommer une précisément :

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 en tant que saved_entry. Ce résultat prouve que le mécanisme fonctionne, car la sauvegarde nécessite un /boot/grub/grubenv accessible en écriture, ce qui n'est pas toujours le cas silencieusement selon les configurations. L'entrée 0 correspond au haut du menu, soit le noyau le plus récent. Les titres sont plus sûrs que les numéros ici, car les numéros changent à chaque installation ou suppression de noyau.

Pourquoi autoremove est risqué sur un serveur headless

APT conserve une liste des paquets noyau qu'il ne doit pas supprimer automatiquement. Consultez 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 modification des paquets noyau et protège le noyau en cours d'exécution ainsi que les plus récents. Le piège est une question de timing. Exécutez sudo apt autoremove --purge juste après avoir redémarré sur un nouveau noyau : la liste protégée a déjà été mise à jour, et l'ancien noyau sur lequel vous comptiez n'est plus protégé. Sur une machine avec un clavier, c'est un désagrément. Sur un serveur headless, c'est la différence entre choisir une entrée dans un menu et devoir monter votre disque depuis une image de secours.

Gardez deux noyaux comme base, et trois si /boot dispose de l'espace nécessaire. Supprimez les anciens 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'

Exécutez à nouveau cette dernière commande par la suite. Si le compteur passe de trois à deux, il s'agit d'un nettoyage. S'il passe à un, c'est une panne en attente du prochain redémarrage.

Effectuer un snapshot avant la mise à niveau

Un snapshot effectué avant apt upgrade constitue la seule méthode de récupération qui ne nécessite pas de démarrer un système tiers. Le restaurer remet le disque dans l'état où l'ancien noyau était par défaut, ce qui vous permet de retenter la mise à niveau avec la console déjà ouverte. Les snapshots d'une machine en cours d'exécution sont « crash consistent », ce qui signifie qu'ils capturent le disque comme si l'alimentation avait été coupée. Éteignez donc le serveur au préalable si votre fournisseur prend en charge les snapshots hors ligne. Un snapshot n'est pas une sauvegarde, car il réside généralement sur la même infrastructure que le volume qu'il copie. Comprendre la différence entre les snapshots VPS et les sauvegardes réelles détermine quelle solution vous sauvera si la panne est plus grave qu'un simple problème de noyau.

Ceci est crucial lors d'une mise à niveau de version, où le noyau, les outils initramfs, le chargeur de démarrage et la configuration GRUB changent en une seule opération. Effectuez le snapshot immédiatement avant de commencer une mise à niveau d'Ubuntu 24.04 vers 26.04, et non la veille, afin que le point de restauration corresponde exactement à la machine que vous vous apprêtez à modifier.

Comment unattended-upgrades gère les paquets du noyau

Le paquet unattended-upgrades d'Ubuntu installe les mises à jour de sécurité sans intervention, et les paquets du noyau arrivent via le dépôt de sécurité comme n'importe quel autre paquet. Deux conséquences en découlent.

Premièrement, le nouveau noyau est installé mais 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 déclenché la demande de redémarrage, mais rien ne redémarre à moins que vous n'ayez 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écalage masque la cause des problèmes. Un serveur peut installer un noyau en mars et redémarrer en juin pour une raison totalement indépendante, puis échouer à démarrer. La modification ayant causé l'échec du démarrage date de trois mois, donc aucune action effectuée ce jour-là ne l'explique. /var/log/apt/history.log est l'endroit où vous trouverez l'exécution ayant installé le noyau qui provoque l'échec actuel.

Redémarrez volontairement, un jour que vous avez choisi, avec la fenêtre de console déjà ouverte. Cette simple habitude transforme une panne mystérieuse en une intervention de deux minutes. Si vous souhaitez l'automatisation sans les surprises, gardez les installations automatiques activées mais les redémarrages automatiques désactivés, et consultez comment configurer 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 arrête complètement, mais cela bloque également les correctifs de sécurité du noyau ; considérez donc cela comme un compromis assumé plutôt que 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) et déclenchez un hard reset depuis le panneau de contrôle, car vous ne pouvez pas vous connecter pour redémarrer proprement. Au redémarrage de la machine, appuyez sur Esc de manière répétée, ou maintenez Shift sur un BIOS legacy, pour afficher le menu GRUB. Choisissez « Advanced options for Ubuntu » et sélectionnez l'entrée située sous le noyau le plus récent. Une fois devant l'invite de connexion, exécutez uname -r pour confirmer le noyau utilisé et dpkg -l 'linux-image-*' pour lister les autres versions installées. Ne diagnostiquez qu'une fois le système opérationnel.

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

Les images cloud règlent souvent le timeout de GRUB à 0 dans un fichier sous /etc/default/grub.d/, ce qui lance le noyau le plus récent sans possibilité d'interruption. Réglez GRUB_TIMEOUT=10 et GRUB_TIMEOUT_STYLE=menu dans /etc/default/grub, ajoutez GRUB_TERMINAL="console serial" pour que le menu soit aussi envoyé vers la 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 dans ce répertoire sont lus après le fichier principal et peuvent écraser votre modification.

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

Supprimez les plus anciens et conservez-en au moins deux. Une partition /boot pleine est une cause de panne en soi, car la génération de l'initramfs échoue et vous vous retrouvez avec un noyau sans image fonctionnelle. Purgez par le nom exact du paquet après avoir vérifié uname -r, afin que le noyau en cours d'exécution ne soit jamais candidat à la suppression. Évitez un sudo apt autoremove --purge global sur une machine sans écran, car la liste des noyaux protégés est régénérée à chaque changement de noyau et une exécution mal synchronisée peut vous laisser avec un seul noyau sans entrée de secours dans le menu.

Est-ce que unattended-upgrades peut empêcher le démarrage ?

Il peut installer un noyau qui échoue au démarrage, mais il ne redémarre pas la machine sauf si Unattended-Upgrade::Automatic-Reboot est réglé 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, et le problème ne survient qu'au redémarrage suivant, des semaines plus tard. Redémarrez volontairement avec la console déjà ouverte, et lisez /var/log/apt/history.log pour identifier quelle exécution a installé le noyau sur lequel vous démarrez.