Mettre à jour le noyau d'un serveur de production : ordre, plan de retour arrière et quand livepatch vaut la peine

Toute autre mise à jour se rétrograde avec apt install pkg=ancienne-version. Une mise à jour du noyau se rétrograde en choisissant l'ancien noyau dans GRUB — ce qui suppose que vous atteigniez GRUB, que l'ancien noyau soit encore là, et que vous fassiez tout cela sous pression pendant que le serveur est à terre. C'est pourquoi la préparation représente 80 % du travail. Cet article est la checklist, dans l'ordre où nous la déroulons nous-mêmes.

Étape 0 : savoir pourquoi vous redémarrez

uname -r                                          # ce qui tourne
dpkg -l 'linux-image-[0-9]*' | awk '/^ii/{print $2}' | sort -V   # ce qui est installé
cat /var/run/reboot-required.pkgs 2>/dev/null     # pourquoi le système veut un redémarrage

Si le nouveau noyau est déjà là (installé par unattended-upgrades, pas encore démarré), sautez l'étape 3. S'il s'agit d'une CVE : vérifiez d'abord dans CVE noyau et backports si elle touche votre noyau — la moitié des redémarrages « urgents » ne le sont pas.

Étape 1 : pré-vérifications (cinq minutes qui vous épargnent une nuit)

# 1. Espace sur /boot — chaque noyau fait 100–150 Mo ; trop peu = installation à moitié faite
df -h /boot
sudo apt autoremove --purge -y            # anciens noyaux dehors, gardez-en au moins deux

# 2. Modules hors arbre (DKMS) : ils doivent être recompilés pour le nouveau noyau
dkms status 2>/dev/null                    # nvidia, zfs, wireguard (ancien), virtualbox, ...
# Vide = pas d'inquiétude. Sinon : assurez-vous que linux-headers-<nouvelle version> s'installe aussi.

# 3. Secure Boot + DKMS = les modules doivent être signés avec une clé MOK
mokutil --sb-state 2>/dev/null             # "SecureBoot enabled" + DKMS → mokutil --list-enrolled

# 4. Quel noyau GRUB démarre-t-il par défaut, et y a-t-il un menu pour se replier ?
grep -E '^GRUB_(DEFAULT|TIMEOUT|TIMEOUT_STYLE)' /etc/default/grub
# GRUB_DEFAULT=0 et GRUB_TIMEOUT=0 signifie : aucune chance de choisir en cas de démarrage bloqué.

# 5. Y a-t-il une console si SSH ne revient pas ? (cloud : VNC/série dans le panneau ; bare metal : IPMI/iDRAC)
#    Ce n'est pas une commande, c'est : savez-vous où est le bouton AVANT d'appuyer sur reboot ?

# 6. Y a-t-il des choses qui nécessitent un arrêt propre ?
systemctl list-units --type=service --state=running --no-legend | grep -Ei 'postgres|mysql|mariadb|redis|rabbit|docker'

Le point 5 est le plus important. Un noyau qui bloque sur un hôte sans console, c'est un ticket chez l'hébergeur et une heure d'indisponibilité.

Étape 2 : snapshot ou sauvegarde

Sur un VPS : snapshot via le panneau ou l'API de l'hébergeur (Hetzner, OVH, Scaleway ont tous un snapshot create). Sur LVM :

sudo lvcreate -s -L 5G -n root-prekernel /dev/vg0/root
# Retour arrière plus tard : sudo lvconvert --merge /dev/vg0/root-prekernel  (effectif après redémarrage)

Ni LVM ni API de snapshot ? Alors au minimum un restic backup /etc /boot et la certitude que votre dernière sauvegarde complète date d'aujourd'hui. Voir vérifier les sauvegardes.

Étape 3 : installer, mais ne pas encore redémarrer

sudo apt update
sudo apt install -y linux-image-generic linux-headers-generic     # Ubuntu
# sudo apt install -y linux-image-amd64 linux-headers-amd64        # Debian
# Ou, si unattended-upgrades l'a déjà récupéré : rien à faire.

# Contrôle : le nouveau noyau est-il dans /boot ET dans GRUB ?
ls -1 /boot/vmlinuz-*
grep -oE "menuentry '[^']+'" /boot/grub/grub.cfg | head -5
# Les modules DKMS sont-ils compilés pour le nouveau noyau ?
dkms status 2>/dev/null | grep -v "$(uname -r)"    # doit dire "installed" pour la nouvelle version

Si dkms status montre added ou built sans installed pour le nouveau noyau, ne redémarrez pas. sudo dkms autoinstall -k <nouvelle-version> et regardez l'erreur.

Étape 4 : le repli — un démarrage raté et GRUB choisit lui-même l'ancien noyau

C'est l'étape qui fait la différence entre « un peu tendu » et « rouler vers le datacenter au milieu de la nuit ». GRUB peut mémoriser si un démarrage a réussi, et se replier sinon.

# 1. GRUB mémorise la dernière entrée choisie et affiche un court menu sur la console
sudo tee /etc/default/grub.d/90-fallback.cfg >/dev/null <<'EOF'
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=false
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=30
EOF
sudo update-grub

# 2. Définir l'ANCIEN noyau par défaut, et démarrer le nouveau UNE SEULE FOIS
OLD=$(uname -r)
NEW=$(ls -1 /boot/vmlinuz-* | sed 's|/boot/vmlinuz-||' | sort -V | tail -1)
echo "old=$OLD new=$NEW"
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux $OLD"
sudo grub-reboot      "Advanced options for Ubuntu>Ubuntu, with Linux $NEW"
# Debian : remplacez "Ubuntu" par "Debian GNU/Linux"

Ce qui se passe maintenant : le prochain démarrage utilise le nouveau noyau (grub-reboot est à usage unique). Si le nouveau noyau ne démarre pas (kernel panic, pilote bloqué), l'ancien noyau redevient la valeur par défaut au cycle d'alimentation suivant — sans que vous ayez à faire quoi que ce soit. S'il démarre, vous le rendez définitif à l'étape 6.

Les noms exacts du menu se trouvent avec grep -oE "menuentry '[^']+'" /boot/grub/grub.cfg ; ils diffèrent selon la distribution et la saveur de noyau (-generic, -cloud-amd64).

Étape 5 : redémarrer, dans la fenêtre

# Arrêt propre des bases de données d'abord — ne comptez pas sur le délai d'arrêt
sudo systemctl stop postgresql mariadb 2>/dev/null
sudo needrestart -b | grep KSTA          # 3 = redémarrage nécessaire, donc on fait bien
sudo reboot

Sur un second écran, lancez un ping et une tentative ssh en boucle. Un VPS revient généralement en 30–90 secondes ; un serveur bare metal avec beaucoup de RAM et un POST peut prendre cinq minutes. Ce n'est qu'après dix minutes sans SSH que vous allez sur la console.

Étape 6 : vérifier, puis seulement rendre définitif

uname -r                                          # la NOUVELLE version ?
systemctl --failed                                 # rien
journalctl -b -p err --no-pager | head -30         # pas d'erreurs de pilotes
ip -br a; ip route | head -3                       # réseau comme attendu
lsmod | wc -l; dkms status 2>/dev/null             # modules chargés
df -h | grep -vE 'tmpfs|udev'                      # tous les montages revenus (NFS ! iSCSI !)
systemctl is-active postgresql mariadb docker 2>/dev/null
curl -fsS -o /dev/null -w '%{http_code}\n' http://localhost/healthz   # l'application elle-même

# Tout va bien ? Faites du nouveau noyau la valeur par défaut.
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux $(uname -r)"
# Ou retour à la première entrée ordinaire :
# sudo sed -i 's/^GRUB_DEFAULT=saved/GRUB_DEFAULT=0/' /etc/default/grub.d/90-fallback.cfg && sudo update-grub

Journalisez le résultat avec la date — c'est la preuve du délai de correction qu'un auditeur demande :

echo "$(date -Is) $(hostname -s) kernel $OLD -> $(uname -r) OK, downtime $(( $(date +%s) - $(stat -c %Y /var/log/kernel-update.start) ))s" | sudo tee -a /var/log/kernel-updates.log

(Faites sudo touch /var/log/kernel-update.start juste avant le reboot de l'étape 5.)

Retour arrière : si l'étape 6 n'est PAS bonne

Le serveur est revenu, mais quelque chose ne fonctionne pas (une carte réseau, un pilote de stockage, une application qui s'appuyait sur une fonctionnalité du noyau) :

# 1. Redémarrer sur l'ancien noyau
sudo grub-reboot "Advanced options for Ubuntu>Ubuntu, with Linux $OLD" && sudo reboot
# 2. Après le redémarrage : geler le noyau jusqu'à savoir ce qui n'allait pas
sudo apt-mark hold linux-image-generic linux-headers-generic
# 3. Ne supprimer le noyau défaillant qu'une fois la cause connue
# sudo apt remove linux-image-$NEW linux-modules-$NEW

Et le snapshot LVM de l'étape 2, vous ne le fusionnez que si des fichiers sont cassés (un passage dpkg à moitié fait), pas pour un noyau qui ne vous convient simplement pas.

Quand livepatch vaut la peine

Livepatch (Ubuntu Pro, gratuit jusqu'à cinq machines ; kpatch sur RHEL) corrige un sous-ensemble de CVE noyau critiques en mémoire, sans redémarrage. Ce n'est pas un remplacement de cette procédure — needrestart continue de dire « redémarrage nécessaire » — mais cela achète du temps : la CVE du lundi est fermée mardi, et vous planifiez le redémarrage dans la fenêtre de la semaine suivante.

L'arbitrage : si vous avez une fenêtre de maintenance mensuelle dans laquelle un redémarrage rentre de toute façon, livepatch ajoute peu. Si vous avez une base de données ou un SLA client qui n'autorise que deux redémarrages par an, cela vaut la peine. Debian n'a pas d'équivalent officiel ; là, une fenêtre planifiée est la pratique.

Pièges

• GRUB_TIMEOUT=0 et pas de console. Il n'y a alors aucun moyen d'intervenir sur un noyau bloqué. Le repli de l'étape 4 résout cela, mais seulement si vous le configurez avant la mise à jour.
• Montages NFS et iSCSI qui ne reviennent pas. Après un redémarrage avec un nouveau noyau, un module de stockage peut manquer ou un montage expirer. Le df -h de l'étape 6 est là précisément pour ça ; une application qui démarre avec un répertoire de données vide est pire qu'une application qui ne démarre pas.
• Noyaux cloud et le métapaquet. Sur les images AWS/Azure/GCP, le métapaquet s'appelle linux-image-aws (etc.). Installer linux-image-generic sur une telle image vous donne un noyau sans les pilotes cloud.
• apt autoremove qui retire le noyau en cours. Impossible — apt protège le noyau en cours. Mais il peut retirer l'ancien noyau que vous vouliez comme repli. Lancez autoremove après l'étape 6, pas avant.
• Deux mises à jour en même temps. Noyau + glibc + systemd dans le même redémarrage : si quelque chose casse, vous ne savez pas quoi. En cas de doute, le reste d'abord, puis le noyau.
• Redémarrages à l'insu de la supervision. Un redémarrage à 03:00 de deux minutes génère des alertes « hôte down ». Définissez une fenêtre de maintenance dans votre supervision, ou acceptez l'alerte et documentez-la.

Ce qu'il vous manque encore

• L'ordre sur la flotte. Redémarrer quatorze serveurs dans le bon ordre (réplicas avant primaires, load balancers en dernier, jamais deux nœuds de la même paire en même temps) est un runbook que quelqu'un exécute à la main.
• L'approbation et la séparation des rôles. Qui a décidé que ce noyau passait en production aujourd'hui, et qui l'a exécuté ? Pour un audit NIS2 ou ISO, ce doivent être démontrablement deux étapes, datées.
• La corrélation avec ce qui suit. Le redémarrage de 03:00 et la base de données lente de 08:00 sont liés, mais ce lien est dans deux logs.

Comment monsys fait

Dans monsys, vous planifiez les mises à jour du noyau comme un lot sur un groupe d'hôtes : le hub connaît par hôte le noyau en cours et installé, reboot_required, les relations de failover (jamais les deux nœuds d'une paire en même temps) et la fenêtre de maintenance du groupe. Un lot proposé par l'assistant IA ou un client MCP doit être approuvé par une autre personne (séparation des tâches, imposée dans la base de données), et chaque étape — proposition, approbation, exécution par hôte, résultat — est une ligne signée dans le transparency log. L'exécution elle-même passe par des Emergency Action Tokens avec UpdateKernel et Reboot comme actions ; un hôte qui ne revient pas après le redémarrage met le lot en pause.

FAQ

Combien de temps dure un redémarrage de noyau ?

Sur un VPS, 30–90 secondes entre reboot et un SSH fonctionnel. Sur bare metal avec beaucoup de mémoire et un POST BIOS, jusqu'à cinq minutes. Comptez quinze minutes dans votre fenêtre, vérification comprise ; que vous n'en ayez généralement besoin que de trois est un bonus.

Puis-je annuler une mise à jour du noyau ?

Oui, tant que l'ancien noyau est encore dans /boot : choisissez-le dans le menu GRUB ou avec grub-reboot, et remettez-le par défaut avec grub-set-default. C'est pourquoi vous gardez toujours au moins deux noyaux et ne lancez apt autoremove qu'après une vérification réussie.

Dois-je redémarrer à chaque mise à jour du noyau ?

Pour faire tourner le nouveau noyau : oui. Que ce soit urgent dépend des CVE que corrige la mise à jour et de leur applicabilité à votre configuration. Vérifiez cela d'abord ; planifiez le reste dans votre fenêtre de maintenance habituelle.