Mise à jour du noyau Linux : un guide complet par distribution

Le noyau Linux est la couche fondamentale entre votre matériel et chaque processus s’exécutant sur votre système. Il gère la planification CPU, l’allocation mémoire, les pilotes de périphériques, les appels système et l’application des politiques de sécurité. Le maintenir à jour n’est pas facultatif pour les systèmes en production — les noyaux obsolètes exposent les serveurs à des exploits d’escalade de privilèges, des vulnérabilités de corruption mémoire et des régressions de performances que les versions plus récentes résolvent.

Ce guide fournit des instructions exhaustives et techniquement précises pour mettre à jour le noyau Linux sur Ubuntu, Debian, CentOS, RHEL et Arch Linux — incluant la configuration du chargeur d’amorçage, la régénération de l’initramfs, l’épinglage de version et les procédures de retour arrière que la plupart des guides omettent entièrement.

Pourquoi les mises à jour du noyau sont une tâche de maintenance critique

Chaque version du noyau traite une combinaison de correctifs de sécurité (CVE), d’améliorations de compatibilité matérielle, d’optimisations du planificateur et de nouvelles capacités de système de fichiers ou de réseau. Les conséquences de l’exécution d’un noyau obsolète incluent :

• CVE non corrigés : Les vulnérabilités comme Dirty COW (CVE-2016-5195), les atténuations Spectre/Meltdown et les bugs d’escalade de privilèges plus récents sont des problèmes au niveau du noyau qu’aucun outil de sécurité au niveau applicatif ne peut pleinement compenser.
• Dégradation des performances : Les noyaux plus anciens manquent d’améliorations apportées au planificateur CFS, à la compaction mémoire et à la gestion de la profondeur de file d’attente NVMe qui affectent directement le débit du serveur.
• Incompatibilité de pilotes : Le nouveau matériel, notamment les contrôleurs NVMe modernes et les adaptateurs réseau, peut nécessiter des versions du noyau qui exposent des interfaces de pilotes mises à jour.
• Prise en charge manquante des appels système : Les environnements d’exécution de conteneurisation (Docker, Podman, containerd) et les frameworks de sécurité (eBPF, seccomp) dépendent de fonctionnalités du noyau introduites dans des versions spécifiques.

Dans un environnement d’hébergement VPS, le noyau régit également l’efficacité avec laquelle le système d’exploitation invité interagit avec l’hyperviseur — ce qui signifie qu’un noyau actuel avec des pilotes virtio à jour et la prise en charge de la paravirtualisation se traduit directement par une latence plus faible et un meilleur débit I/O.

Avant de commencer : liste de contrôle pré-mise à jour

Quelle que soit la distribution, exécutez ces étapes avant de toucher au noyau :

1. Créez un instantané ou une sauvegarde de votre système. Si votre fournisseur prend en charge les instantanés, prenez-en un maintenant. Sur du matériel physique, assurez-vous que votre sauvegarde est à jour.
2. Vérifiez votre version actuelle du noyau : uname -r
3. Vérifiez l’espace disque disponible dans /boot : df -h /boot — une partition /boot pleine fera échouer silencieusement les installations du noyau sur les systèmes basés sur Debian.
4. Confirmez votre chargeur d’amorçage : ls /boot | grep -E 'grub|efi' — savoir si vous utilisez GRUB2, systemd-boot ou GRUB legacy change les étapes post-installation.
5. Vérifiez les paquets retenus ou épinglés : Sur Debian/Ubuntu, exécutez apt-mark showhold. Sur RHEL/CentOS, vérifiez /etc/yum.conf pour exclude=kernel*.
6. Assurez-vous d’avoir accès à la console. Si le nouveau noyau ne démarre pas, SSH sera indisponible. Assurez-vous d’avoir un accès hors bande (VNC, IPMI ou la console d’urgence de votre fournisseur) avant de redémarrer.

Mise à jour du noyau sur Ubuntu et Debian

Ubuntu et Debian utilisent le gestionnaire de paquets APT et fournissent les images du noyau sous forme de paquets standard selon la convention de nommage linux-image-*. Le noyau, ses modules et l’initramfs sont tous gérés via ce système, ce qui rend les mises à jour relativement simples — mais il existe des nuances importantes.

Étape 1 : Synchroniser les dépôts de paquets

sudo apt update

Cela actualise l’index local des paquets par rapport à tous les dépôts configurés. Ne sautez pas cette étape — exécuter apt upgrade sans un apt update préalable peut installer des versions de paquets obsolètes.

Étape 2 : Appliquer la mise à niveau complète du système

sudo apt upgrade

Cela met à niveau les paquets installés mais n’installera pas un nouveau noyau si cela nécessite la suppression de paquets existants. Pour les transitions de noyau (par exemple, passer de 5.15 à 6.1), utilisez :

sudo apt full-upgrade

L’ancienne commande dist-upgrade est fonctionnellement équivalente à full-upgrade et reste disponible, mais full-upgrade est la forme canonique actuelle.

Étape 3 : Installer le métapaquet du noyau

sudo apt install linux-image-generic linux-headers-generic

Le métapaquet (linux-image-generic) suit toujours le dernier noyau recommandé pour votre architecture. L’installer explicitement garantit que le gestionnaire de paquets sait que vous souhaitez des mises à jour du noyau à l’avenir. Le paquet linux-headers-generic est requis si vous compilez des modules de noyau externes (par exemple, des pilotes gérés par DKMS comme ZFS ou des pilotes GPU propriétaires).

Pour les systèmes Ubuntu, vous pouvez également installer des noyaux HWE (Hardware Enablement), qui rétroportent des noyaux plus récents vers les versions LTS :

sudo apt install linux-generic-hwe-22.04

Étape 4 : Vérifier que le nouveau noyau est en attente

dpkg --list | grep linux-image

Vous devriez voir la nouvelle version du noyau listée avec le statut ii (installé). L’ancien noyau reste installé comme solution de repli — c’est intentionnel.

Étape 5 : Redémarrer et confirmer

sudo reboot

Après reconnexion :

uname -r

Confirmez que la sortie reflète la nouvelle version du noyau.

Nettoyage des anciens noyaux sur Debian/Ubuntu

Les anciens noyaux s’accumulent dans /boot et consomment de l’espace disque. Supprimez-les en toute sécurité avec :

sudo apt autoremove --purge

APT identifie automatiquement les paquets de noyau remplacés et les supprime, mais uniquement s’ils ne sont pas le noyau en cours d’exécution ou la solution de repli la plus récente.

Piège critique : Ne supprimez jamais manuellement le paquet du noyau en cours d’exécution. Redémarrez toujours dans le nouveau noyau en premier, puis exécutez autoremove.

Mise à jour du noyau sur CentOS et RHEL

CentOS et RHEL utilisent la gestion de paquets basée sur RPM — soit yum (CentOS 7, RHEL 7) soit dnf (CentOS 8+, RHEL 8+, AlmaLinux, Rocky Linux). Le processus de mise à jour du noyau diffère des systèmes basés sur Debian sur un point important : les systèmes RPM conservent plusieurs versions du noyau installées simultanément par défaut, contrôlé par la directive installonly_limit dans /etc/yum.conf ou /etc/dnf/dnf.conf.

Étape 1 : Mettre à jour tous les paquets y compris le noyau

# CentOS 7 / RHEL 7
sudo yum update

# CentOS 8+ / RHEL 8+ / AlmaLinux / Rocky Linux
sudo dnf update

Cette commande unique gère la mise à jour du noyau dans la plupart des cas. Contrairement à Debian, il n’existe pas d’équivalent séparé à dist-upgrade — yum update / dnf update gère automatiquement la résolution des dépendances pour les transitions de noyau.

Étape 2 : Installer une version spécifique du noyau (optionnel)

Si vous avez besoin d’une version spécifique du noyau plutôt que la dernière disponible :

sudo yum install kernel-<version>
# Example:
sudo yum install kernel-5.14.0-284.30.1.el9_2

Étape 3 : Régénérer la configuration GRUB2

Sur les systèmes RHEL/CentOS, la configuration du chargeur d’amorçage doit être explicitement régénérée pour inclure la nouvelle entrée du noyau. La commande correcte dépend de si votre système utilise BIOS ou UEFI :

Systèmes basés sur BIOS :

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Systèmes basés sur UEFI :

sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
# or for CentOS/AlmaLinux/Rocky:
sudo grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

Important : Sur RHEL 8+ et ses dérivés, l’étape grub2-mkconfig est souvent gérée automatiquement par les scriptlets du paquet kernel-core via grubby. Vous pouvez vérifier l’entrée de démarrage par défaut avec :

sudo grubby --default-kernel

Pour définir manuellement le noyau par défaut :

sudo grubby --set-default /boot/vmlinuz-<new-version>

Étape 4 : Redémarrer et vérifier

sudo reboot
uname -r

Gestion de la rétention des noyaux sur RHEL/CentOS

Par défaut, installonly_limit=3 dans /etc/dnf/dnf.conf conserve les trois noyaux les plus récents. Ajustez cette valeur si l’espace disque dans /boot est limité :

sudo sed -i 's/installonly_limit=3/installonly_limit=2/' /etc/dnf/dnf.conf

Pour lister tous les noyaux installés :

rpm -q kernel

Mise à jour du noyau sur Arch Linux

Arch Linux suit un modèle de publication continue, ce qui signifie que le noyau est mis à jour en continu au fur et à mesure que de nouvelles versions amont sont publiées. Il n’y a pas de versions discrètes — le système évolue toujours vers le dernier noyau stable. Cela rend Arch idéal pour les développeurs qui ont besoin de fonctionnalités de noyau de pointe, mais cela nécessite une maintenance plus attentive.

Étape 1 : Synchronisation complète du système et mise à niveau

sudo pacman -Syu

Le drapeau -S synchronise les paquets, -y actualise la base de données et -u met à niveau tous les paquets installés. Sur Arch, vous devriez toujours effectuer une mise à niveau complète du système plutôt que de mettre à niveau des paquets individuels de manière isolée — les mises à niveau partielles sont explicitement non prises en charge et peuvent provoquer des ruptures de dépendances de bibliothèques.

Étape 2 : Installer ou réinstaller le paquet du noyau

Si le noyau n’a pas été mis à jour par pacman -Syu (par exemple, vous changez de variante de noyau), installez-le explicitement :

sudo pacman -S linux linux-headers

Arch Linux propose plusieurs variantes officielles du noyau :

Pour les environnements serveur, linux-lts est généralement préférable — il fournit un ABI stable pour les modules DKMS et réduit la fréquence des redémarrages requis par les mises à jour du noyau.

Étape 3 : Régénérer l’initramfs

sudo mkinitcpio -p linux

Cela régénère le système de fichiers RAM initial en utilisant le préréglage défini dans /etc/mkinitcpio.d/linux.preset. L’initramfs contient l’environnement minimal nécessaire pour monter le système de fichiers racine avant que le système d’exploitation complet ne prenne le relais. Sauter cette étape après une mise à jour du noyau peut entraîner un système qui ne démarre pas si le système de fichiers racine nécessite un module (par exemple, ext4, btrfs, ou un volume chiffré via dm-crypt).

Si vous avez installé linux-lts, utilisez le préréglage correspondant :

sudo mkinitcpio -p linux-lts

Étape 4 : Mettre à jour la configuration du chargeur d’amorçage GRUB

sudo grub-mkconfig -o /boot/grub/grub.cfg

Notez que sur Arch, la commande est grub-mkconfig (sans le suffixe 2), contrairement à RHEL/CentOS. Si vous utilisez systemd-boot au lieu de GRUB (courant sur les installations Arch UEFI), mettez à jour l’entrée de démarrage manuellement ou exécutez :

sudo bootctl update

Étape 5 : Redémarrer

sudo reboot
uname -r

Comparaison des distributions : mécanismes de mise à jour du noyau

Retour arrière du noyau : que faire quand un nouveau noyau casse votre système

Une mise à jour du noyau qui provoque des échecs de démarrage ou une incompatibilité matérielle est un risque opérationnel réel. Voici la procédure de récupération :

Étape 1 : Accédez au menu GRUB au démarrage. Si GRUB est masqué (courant sur les environnements VPS), maintenez ou appuyez à plusieurs reprises sur Shift (BIOS) ou Esc (UEFI) pendant le démarrage, ou configurez GRUB_TIMEOUT dans /etc/default/grub à une valeur non nulle avant la mise à jour.

Étape 2 : Sélectionnez « Options avancées » et choisissez la version précédente du noyau dans la liste.

Étape 3 : Une fois démarré dans le noyau fonctionnel, soit :

• Épinglez le noyau fonctionnel pour empêcher sa suppression (Debian/Ubuntu : sudo apt-mark hold linux-image-<version>)
• Définissez-le comme entrée de démarrage par défaut (RHEL : sudo grubby --set-default /boot/vmlinuz-<version>)
• Supprimez le noyau problématique (Arch : sudo pacman -R linux suivi de la réinstallation de la variante LTS)

Étape 4 : Déposez un rapport de bug auprès de l’équipe du noyau de votre distribution ou consultez les trackers de bugs du noyau amont avant de retenter la mise à jour.

Mises à jour du noyau dans les environnements conteneurisés et virtualisés

Dans un environnement d’hébergement VPS, le processus de mise à jour du noyau a une considération supplémentaire : vous mettez à jour le noyau invité, pas le noyau de l’hyperviseur hôte. C’est standard et attendu — le système d’exploitation invité exécute son propre noyau dans un contexte paravirtualisé ou entièrement virtualisé.

Cependant, sur les plateformes VPS basées sur des conteneurs (OpenVZ, LXC sans espace de noms du noyau), l’invité peut partager le noyau hôte. Dans ces cas, uname -r reflète la version du noyau hôte, et tenter d’installer un nouveau paquet de noyau à l’intérieur du conteneur ne changera pas le noyau en cours d’exécution — bien que l’installation du paquet elle-même soit inoffensive.

Sur l’infrastructure VPS basée sur KVM (qui est la norme pour les fournisseurs modernes), vous avez un contrôle total sur le noyau. Assurez-vous que votre noyau mis à jour inclut les pilotes virtio compilés ou disponibles en tant que modules — spécifiquement virtio_net, virtio_blk et virtio_scsi — pour maintenir la connectivité réseau et stockage après le redémarrage.

Pour les charges de travail nécessitant des performances I/O brutes maximales — telles que les serveurs de bases de données ou les pipelines d’inférence ML — envisagez d’associer les mises à jour du noyau à un environnement de serveurs dédiés où vous avez un contrôle total du matériel et aucune surcharge d’hyperviseur.

Avancé : installation de noyaux mainline ou personnalisés

Pour les utilisateurs qui ont besoin de fonctionnalités du noyau pas encore rétroportées vers le noyau stable de leur distribution, les noyaux mainline peuvent être installés depuis les sources ou via des outils spécifiques à la distribution.

Installateur de noyau mainline Ubuntu :

# Using the mainline tool (third-party PPA)
sudo add-apt-repository ppa:cappelikan/ppa
sudo apt update
sudo apt install mainline
mainline install-latest

Compilation depuis les sources (toutes distributions) :

# Download from kernel.org
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.x.y.tar.xz
tar -xf linux-6.x.y.tar.xz
cd linux-6.x.y
cp /boot/config-$(uname -r) .config
make olddefconfig
make -j$(nproc)
sudo make modules_install
sudo make install

La compilation depuis les sources vous donne un contrôle précis sur la configuration du noyau — activation ou désactivation de sous-systèmes spécifiques, application de correctifs personnalisés ou activation de fonctionnalités expérimentales. Cela est particulièrement pertinent pour les charges de travail d’hébergement GPU où des paramètres de noyau personnalisés pour la compatibilité des pilotes NVIDIA ou la configuration IOMMU peuvent être requis.

Automatisation des mises à jour du noyau en toute sécurité

Les mises à jour automatiques du noyau sont une capacité à double tranchant. Elles réduisent la fenêtre d’exposition aux CVE connus mais introduisent le risque d’un redémarrage non surveillé dans un état de noyau défaillant.

Ubuntu/Debian — unattended-upgrades :

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Modifiez /etc/apt/apt.conf.d/50unattended-upgrades pour inclure ou exclure les paquets du noyau :

Unattended-Upgrade::Package-Blacklist {
    // "linux-image";  // Uncomment to exclude kernel updates
};

RHEL/CentOS — dnf-automatic :

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Configurez /etc/dnf/automatic.conf pour définir apply_updates = yes uniquement après avoir validé votre stratégie de retour arrière.

Bonne pratique pour la production : Appliquez les mises à jour de sécurité du noyau automatiquement, mais planifiez les redémarrages via une fenêtre de maintenance en utilisant des outils comme needrestart ou kured (Kubernetes Reboot Daemon pour les charges de travail conteneurisées).

Matrice de décision et points clés à retenir

Utilisez cette liste de contrôle avant et après chaque mise à jour du noyau :

• Instantané ou sauvegarde complété avant de commencer
• Version actuelle du noyau documentée (uname -r)
• La partition /boot dispose d’un espace libre suffisant (df -h /boot)
• Accès console/hors bande confirmé et testé
• Délai d’attente GRUB défini à une valeur non nulle pour permettre un démarrage de récupération
• Nouveau noyau installé et vérifié dans le gestionnaire de paquets
• initramfs régénéré (critique sur Arch ; à vérifier sur toutes les distributions)
• Configuration GRUB régénérée si nécessaire (RHEL, Arch)
• Système redémarré et nouvelle version du noyau confirmée (uname -r)
• Anciens paquets du noyau nettoyés après confirmation de la stabilité
• Version du noyau documentée dans le journal des modifications ou le système de surveillance
• Pour les modules DKMS (ZFS, pilotes propriétaires) : modules reconstruits et vérifiés

Quand utiliser les noyaux LTS par rapport au dernier stable :

• Serveurs de bases de données en production, serveurs web, infrastructure de messagerie : Utilisez les noyaux LTS. La stabilité et un ABI prévisible pour les modules du noyau l’emportent sur l’accès aux fonctionnalités les plus récentes. Si vous exploitez des stacks d’hébergement de messagerie ou d’hébergement web mutualisé, LTS est le bon choix.
• Environnements de développement, nœuds de calcul GPU, réseau de périphérie : Utilisez le dernier noyau stable pour accéder aux nouvelles capacités eBPF, aux algorithmes de planificateur mis à jour et à la prise en charge matérielle actuelle.
• Environnements critiques pour la sécurité : Envisagez linux-hardened (Arch) ou RHEL avec la correction à chaud du noyau (kpatch) pour appliquer les correctifs CVE sans redémarrer.

Pour les environnements où la terminaison SSL/TLS et la gestion des certificats font partie de la pile, gardez à l’esprit que la prise en charge du TLS au niveau du noyau (ktls) — disponible dans les noyaux 4.13+ — peut décharger le chiffrement des enregistrements TLS vers le noyau, réduisant la charge CPU. Associez cela à des certificats SSL correctement gérés pour une posture de sécurité complète.

FAQ

Q : La mise à jour du noyau va-t-elle casser mes applications en cours d’exécution ?

R : La mise à jour du noyau elle-même n’affecte pas les processus en cours d’exécution — ils continuent d’utiliser l’ancien noyau jusqu’au redémarrage. Après le redémarrage dans le nouveau noyau, les applications qui dépendent de modules du noyau compilés contre l’ancienne version (par exemple, les modules DKMS comme ZFS ou VirtualBox) peuvent ne pas se charger. Vérifiez toujours l’état des modules DKMS avec dkms status avant de redémarrer.

Q : Comment vérifier quelle version du noyau est disponible avant de l’installer ?

R : Sur Debian/Ubuntu : apt-cache show linux-image-generic | grep Version. Sur RHEL/CentOS : dnf info kernel. Sur Arch : pacman -Si linux | grep Version. Cela vous permet d’évaluer la mise à jour avant de vous engager.

Q : Puis-je mettre à jour le noyau sur un VPS sans accès à la console ?

R : Techniquement oui, mais c’est fortement déconseillé. Si le nouveau noyau ne démarre pas, vous perdrez l’accès SSH sans aucune possibilité de récupération. Confirmez toujours que votre fournisseur VPS propose une console d’urgence (VNC ou série) avant d’effectuer des mises à jour du noyau à distance.

Q : Quelle est la différence entre apt upgrade et apt full-upgrade pour les mises à jour du noyau ?

R : apt upgrade n’installera pas un nouveau noyau si cela nécessite la suppression d’un paquet actuellement installé. apt full-upgrade (anciennement dist-upgrade) résout ces conflits en permettant la suppression de paquets si nécessaire — cela est généralement requis lors de la transition entre des versions majeures du noyau sur Debian/Ubuntu.

Q : Comment empêcher une version spécifique du noyau d’être automatiquement mise à jour ?

R : Sur Debian/Ubuntu, utilisez sudo apt-mark hold linux-image-<version>. Sur RHEL/CentOS, ajoutez exclude=kernel-<version> à /etc/dnf/dnf.conf ou utilisez dnf versionlock add kernel-<version> après avoir installé le paquet python3-dnf-plugin-versionlock. Sur Arch, ajoutez le paquet à IgnorePkg dans /etc/pacman.conf.