Supprimer les anciens kernels Ubuntu et libérer /boot

Pourquoi apt cesse de fonctionner lorsque /boot se remplit 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 pleine, et apt ne peut plus terminer l’installation. La réparation se fait en 2 étapes. Déterminez quels packages installés 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 à ne surtout pas supprimer. Le serveur 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 noyau installe deux fichiers volumineux dans /boot : le noyau compressé (vmlinuz-<version>) et l’initramfs (système de fichiers RAM initial, initrd.img-<version>, la petite archive que le noyau 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 nécessite de l’espace libre, et pas seulement de la bande passante pour le téléchargement. S’il ne reste plus de place, la génération échoue et l’installation du paquet échoue à son tour.

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 vient de COMPRESS= dans /etc/initramfs-tools/initramfs.conf. Ainsi, une image récente peut utiliser le nom zstd, tandis qu’une ancienne utilise gzip. Les deux lignes qui identifient ce problème sont No space left on device et la ligne dpkg: error processing package située en dessous.

Ensuite, le paquet reste partiellement configuré. Chaque nouvelle exécution 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 correctifs de sécurité. Cela signifie également que toute installation sans rapport que vous tentez échoue avec la même ligne, et que la responsabilité semble revenir à ce que vous étiez en train d’ajouter. C’est pourquoi l’installation de Tailscale qui échoue sur Ubuntu mérite d’abord d’être analysée comme une erreur apt. Si apt update échoue avant que vous n’en arriviez là, 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, vérifiez ce que vous allez réellement libérer.

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

La première commande n’affiche une ligne que 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 seul : votre système de fichiers racine est plein, et les anciens noyaux 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 n’y libère absolument aucun espace, car le cache se trouve sur un autre système de fichiers.

Récupérez maintenant la valeur de référence à utiliser.

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

Comparez la colonne Avail à la taille de ces deux fichiers. L’initrd est le plus volumineux. La prochaine mise à jour du noyau devra disposer d’un espace suffisant pour une autre paire de taille à peu près équivalente. Si Avail est plus petit que l’initrd actuel, la prochaine mise à jour va déjà échouer.

Identifier le noyau en cours d’exécution

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

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

Le deuxième fichier n’existe que lorsqu’un paquet demande un redémarrage. Une ligne linux-image indique qu’un noyau 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 noyau en cours d’exécution et le plus récent. Effectuer le nettoyage avec un ancien noyau en cours d’exécution conserve donc une version épinglée de plus que nécessaire.

Lister les paquets du kernel et consulter leur état

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

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

Le deuxième champ indique le type de paquet. Un nom qui contient une version, comme linux-image-6.8.0-64-generic, désigne un kernel 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 kernel. Son seul rôle est de dépendre du kernel le plus récent portant un numéro de version, afin que apt upgrade installe les nouveaux kernels. La suppression d’un meta package empêche la machine de recevoir les mises à jour du kernel, sans aucun avertissement ultérieur.

Les familles se répartissent comme suit. linux-image-* contient l’image compressée du kernel dans /boot. linux-modules-* et linux-modules-extra-* contiennent les drivers 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’image du kernel 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 résidu laissé par une suppression manuelle de fichiers.

Comment apt détermine les noyaux à conserver

apt autoremove ne supprimera pas un noyau qu’il considère comme protégé. L’ensemble des noyaux protégés inclut le noyau actuellement utilisé. La stratégie de conservation a changé selon les versions d’Ubuntu. Consultez-la donc sur votre propre machine au lieu de vous fier à un nombre noté 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 contient la liste des motifs de noms de paquets auxquels apt autoremove refuse de toucher. APT::VersionedKernelPackages contient 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 installation d’un paquet de noyau. Le modifier manuellement ne sert donc à rien : l’installation du noyau suivant écrasera vos modifications. 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 actuellement en vigueur sur votre machine. Cette sortie est la réponse correcte pour votre version.

Nettoyage que vous pouvez exécuter 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 arrêter. Un méta-paquet tel que linux-generic ou linux-image-generic dans la liste des suppressions signifie qu’un élément l’a marqué comme installé automatiquement. Sa suppression interromprait les mises à jour du kernel. La chaîne fournie 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 arriver. Vous devez rechercher la cause avant d’aller plus loin.

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

sudo apt autoremove --purge
df -h /boot

La partie --purge supprime également la configuration restante, en plus du paquet. Elle libère peu d’espace supplémentaire, mais évite l’accumulation de lignes rc dans dpkg --list, ce qui facilite le prochain audit.

Vérifiez ensuite que le menu de démarrage a été reconstruit. La suppression d’un paquet de kernel exécute update-grub automatiquement. Le menu ne devrait donc référencer que 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 de 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 bien 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 automatiques, 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 manuel. autoremove ne le supprimera donc jamais, même s’il est très ancien.

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

Toutes les versions du kernel affichées dans cette sortie sont ignorées par autoremove. Réinstallez leur statut automatique 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 manuels. Ils doivent l’être, car ce sont les paquets que vous avez demandé d’installer.

Supprimer volontairement un noyau donné

Il peut être nécessaire de supprimer immédiatement une version précise, sans attendre l’application de la politique de nettoyage. Indiquez le paquet d’image concerné 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 modification, car linux-modules-extra-* dépend du paquet d’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 un paquet méta qui serait supprimé avec la version ciblée. 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 plus de raison d’être.

Pourquoi vous ne devez jamais supprimer le noyau en cours d’exécution

Le noyau déjà chargé en mémoire continue de fonctionner après la suppression de ses fichiers. Rien ne semble donc se casser immédiatement. Ce qui ne fonctionne plus, ce sont les éléments que le noyau n’a pas encore chargés. 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 pare-feu échoue lui aussi. Le montage d’un type de système de fichiers que ce noyau n’a pas utilisé depuis le démarrage échoue également. Par ailleurs, /boot/vmlinuz-$(uname -r) a disparu. Le menu de démarrage ne propose donc plus le noyau en cours d’exécution, et le prochain redémarrage démarre sur un autre noyau. La machine continue de traiter le trafic, mais elle n’est déjà plus amorçable. Vérifiez toujours uname -r par rapport à la liste des éléments à supprimer.

Quand /boot est trop plein pour qu’apt puisse fonctionner

C’est dans cet état que se trouvent les personnes qui arrivent sur cette page. apt autoremove a besoin de dpkg pour terminer la configuration du paquet du noyau partiellement configuré. Cette étape reconstruit un initramfs, qui nécessite de l’espace dans un /boot qui n’en a plus. Sortez manuellement de cette boucle, une seule fois.

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

Choisissez un initrd dont la version n’est pas la chaîne renvoyée par uname -r, puis supprimez ce fichier uniquement.

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. rm est une exception délibérée : elle 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 assez d’espace pour l’initramfs. autoremove --purge supprime ensuite le paquet correspondant au fichier supprimé, ainsi que les autres anciennes versions, ce qui remet dpkg en cohérence 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 indique que l’opération a été interrompue, sudo dpkg --configure -a effectue la même réparation que apt --fix-broken install.

Le même traitement sur les systèmes dnf

Si votre VPS utilise Fedora ou l’une des distributions reconstruites à partir 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 le déclencher avec unattended-upgrades, tandis que dnf impose un nombre appelé installonly_limit et supprime automatiquement le noyau le plus ancien dès qu’une nouvelle installation le dépasserait. Consultez la valeur en vigueur avec grep installonly_limit /etc/dnf/dnf.conf et man 5 dnf.conf, puis supprimez les anciens noyaux accumulés avec sudo dnf remove --oldinstallonly. Le noyau en cours d’exécution est également protégé. Pour le tableau de correspondance plus complet entre les deux gestionnaires de paquets, consultez les équivalents des commandes dnf et apt.

Éviter que le problème se reproduise

Une procédure de nettoyage qui dépend de votre mémoire finira par échouer. Ajoutez-la donc à l’élément qui installe les noyaux. Ouvrez /etc/apt/apt.conf.d/50unattended-upgrades et recherchez ces clés, que le fichier fourni contient déjà sous forme de lignes commentées :

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

Décommentez-les au lieu d’ajouter une deuxième copie à la fin du fichier. Dans la configuration d’apt, la dernière affectation d’une clé 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 par le parser 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 en apporte la preuve. Il enregistre chaque exécution. Une mise à niveau qui a échoué faute d’espace y apparaît donc bien avant que quelqu’un remarque que la machine n’installe plus 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 à la taille de ce fichier, l’installation du prochain noyau échouera exactement comme indiqué ci-dessus. Corrigez donc le problème maintenant, plutôt que pendant la mise à niveau. Cette vérification ne prend qu’une minute, en complément de vos 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 continuer lorsque /boot manque d’espace. Si cette mise à niveau n’est pas encore proposée sur votre serveur LTS, il s’agit d’une question de calendrier et non d’une anomalie. Ubuntu retarde les mises à niveau d’une version LTS vers la suivante jusqu’à la sortie de la version intermédiaire 26.04.1. Vous disposez ainsi d’une période connue pour mettre /boot en ordre au préalable.

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 mauvaise mise à jour depuis le menu GRUB, plutôt que depuis la console de secours du fournisseur. apt protège donc un ensemble de packages du noyau contre la suppression automatique, en incluant toujours celui que vous utilisez. Exécutez apt-config dump | grep -i neverautoremove pour afficher les motifs exacts protégés par votre version, car la règle a changé d’une version à l’autre.

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

Oui, à condition de commencer par lire la simulation. 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 packages 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, les suppressions concernent d’anciens noyaux et des dépendances orphelines.

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

Les anciens noyaux sont presque certainement marqués comme installés manuellement, et autoremove ne traite que les packages marqués comme installés automatiquement. Exécutez apt-mark showmanual | grep -E '^linux-'. Toute version de noyau listée à cet endroit a été installée manuellement à un moment donné. Marquez-la comme automatique avec sudo apt-mark auto linux-image-<version> et relancez la simulation, ou purgez directement cette version avec sudo apt purge linux-image-<version>.

Puis-je supprimer manuellement des fichiers de /boot ?

Uniquement de manière exceptionnelle et délibérée, lorsque /boot est tellement plein que apt ne peut pas configurer le package du 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 opérations de suivi laisse dpkg enregistrer des packages dont les fichiers ont disparu et laisse dans le menu GRUB des entrées qui pointent vers des fichiers inexistants. La machine échoue alors lors de son prochain redémarrage, et non au moment où vous avez commis l’erreur.