Supprimer les anciens kernels Ubuntu et libérer /boot

Pourquoi apt cesse de fonctionner lorsque /boot est rempli d’anciens kernels

Sur Ubuntu, chaque mise à jour du kernel écrit un nouvel ensemble de fichiers dans /boot et conserve les précédents. Une petite partition /boot finit donc par être remplie, et apt ne peut plus terminer l’installation. La réparation se déroule en deux étapes. Déterminez quels packages installés sur la machine sont des kernels et lequel est actuellement démarré, puis supprimez les autres avec apt autoremove --purge.

L’ordre des opérations est important. Le kernel en cours d’exécution est le package que vous ne devez pas supprimer. La machine peut déjà être dans un état où apt ne peut plus s’exécuter du tout. Commencez par établir le diagnostic.

À quoi ressemble réellement l’échec

Une version du kernel installe deux fichiers volumineux dans /boot : le kernel compressé (vmlinuz-<version>) et l’initramfs (initial RAM filesystem, initrd.img-<version>, la petite archive que le kernel décompresse avant de monter la vraie racine). L’initramfs est généré sur votre machine au moment de l’installation. C’est pourquoi l’installation a besoin d’espace libre, et pas seulement de bande passante pour le téléchargement. Lorsqu’il ne reste plus d’espace, la génération échoue et l’installation du paquet échoue avec elle.

update-initramfs: Generating /boot/initrd.img-6.8.0-64-generic
gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-6.8.0-64-generic with 1.
dpkg: error processing package linux-image-6.8.0-64-generic (--configure):
 installed linux-image-6.8.0-64-generic package post-installation script subprocess returned error exit status 1

La chaîne de version sera la vôtre. Le nom du compresseur provient de COMPRESS= dans /etc/initramfs-tools/initramfs.conf. Une image récente peut donc utiliser zstd, tandis qu’une image plus ancienne utilise gzip. Les deux lignes qui identifient ce problème sont No space left on device et la ligne dpkg: error processing package qui la suit.

Le paquet reste ensuite dans l’état « half-configured ». Chaque exécution ultérieure de apt tente de le configurer à nouveau, échoue de la même manière et se termine par E: Sub-process /usr/bin/dpkg returned an error code (1). C’est l’aspect important au-delà du manque d’espace disque : unattended-upgrades s’exécute selon sa planification, rencontre la même erreur et s’arrête. Le serveur semble fonctionner normalement, mais cesse discrètement d’appliquer les mises à jour de sécurité. Cela signifie également que toute installation indépendante que vous tentez échoue avec la même ligne, et que la cause semble venir du logiciel que vous ajoutiez à ce moment-là. C’est pourquoi l’installation de Tailscale qui échoue sur Ubuntu doit d’abord être examinée comme une erreur apt. Si apt update échoue avant d’atteindre cette étape, il s’agit d’un autre problème, souvent d’une entrée en double après la migration des sources deb822.

Vérifier si /boot est une partition distincte

Avant de supprimer quoi que ce soit, déterminez réellement ce que vous allez libérer.

findmnt /boot
findmnt -T /boot
df -h /boot /

La première commande affiche une ligne uniquement si /boot est son propre point de montage. La seconde affiche toujours une ligne et indique le système de fichiers qui contient réellement /boot. S’ils indiquent le même système de fichiers que /, alors /boot est simplement un répertoire du système de fichiers racine et ne peut pas se remplir indépendamment : votre système de fichiers racine est plein, et les anciens kernels ne sont qu’une cause parmi d’autres. Dans ce cas, sudo apt clean, qui vide les fichiers .deb téléchargés dans /var/cache/apt/archives, libère de l’espace. Sur une machine équipée d’une véritable partition /boot, apt clean ne libère aucun espace sur cette partition, car le cache se trouve sur un autre système de fichiers.

Obtenez maintenant la valeur de référence.

df -h /boot
ls -lh /boot/vmlinuz-$(uname -r) /boot/initrd.img-$(uname -r)

Comparez la colonne Avail avec la taille de ces deux fichiers. L’initrd est le plus volumineux. La prochaine mise à jour du kernel aura besoin d’espace pour une autre paire d’une taille approximativement équivalente. Si Avail est inférieur à la taille de l’initrd actuel, la prochaine mise à jour va déjà échouer.

Identifier le kernel en cours d’exécution

uname -r
cat /var/run/reboot-required.pkgs

uname -r affiche la chaîne de version du kernel actuellement chargé en mémoire. Copiez cette chaîne quelque part. C’est la seule version à ne surtout pas supprimer.

Le second fichier n’existe que lorsqu’un package a demandé un redémarrage. Une ligne linux-image indique qu’un kernel plus récent est installé sur le disque, mais n’est pas utilisé, car la machine n’a pas redémarré depuis son installation. Redémarrez avant le nettoyage si possible. apt protège le kernel en cours d’exécution et le plus récent. Ainsi, effectuer le nettoyage avec un kernel ancien conserve une version supplémentaire, sans nécessité.

Lister les paquets du noyau et consulter leur état

dpkg --list | grep -E 'linux-(image|modules|headers|tools)' | awk '{print $1, $2}'

Le premier champ contient le code d’état de dpkg. ii signifie que le paquet est installé et configuré. iF signifie qu’il est installé mais partiellement configuré, ce qui correspond exactement à l’état laissé par la mise à niveau ayant échoué ci-dessus. rc signifie qu’il a été supprimé, mais que sa configuration est toujours présente sur le disque. Cela n’occupe aucun espace dans /boot et peut être purgé sans risque.

Le deuxième champ indique le type de paquet. Un nom contenant une version, comme linux-image-6.8.0-64-generic, désigne un noyau précis. Un nom sans version, comme linux-image-generic, linux-headers-generic ou linux-generic, désigne un meta package. Il ne contient aucun noyau. Son rôle est de dépendre du noyau versionné le plus récent afin que apt upgrade installe les nouveaux noyaux. La suppression d’un meta package empêche la machine de recevoir les mises à jour du noyau, sans afficher ensuite le moindre avertissement.

Les familles se répartissent comme suit. linux-image-* contient l’image compressée du noyau dans /boot. linux-modules-* et linux-modules-extra-* contiennent les pilotes dans /lib/modules. linux-headers-* contient les headers nécessaires à la compilation dans /usr/src. La purge des headers libère donc de l’espace sur le système de fichiers root, et non dans /boot. Si le problème concerne une partition /boot pleine, ce sont les paquets d’images qu’il faut rechercher.

ls -1 /boot/vmlinuz-*
ls -1 /lib/modules/

Ces deux listes doivent correspondre entre elles et avec la sortie de dpkg --list. Un répertoire présent dans /lib/modules sans paquet installé correspondant est un reste de fichiers supprimés manuellement.

Comment apt décide quels noyaux conserver

apt autoremove ne supprimera pas un noyau qu’il considère comme protégé. L’ensemble protégé comprend le noyau actuellement utilisé. La politique de conservation a changé selon les versions d’Ubuntu. Consultez-la donc sur votre propre machine au lieu de vous fier à une valeur indiquée ailleurs.

apt-config dump | grep -i -e neverautoremove -e versionedkernel
ls -l /etc/apt/apt.conf.d/01autoremove /etc/apt/apt.conf.d/01autoremove-kernels

APT::NeverAutoRemove est la liste des motifs de noms de paquets auxquels apt autoremove refuse de toucher. APT::VersionedKernelPackages est la liste des préfixes de noms que apt considère d’abord comme des paquets de noyau versionnés. Sur les versions qui génèrent /etc/apt/apt.conf.d/01autoremove-kernels, ce fichier est réécrit par /etc/kernel/postinst.d/apt-auto-removal chaque fois qu’un paquet de noyau est installé. Le modifier manuellement ne sert donc à rien : l’installation du noyau suivant écrase votre modification. Sur les versions où le fichier est absent, apt applique la même protection en interne. Dans tous les cas, apt-config dump affiche les règles appliquées sur votre machine. Cette sortie constitue la réponse correcte pour votre version.

Nettoyage sans risque

sudo apt update
sudo apt autoremove --purge --dry-run

--dry-run ne modifie rien sur le disque et affiche exactement ce que l’exécution réelle supprimerait. Lisez la liste. Deux éléments doivent vous faire arrêter. Un meta package tel que linux-generic ou linux-image-generic dans la liste des suppressions signifie qu’un élément l’a marqué comme automatique. Sa suppression arrête les mises à jour de votre kernel. La chaîne renvoyée par uname -r dans la liste des suppressions signifie que le kernel en cours d’exécution n’est pas protégé. Cela ne devrait pas se produire. Vous devez rechercher la cause avant de continuer.

Si la liste est correcte, exécutez la commande pour de vrai.

sudo apt autoremove --purge
df -h /boot

La partie --purge supprime également la configuration restante, en plus du package. Elle libère peu d’espace supplémentaire, mais évite que dpkg --list accumule des lignes rc, ce qui rend l’audit suivant lisible.

Vérifiez ensuite que le menu de démarrage a été reconstruit. La suppression d’un package de kernel exécute update-grub pour vous. Le menu doit donc faire référence uniquement à des fichiers qui existent encore.

sudo grep -o 'vmlinuz-[^ ]*' /boot/grub/grub.cfg | sort -u
ls -1 /boot/vmlinuz-*

Chaque version de la première sortie doit apparaître dans la seconde. Une entrée du menu qui pointe vers un fichier supprimé peut transformer un serveur fonctionnel en serveur qui s’arrête à l’invite GRUB. C’est l’une des causes possibles d’un VPS qui ne redémarre pas après une mise à jour du kernel. Le problème est beaucoup plus difficile à corriger depuis une console de secours qu’à éviter ici.

Pourquoi apt autoremove ne supprime parfois rien

apt autoremove supprime uniquement les paquets marqués comme installés automatiquement, c’est-à-dire les paquets installés comme dépendances d’un autre paquet. Un kernel que vous avez installé vous-même avec apt install linux-image-6.8.0-40-generic est marqué comme installé manuellement. autoremove ne le supprimera donc jamais, même s’il est ancien.

apt-mark showmanual | grep -E '^linux-'

Toutes les versions du kernel affichées dans cette sortie sont ignorées par autoremove. Marquez-les de nouveau comme installées automatiquement en utilisant les chaînes de version de votre propre liste :

sudo apt-mark auto linux-image-6.8.0-40-generic linux-modules-6.8.0-40-generic
sudo apt autoremove --purge --dry-run

Laissez les meta packages marqués comme installés manuellement. C’est leur état attendu, car ce sont les paquets que vous avez demandé d’installer.

Supprimer volontairement un noyau précis

Vous pouvez parfois vouloir supprimer immédiatement une version précise, plutôt que d’attendre que la policy l’autorise. Indiquez le nom du paquet image et laissez apt déterminer le reste.

sudo apt purge linux-image-6.8.0-40-generic

apt affiche la liste des suppressions avant toute opération, car linux-modules-extra-* dépend du paquet image et doit être supprimé dans la même transaction. Cette liste constitue votre véritable contrôle de sécurité. Elle permet de repérer la suppression d’un meta-paquet avec la version que vous vouliez retirer. Répondez n si elle contient un élément inattendu. Exécutez ensuite sudo apt autoremove --purge pour supprimer les paquets de modules et d’en-têtes qui n’ont désormais plus de raison d’être.

Pourquoi ne faut-il jamais supprimer le kernel en cours d’exécution

Le kernel déjà chargé en mémoire continue de fonctionner après la suppression de ses fichiers. Rien ne semble donc se casser immédiatement. Le problème concerne tout ce que le kernel n’a pas encore chargé. La purge de linux-modules-$(uname -r) supprime /lib/modules/$(uname -r)/. Le chargement du module échoue alors :

modprobe: FATAL: Module nf_tables not found in directory /lib/modules/6.8.0-64-generic

À partir de là, le rechargement du firewall échoue également. Le montage d’un type de système de fichiers que ce kernel n’a pas utilisé depuis le démarrage échoue aussi. Par ailleurs, /boot/vmlinuz-$(uname -r) a disparu. Le menu de démarrage ne propose donc plus le kernel que vous utilisez. Au prochain redémarrage, la machine démarre sur un autre kernel. Elle continue de traiter le trafic, mais elle est déjà impossible à démarrer. Vérifiez systématiquement uname -r par rapport à la liste des éléments à supprimer.

Quand /boot est trop plein pour qu’apt puisse s’exécuter

C’est l’état qui amène les utilisateurs sur cette page. apt autoremove doit terminer la configuration du paquet de noyau partiellement configuré avec dpkg, et cette étape reconstruit un initramfs. Elle nécessite de l’espace dans un /boot qui n’en a plus. Rompez la boucle manuellement, une seule fois.

uname -r
ls -1 /boot/initrd.img-*

Choisissez un initrd dont la version ne correspond pas à la chaîne renvoyée par uname -r, puis supprimez ce fichier.

sudo rm /boot/initrd.img-6.8.0-40-generic
sudo apt --fix-broken install
sudo apt autoremove --purge
sudo update-grub

Chaque ligne a une raison. Le rm constitue une exception volontaire : il laisse dpkg croire qu’un fichier existe alors que ce n’est pas le cas. apt --fix-broken install termine la configuration qui a échoué, maintenant qu’il y a de la place pour l’initramfs. autoremove --purge supprime ensuite le paquet correspondant au fichier supprimé, ainsi que les autres anciennes versions, ce qui resynchronise dpkg avec le contenu du disque. update-grub reconstruit le menu à partir des fichiers réellement présents. Ne redémarrez pas entre rm et update-grub, car pendant cette période le menu peut encore pointer vers le fichier que vous venez de supprimer. Si dpkg signale que son exécution a été interrompue, sudo dpkg --configure -a effectue la même réparation que apt --fix-broken install.

Le même fonctionnement sur les systèmes utilisant dnf

Si votre VPS utilise Fedora ou l’une des distributions recompilées de RHEL, comme Rocky Linux, le mécanisme est inversé. Debian et Ubuntu protègent les noyaux avec les règles apt autoremove et vous laissent effectuer le nettoyage, ou attendent que unattended-upgrades le déclenche. De son côté, dnf impose une limite appelée installonly_limit et supprime automatiquement le noyau le plus ancien dès qu’une nouvelle installation la dépasserait. Consultez la valeur appliquée avec grep installonly_limit /etc/dnf/dnf.conf et man 5 dnf.conf, puis supprimez les anciens noyaux déjà présents avec sudo dnf remove --oldinstallonly. Le noyau en cours d’exécution est également protégé. Pour le tableau de correspondance complet entre les deux gestionnaires de paquets, consultez les équivalences entre les commandes dnf et apt.

Éviter que le problème se reproduise

Un nettoyage qui dépend de votre mémoire finira par être oublié. Configurez-le donc dans le mécanisme qui installe les noyaux. Ouvrez /etc/apt/apt.conf.d/50unattended-upgrades et recherchez ces paramètres, déjà présents sous forme de lignes commentées dans le fichier fourni :

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Décommentez-les au lieu d’ajouter une seconde copie à la fin du fichier. Dans la configuration d’apt, la dernière affectation d’un paramètre est prioritaire. Un doublon rend donc le fichier incohérent et masque la valeur réellement utilisée. Vérifiez la configuration interprétée et surveillez une exécution qui ne modifie rien :

apt-config dump | grep -i 'Unattended-Upgrade::Remove'
sudo unattended-upgrade --dry-run --debug
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Le journal constitue la preuve. Il enregistre chaque exécution. Une mise à niveau qui échoue par manque d’espace y apparaît donc bien avant que quelqu’un ne remarque que la machine n’a pas reçu les correctifs. Le reste de cette configuration est présenté dans les mises à jour de sécurité automatiques sur Ubuntu.

Avant l’installation du prochain noyau, vérifiez une valeur. Il s’agit de la même paire de commandes qu’au début de ce guide :

df -h /boot
ls -lh /boot/initrd.img-$(uname -r)

Si Avail n’est pas nettement supérieur à ce fichier, l’installation du prochain noyau échouera exactement comme décrit ci-dessus. Corrigez donc le problème maintenant, plutôt que pendant la mise à niveau. Cette vérification ne prend qu’une minute et complète vos autres contrôles de l’état du disque sur un VPS. Elle est particulièrement importante juste avant une mise à niveau de version, car le passage d’Ubuntu 24.04 à 26.04 installe rapidement un nouveau noyau et do-release-upgrade refuse de poursuivre lorsque /boot manque d’espace.

FAQ

Pourquoi Ubuntu conserve-t-il les anciens noyaux au lieu de les supprimer ?

Parce qu’un noyau qui ne démarre pas ne vous laisse aucune autre version à sélectionner. Conserver la version précédente permet de récupérer après une mise à jour défectueuse depuis le menu GRUB, plutôt que depuis la console de rescue du fournisseur. apt protège donc un ensemble de paquets de noyau contre la suppression automatique, en incluant toujours celui que vous utilisez. Exécutez apt-config dump | grep -i neverautoremove pour voir les patterns exacts protégés par votre release, car la politique a changé entre les releases.

Est-il sûr d’exécuter apt autoremove --purge sur un serveur de production ?

Oui, à condition de lire d’abord le dry run. Exécutez sudo apt autoremove --purge --dry-run, qui n’écrit rien, puis vérifiez la liste affichée. Arrêtez-vous si elle contient un meta package tel que linux-generic ou linux-image-generic, car la suppression de l’un de ces paquets bloque les futures mises à jour du noyau. Arrêtez-vous également si elle contient la chaîne de version affichée par uname -r. Si aucun de ces éléments n’apparaît, il s’agit d’anciens noyaux et de dépendances orphelines.

apt autoremove n’a rien supprimé et /boot est toujours plein. Que faire ?

Les anciens noyaux sont très probablement marqués comme installés manuellement, et autoremove ne concerne que les paquets marqués comme installés automatiquement. Exécutez apt-mark showmanual | grep -E '^linux-'. Tout noyau versionné listé à cet endroit a été installé manuellement à un moment donné. Marquez-le comme automatique avec sudo apt-mark auto linux-image-<version>, puis relancez le dry run, ou purgez directement cette version avec sudo apt purge linux-image-<version>.

Puis-je supprimer manuellement des fichiers de /boot ?

Uniquement de manière ponctuelle et délibérée, lorsque /boot est tellement plein que apt ne peut pas configurer le paquet de noyau défectueux. Supprimez un seul fichier initrd.img-<version> dont la version ne correspond pas à la sortie de uname -r, puis exécutez immédiatement sudo apt --fix-broken install, sudo apt autoremove --purge et sudo update-grub. Supprimer des fichiers sans effectuer ces étapes laisse dpkg enregistrer des paquets dont les fichiers ont disparu et laisse dans le menu GRUB des entrées pointant vers des fichiers absents. La machine échoue alors au redémarrage suivant, et non au moment où vous avez commis l’erreur.