Mettre à jour le noyau Debian sur un serveur Kimsufi/OVH

Mettre à jour le noyau Debian d’un serveur dédié Kimsufi ou OVH peut être nécessaire pour corriger une faille, améliorer la prise en charge matérielle, bénéficier d’un noyau LTS plus récent ou résoudre un bug réseau, disque ou virtualisation.

Mais un noyau, ce n’est pas un plugin WordPress. Si le serveur ne redémarre pas, vous n’avez plus seulement un paquet cassé : vous avez une machine distante muette, et une petite montée d’adrénaline offerte par GRUB.

Dans ce guide, nous allons voir comment mettre à jour proprement le noyau Debian sur un serveur dédié Kimsufi ou OVHcloud : diagnostic, sauvegarde, noyau officiel, backports, GRUB, redémarrage, vérifications, rollback et mode rescue.

Faut-il vraiment mettre à jour le noyau ?

Avant de toucher au noyau, identifiez la raison. Sur un serveur Debian stable, le noyau fourni par la distribution reçoit des correctifs de sécurité sans forcément changer de version majeure visible. Une version qui paraît ancienne n’est donc pas forcément vulnérable.

Une mise à jour du noyau peut être utile si :

• un bulletin de sécurité impose une correction noyau ;
• le matériel est mal reconnu ;
• un pilote réseau, disque ou RAID pose problème ;
• vous avez besoin d’un noyau plus récent via backports ;
• un bug kernel affecte votre charge réelle ;
• vous migrez vers une version Debian plus récente ;
• vous avez des modules DKMS à reconstruire proprement.

En revanche, ne mettez pas à jour le noyau “pour avoir le dernier”. Sur un serveur, la stabilité vaut souvent mieux que la nouveauté. Le kernel dernier cri sur une machine de production, c’est parfois une excellente manière de découvrir des bugs avant tout le monde. Ambiance bêta-testeur involontaire.

Identifier la version Debian et le noyau actuel

Commencez par relever l’état exact du serveur :

cat /etc/os-release
uname -a
uname -r
dpkg --print-architectureLangage du code : PHP (php)

Listez les noyaux installés :

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

Listez aussi les headers installés :

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

Sur un serveur Debian amd64 classique, le métapaquet important est généralement :

linux-image-amd64

Ce métapaquet dépend du dernier noyau Debian approprié à l’architecture amd64. Dans bookworm-backports, par exemple, Debian décrit linux-image-amd64 comme le métapaquet qui dépend du dernier noyau Linux et de ses modules pour les machines AMD64, Intel 64 et VIA Nano.

Vérifier le mode de démarrage : BIOS ou UEFI

Avant de redémarrer un serveur distant, vérifiez le mode de boot. Cela aide à comprendre GRUB, les partitions EFI et le plan de récupération.

if [ -d /sys/firmware/efi ]; then
  echo "Boot UEFI"
else
  echo "Boot BIOS/Legacy"
fiLangage du code : PHP (php)

Listez les disques et partitions :

lsblk -f
findmnt /
findmnt /boot
findmnt /boot/efi

Sur certains serveurs dédiés, /boot ou /boot/efi peut être séparé. Vérifiez qu’il reste de l’espace avant d’installer un nouveau noyau.

df -h /boot /boot/efi 2>/dev/null || trueLangage du code : JavaScript (javascript)

Un /boot plein peut empêcher l’installation du nouveau noyau ou générer une initramfs incomplète. C’est bête, mais c’est un grand classique. Le genre de panne qui n’a pas de panache, donc qui arrive souvent.

Avant toute mise à jour : sauvegardez

Avant une mise à jour noyau, assurez-vous d’avoir des sauvegardes récentes et restaurables. Sur un serveur web, cela veut dire au minimum :

• fichiers des sites ;
• bases de données ;
• configurations Nginx ou Apache ;
• configurations PHP-FPM ;
• configurations mail si le serveur héberge Postfix/Dovecot ;
• pare-feu ;
• crons ;
• clés SSH ;
• configuration réseau.

Pour un site WordPress, exportez au moins la base avant intervention :

mkdir -p ~/backups
wp db export ~/backups/before-kernel-update-$(date +%F-%H%M%S).sql --add-drop-table

Pour une sauvegarde rapide de configuration serveur :

sudo tar -czf ~/server-config-before-kernel-$(date +%F-%H%M%S).tar.gz \
  /etc/nginx \
  /etc/apache2 \
  /etc/php \
  /etc/postfix \
  /etc/dovecot \
  /etc/ssh \
  /etc/fail2ban \
  /etc/ufw \
  /etc/cron* \
  2>/dev/null || trueLangage du code : JavaScript (javascript)

Adaptez à votre stack. L’objectif n’est pas de faire une sauvegarde parfaite ici, mais d’éviter de perdre la configuration critique si vous devez réparer depuis le mode rescue.

Préparer le mode rescue OVHcloud/Kimsufi

Sur un serveur Kimsufi, le filet de sécurité principal est le mode rescue OVHcloud. Il permet de démarrer le serveur sur un système temporaire pour diagnostiquer et réparer une installation qui ne démarre plus.

OVHcloud documente le mode rescue comme un système temporaire adapté à la réparation d’un système cassé, au diagnostic réseau, à la correction d’un pare-feu, aux tests disque, CPU ou RAM. Le mode rescue nécessite de modifier le paramètre de Netboot, puis de redémarrer le serveur.

Avant le reboot kernel, vérifiez donc que vous savez :

• ouvrir l’espace client OVHcloud ;
• trouver le serveur dédié ;
• changer le Netboot ;
• activer le mode rescue ;
• redémarrer la machine ;
• récupérer les identifiants rescue envoyés par email ;
• remettre ensuite le boot sur disque dur normal.

Le mode rescue interrompt les services en production, puisqu’il redémarre la machine sur un environnement auxiliaire. OVHcloud recommande aussi de sauvegarder vos données si vous n’avez pas déjà de sauvegardes récentes.

Méthode 1 : mettre à jour le noyau Debian officiel

La méthode la plus sûre consiste à rester sur les paquets noyau officiels de votre version Debian stable.

Mettez à jour la liste des paquets :

sudo apt update

Vérifiez les mises à jour disponibles :

apt list --upgradableLangage du code : PHP (php)

Mettez à jour le système :

sudo apt full-upgrade

Assurez-vous que le métapaquet noyau est installé :

sudo apt install linux-image-amd64

Si vous utilisez des modules DKMS, installez aussi les headers correspondants :

sudo apt install linux-headers-amd64 dkms

Ensuite, vérifiez les noyaux disponibles :

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

Ne redémarrez pas encore. D’abord, vérifiez GRUB et l’initramfs.

Méthode 2 : installer un noyau plus récent depuis Debian Backports

Si le noyau stable ne suffit pas, Debian Backports est la voie propre pour installer un noyau plus récent tout en restant dans l’écosystème Debian.

Debian Backports fournit des paquets reconstruits pour Debian stable, issus principalement de Debian testing. Le projet recommande de choisir seulement les backports nécessaires, au cas par cas, plutôt que d’utiliser tous les paquets backports disponibles.

Vérifiez votre nom de version Debian :

. /etc/os-release
echo "$VERSION_CODENAME"Langage du code : PHP (php)

Pour Debian 12 Bookworm, créez une source backports moderne au format deb822 :

sudo tee /etc/apt/sources.list.d/debian-backports.sources >/dev/null <&lt'EOF'
Types: deb
URIs: http://deb.debian.org/debian
Suites: bookworm-backports
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
EOFLangage du code : JavaScript (javascript)

Pour Debian 13 Trixie, adaptez :

sudo tee /etc/apt/sources.list.d/debian-backports.sources >/dev/null <&lt'EOF'
Types: deb
URIs: http://deb.debian.org/debian
Suites: trixie-backports
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
EOFLangage du code : JavaScript (javascript)

Mettez à jour APT :

sudo apt update

Installez uniquement le noyau depuis backports. Pour Debian 12 :

sudo apt install -t bookworm-backports linux-image-amd64 linux-headers-amd64

Pour Debian 13 :

sudo apt install -t trixie-backports linux-image-amd64 linux-headers-amd64

Les instructions officielles de Debian Backports indiquent que les backports sont désactivés par défaut et que l’installation se fait explicitement avec apt install -t trixie-backports <package> ou l’équivalent de la suite utilisée.

Sur Debian 12, le métapaquet linux-image-amd64 de bookworm-backports dépend actuellement d’un noyau 6.12 signé dans les pages de paquets Debian, ce qui illustre bien l’intérêt des backports pour obtenir un noyau plus récent sans basculer tout le système en testing.

Éviter les backports “sloppy” sauf cas très particulier

Debian propose aussi des suites oldstable-backports-sloppy dans certains cas. Évitez-les sur un serveur de production, sauf besoin précis et assumé.

La documentation Backports explique que les backports “sloppy” sacrifient la capacité à faire une mise à niveau propre vers la version stable suivante et sont fournis sans support officiel équivalent.

Sur un serveur Kimsufi qui héberge des services, votre objectif est d’avoir un système maintenable. Pas de gagner trois numéros de version au prix d’un futur upgrade pénible.

Vérifier DKMS et les modules externes

Si vous utilisez ZFS, VirtualBox, pilotes réseau spécifiques, modules RAID, WireGuard hors noyau ancien, ou tout autre module externe, vérifiez DKMS avant de redémarrer.

dkms status

Après installation du nouveau noyau, DKMS doit reconstruire les modules nécessaires. Vérifiez les erreurs :

journalctl -p err -b --no-pager | tail -n 100
grep -R "Error" /var/lib/dkms 2>/dev/null | head -n 50Langage du code : JavaScript (javascript)

Si DKMS échoue sur un module essentiel au boot ou au réseau, ne redémarrez pas avant d’avoir corrigé. Un serveur sans module réseau après reboot, c’est un serveur qui médite en silence.

Vérifier GRUB avant redémarrage

Après l’installation du noyau, mettez à jour GRUB si nécessaire :

sudo update-grub

Vérifiez que le nouveau noyau apparaît dans la configuration GRUB :

grep -E "menuentry 'Debian GNU/Linux|linux /boot/vmlinuz" /boot/grub/grub.cfg | head -n 40Langage du code : JavaScript (javascript)

Vérifiez aussi les fichiers dans /boot :

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

Vérifiez le noyau par défaut configuré :

grep '^GRUB_DEFAULT' /etc/default/grubLangage du code : JavaScript (javascript)

Dans la majorité des cas, gardez GRUB_DEFAULT=0. GRUB démarrera sur le noyau le plus récent. Ne modifiez cette valeur que si vous avez une vraie stratégie de boot.

Garder au moins un ancien noyau installé

Ne supprimez jamais tous les anciens noyaux avant d’avoir redémarré et validé le nouveau. Gardez au minimum un noyau précédent connu comme fonctionnel.

Vérifiez la liste :

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

Après plusieurs semaines de stabilité, vous pourrez nettoyer les anciens paquets. Pas avant. Le rollback le plus simple est souvent juste un ancien noyau encore présent dans GRUB.

Planifier le redémarrage

Un nouveau noyau ne sera utilisé qu’après redémarrage. Planifiez une fenêtre courte, surtout si le serveur héberge des sites, emails, bases de données ou services clients.

Avant reboot :

• prévenez si nécessaire ;
• vérifiez les sauvegardes ;
• gardez l’accès OVHcloud ouvert ;
• gardez le mode rescue en tête ;
• ouvrez un terminal avec une session root ou sudo ;
• notez l’ancien noyau ;
• vérifiez les services critiques.

Notez le noyau avant redémarrage :

uname -r > ~/kernel-before-reboot.txt
cat ~/kernel-before-reboot.txt

Lancez le reboot :

sudo systemctl reboot

Surveillez ensuite le ping ou l’accès SSH depuis votre poste :

ping votre-serveur.example.comLangage du code : CSS (css)

Ne redémarrez pas une deuxième fois parce que “ça semble long” au bout de vingt secondes. Un serveur dédié peut prendre un peu de temps à revenir. Le double reboot impatient est une discipline dangereuse.

Vérifier le noyau après redémarrage

Une fois reconnecté en SSH :

uname -r
uptime
hostnamectl

Comparez avec l’ancien noyau :

cat ~/kernel-before-reboot.txt

Vérifiez les erreurs du boot courant :

journalctl -p err -b --no-pager

Vérifiez les services critiques :

systemctl --failed
systemctl status ssh --no-pager
systemctl status nginx --no-pager 2>/dev/null || true
systemctl status apache2 --no-pager 2>/dev/null || true
systemctl status php8.3-fpm --no-pager 2>/dev/null || true
systemctl status mariadb --no-pager 2>/dev/null || true
systemctl status postfix --no-pager 2>/dev/null || trueLangage du code : JavaScript (javascript)

Adaptez les versions PHP et les services à votre serveur.

Vérifier réseau, disques et firewall

Après un changement de noyau, vérifiez le réseau :

ip addr
ip route
resolvectl status 2>/dev/null || cat /etc/resolv.confLangage du code : JavaScript (javascript)

Vérifiez les disques :

lsblk
df -h
mount | column -t

Vérifiez le firewall :

sudo nft list ruleset | head -n 80
sudo ufw status verbose 2>/dev/null || trueLangage du code : JavaScript (javascript)

Si un service n’écoute plus :

ss -tulpn

Un noyau peut changer le comportement d’un pilote réseau, d’un module firewall ou d’un système de fichiers. C’est rare avec les noyaux Debian officiels, mais c’est précisément pour cela qu’on vérifie.

Rollback : redémarrer sur un ancien noyau

Si le nouveau noyau démarre mais provoque des problèmes, vous pouvez configurer GRUB pour démarrer sur l’ancien noyau au prochain reboot.

Listez les entrées GRUB :

grep -n "menuentry '" /boot/grub/grub.cfg | head -n 40Langage du code : JavaScript (javascript)

Sur Debian, les anciens noyaux sont généralement dans le sous-menu “Advanced options for Debian GNU/Linux”. Le plus propre est souvent d’utiliser grub-reboot pour un démarrage unique sur une entrée précise.

Exemple conceptuel :

sudo grub-reboot "Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 6.1.0-xx-amd64"
sudo rebootLangage du code : JavaScript (javascript)

Adaptez exactement le nom de l’entrée. Une erreur de chaîne peut ne pas produire le résultat attendu. Sur serveur distant, soyez méthodique.

Si le serveur ne revient pas : utiliser le mode rescue

Si SSH ne revient pas après le reboot, passez par l’espace client OVHcloud/Kimsufi et activez le mode rescue.

Une fois connecté au rescue, identifiez les disques :

lsblk -f

Montez la partition racine. Exemple simple :

mkdir -p /mnt/server
mount /dev/sda2 /mnt/server

Adaptez /dev/sda2 à votre partition réelle. Si vous avez du RAID logiciel ou LVM, assemblez d’abord les volumes.

Montez les pseudo-systèmes pour chrooter :

mount --bind /dev /mnt/server/dev
mount --bind /proc /mnt/server/proc
mount --bind /sys /mnt/server/sys
mount --bind /run /mnt/server/run

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

mount /dev/sda1 /mnt/server/boot

Si vous êtes en UEFI, montez la partition EFI :

mount /dev/sda1 /mnt/server/boot/efi

Chrootez :

chroot /mnt/server /bin/bash

Depuis le chroot, vous pouvez réinstaller un noyau, mettre à jour GRUB, corriger /etc/default/grub ou retirer le noyau problématique.

apt update
apt install --reinstall linux-image-amd64
update-initramfs -u -k all
update-grub

Ensuite, quittez, démontez, remettez le Netboot OVHcloud sur disque normal, puis redémarrez.

Nettoyer les anciens noyaux après validation

Après plusieurs jours ou semaines de fonctionnement stable, vous pouvez nettoyer les anciens noyaux inutiles. Ne gardez pas dix versions si /boot est petit, mais gardez au moins un noyau de secours.

Vérifiez le noyau actif :

uname -r

Listez les noyaux installés :

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

Nettoyage automatique prudent :

sudo apt autoremove --purge

Relisez toujours ce qu’APT veut supprimer avant de valider. Si vous voyez le noyau actif dans la liste, arrêtez tout. APT est un outil, pas un ange gardien.

Cas particulier : serveurs très anciens Kimsufi

Certains vieux serveurs Kimsufi ont du matériel ancien : cartes réseau anciennes, contrôleurs SATA datés, BIOS capricieux, partitions historiques, boot legacy, ou installations Debian migrées plusieurs fois.

Sur ces machines, soyez encore plus prudent :

• évitez les noyaux non officiels ;
• gardez un noyau précédent ;
• vérifiez les pilotes réseau après reboot ;
• contrôlez les logs dmesg ;
• gardez le mode rescue prêt ;
• préférez une mise à niveau Debian complète si le système est trop ancien.

Si le serveur tourne encore sur une vieille Debian non supportée, la priorité n’est pas “un noyau plus récent”. La priorité est de migrer vers une version supportée ou vers une nouvelle machine. Un vieux serveur patché à la ficelle finit toujours par présenter la facture.

Faut-il compiler son propre noyau ?

Dans presque tous les cas : non.

Compiler son noyau peut se justifier pour un besoin très spécifique, mais ce n’est pas une méthode de maintenance normale pour un serveur Debian. Vous perdez une partie de l’intégration APT, vous augmentez la charge de maintenance, et vous compliquez les mises à jour de sécurité.

Ordre recommandé :

1. noyau Debian stable ;
2. noyau Debian stable à jour ;
3. noyau Debian Backports si besoin réel ;
4. migration vers une Debian plus récente ;
5. noyau custom seulement pour un cas très spécifique.

Pour un serveur web, mail ou WordPress, les noyaux Debian officiels couvrent généralement très bien le besoin.

Script de pré-vérification avant mise à jour noyau

Voici un petit script pour collecter les informations utiles avant intervention.

#!/usr/bin/env bash

set -euo pipefail

echo "=== Système ==="
cat /etc/os-release
echo

echo "=== Noyau actif ==="
uname -a
echo

echo "=== Architecture ==="
dpkg --print-architecture
echo

echo "=== Boot mode ==="
if [ -d /sys/firmware/efi ]; then
  echo "UEFI"
else
  echo "BIOS/Legacy"
fi
echo

echo "=== Espace /boot ==="
df -h /boot /boot/efi 2>/dev/null || true
echo

echo "=== Noyaux installés ==="
dpkg -l 'linux-image*' | grep '^ii' || true
echo

echo "=== Headers installés ==="
dpkg -l 'linux-headers*' | grep '^ii' || true
echo

echo "=== DKMS ==="
dkms status 2>/dev/null || echo "DKMS non installé ou aucun module DKMS."
echo

echo "=== Services échoués ==="
systemctl --failed || true
echo

echo "=== Disques ==="
lsblk -f
echo

echo "=== GRUB default ==="
grep '^GRUB_DEFAULT' /etc/default/grub || trueLangage du code : PHP (php)

Enregistrez-le :

nano kernel-precheck.sh
chmod +x kernel-precheck.sh
./kernel-precheck.sh | tee kernel-precheck-$(date +%F-%H%M%S).logLangage du code : JavaScript (javascript)

Checklist avant reboot

• Les sauvegardes sont récentes et vérifiées.
• Le mode rescue OVHcloud/Kimsufi est connu et accessible.
• Le nouveau noyau est installé via APT.
• Les headers sont installés si DKMS est utilisé.
• DKMS ne signale pas d’échec critique.
• /boot n’est pas plein.
• GRUB voit le nouveau noyau.
• Un ancien noyau fonctionnel reste installé.
• Les services critiques sont identifiés.
• Une fenêtre de redémarrage est prévue.
• L’accès à l’espace client OVHcloud est ouvert.

FAQ

Faut-il redémarrer après une mise à jour du noyau Debian ?

Oui. Le nouveau noyau n’est utilisé qu’après redémarrage. Vous pouvez installer le paquet avant, mais uname -r ne changera qu’après reboot.

Quel paquet installer pour suivre le noyau Debian amd64 ?

Installez généralement linux-image-amd64. C’est un métapaquet qui dépend du noyau approprié pour l’architecture amd64. Ajoutez linux-headers-amd64 si vous utilisez DKMS.

Puis-je installer un noyau depuis Debian Backports ?

Oui, si vous avez un besoin réel. Utilisez apt install -t bookworm-backports linux-image-amd64 linux-headers-amd64 sur Debian 12, en adaptant la suite à votre version Debian.

Dois-je supprimer les anciens noyaux avant reboot ?

Non. Gardez au moins un ancien noyau fonctionnel. Supprimez les noyaux inutiles seulement après avoir validé le nouveau en production.

Que faire si le serveur Kimsufi ne redémarre plus ?

Activez le mode rescue depuis l’espace client OVHcloud/Kimsufi, montez les partitions, chrootez dans le système installé, puis réinstallez le noyau ou corrigez GRUB.

Faut-il compiler son propre noyau sur un serveur Debian ?

Très rarement. Préférez le noyau Debian stable, puis Debian Backports si besoin. Un noyau compilé à la main augmente la maintenance et complique les mises à jour de sécurité.

Conclusion

Mettre à jour le noyau Debian d’un serveur Kimsufi ou OVHcloud doit rester une opération maîtrisée. Utilisez les paquets officiels Debian, ou Debian Backports si vous avez besoin d’un noyau plus récent. Évitez les dépôts exotiques et les noyaux compilés à la main sans nécessité solide.

La clé, c’est la préparation : sauvegardes, espace dans /boot, headers, DKMS, GRUB, ancien noyau conservé, fenêtre de reboot et mode rescue prêt. Une fois le serveur redémarré, vérifiez le noyau actif, les logs, les services et le réseau.

Un changement de noyau bien préparé prend peu de temps. Un changement improvisé peut vous offrir une longue soirée en rescue. Et franchement, il y a des manières plus agréables de passer la nuit.

Sources

• Debian Backports : instructions officielles
• Debian Wiki : Backports
• Debian Packages : linux-image-amd64 dans bookworm-backports
• OVHcloud : mode rescue sur un serveur dédié
• OVHcloud : how to activate and use rescue mode

Report a typo