Un apt update ou apt upgrade qui plante avec un message « no space left on device » alors que votre disque affiche encore plusieurs dizaines de gigas libres, c’est le grand classique du sysadmin Linux qui panique pour rien. Le coupable n’est presque jamais le disque dur dans son ensemble, mais une toute petite partition dédiée : /boot. Et la solution la plus tentante, celle où on va supprimer des fichiers à la main dans ce dossier, est justement celle qui va transformer un système un peu encombré en système qui ne démarre plus du tout.
À retenir
- Pourquoi /boot se remplit progressivement sans que le reste du disque ne bouge
- Pourquoi le réflexe de rm ne fonctionne pas et peut carrément casser le démarrage
- La procédure exacte pour libérer de l’espace sans contourner le gestionnaire de paquets
Pourquoi /boot se remplit alors que le reste du disque respire
Sur Debian, Ubuntu et toutes leurs dérivées, /boot est souvent une petite partition à part, séparée du reste du système. Elle stocke les images de noyau (vmlinuz), les initrd et la configuration GRUB. Le souci, c’est qu’à chaque mise à jour du noyau, l’ancien n’est pas systématiquement supprimé : il reste en place comme filet de sécurité, au cas où le nouveau poserait problème au redémarrage. Ubuntu garde plusieurs versions du noyau installées comme filet de sécurité, si un nouveau noyau pose problème vous pouvez redémarrer sur un ancien, et par défaut les deux ou trois dernières versions sont conservées après chaque mise à jour du noyau.
Le problème, c’est que ces filets de sécurité coûtent cher en espace. La partition /boot fait généralement entre 500 Mo et 1 Go, et chaque version de noyau pèse environ 50 à 100 Mo. Faites le calcul : sur une machine qui tourne depuis deux ou trois ans sans nettoyage, il n’est pas rare de retrouver cinq, dix, voire une vingtaine de noyaux qui traînent, chacun avec son image, son initrd et ses modules. Un utilisateur signalait même sur un forum avoir accumulé 26 différents noyaux sans que rien ne se supprime automatiquement. Résultat : la partition se retrouve à 100%, et paradoxalement, c’est justement apt qui a besoin d’écrire dans /boot pour installer le nouveau noyau ou pour nettoyer les anciens qui se retrouve bloqué. Le /boot est plein, mais il contient de vieux noyaux et le noyau actuel, et apt-get n’arrive jamais à faire le ménage parce que la partition /boot est pleine. C’est un cercle vicieux savoureux : pour libérer de la place, il faudrait que le gestionnaire de paquets fasse son travail, mais il ne peut pas le faire faute de place.
Concrètement, ça se traduit par des erreurs assez cryptiques dans le terminal, du genre dpkg: error processing archive… failed to write (No space left on device), suivies de messages sur des dépendances non satisfaites qui n’ont, en apparence, rien à voir avec un problème de disque. Quelqu’un utilisant apt-get à chaque fois voit son installation échouer parce que le système essaie d’écrire dans cette partition. Beaucoup de gens tapent alors df -i pour vérifier les inodes en pensant à un autre souci, avant de réaliser que le taux de remplissage de /boot spécifiquement est le vrai responsable.
La fausse bonne idée : supprimer des fichiers dans /boot à la main
Face à un ls -lhS /boot qui affiche des initrd.img de 40 Mo chacun, la tentation est grande de sortir la commande rm et de virer directement les plus anciens fichiers pour respirer. C’est exactement le piège. Un témoignage sur un forum résume bien la situation : après avoir déplacé quelques fichiers vers /tmp juste pour que ça fonctionne, cela a causé encore plus d’espace utilisé, l’opération ayant en réalité aggravé le problème plutôt que de le résoudre.
La raison est simple : le système de paquets Debian, via dpkg, tient un registre précis de chaque fichier appartenant à chaque paquet installé. Si vous supprimez à la main un vmlinuz ou un initrd.img, dpkg continue de croire que ce fichier existe et que le paquet correspondant est intact. La configuration GRUB, elle aussi, garde une entrée de démarrage pointant vers un fichier qui n’existe plus, ce qui peut produire un menu de boot fantôme, voire un système qui refuse carrément de démarrer si vous avez eu la mauvaise idée de toucher au noyau actuellement utilisé. Une règle d’or à graver quelque part : ne jamais retirer le noyau en cours d’exécution. Vérifiez toujours avec uname -r avant de toucher à quoi que ce soit dans /boot.
La bonne méthode, celle qui respecte la base de données de paquets
La démarche propre consiste à laisser dpkg et apt gérer eux-mêmes la suppression, plutôt que de contourner le système. Sur les distributions récentes, un simple apt autoremove --purge suffit généralement, puisque les noyaux et en-têtes obsolètes sont automatiquement marqués comme n’étant plus nécessaires et peuvent donc être purgés avec cette seule commande. Mais quand la partition est déjà à 100% et que la commande plante en cours de route, il faut procéder différemment, en libérant juste assez d’espace pour que dpkg puisse reprendre la main proprement.
La technique recommandée consiste à purger directement, via dpkg, un ou deux paquets de noyau précis (jamais le noyau actif), plutôt que de supprimer des fichiers bruts. Comme l’explique une ressource technique sur le sujet, il faut retirer le fichier init du noyau avec update-initramfs -d, puis purger le noyau et son paquet modules-extra associé avec dpkg –purge, en respectant l’ordre des dépendances pour éviter un échec. Cette suppression passe par le gestionnaire de paquets, donc le registre dpkg reste cohérent, contrairement à un rm sauvage. Une fois qu’un peu de marge est récupérée, on relance apt-get -f install pour réparer l’état, puis apt autoremove --purge pour finir le nettoyage des noyaux restants, et enfin update-grub pour que le menu de démarrage colle exactement à la réalité du disque.
Un détail qui change tout au quotidien : sur Ubuntu, les mises à jour automatiques sont censées éviter ce scénario en amont, puisque unattended-upgrades devrait être activé par défaut à partir d’Ubuntu 16.04, avec un nettoyage régulier des anciens noyaux. Si votre /boot déborde malgré tout, c’est souvent le signe que ce service a été désactivé, ou que la machine a été laissée sans redémarrage ni mise à jour pendant de longs mois. Un petit systemctl status unattended-upgrades de temps en temps vous évitera bien des sueurs froides le jour où vous aurez vraiment besoin d’installer un paquet en urgence.
Sources : silvae86.github.io | nicolasbouliane.com