Échec de la mise à jour / de l'installation des packages - Problèmes d'espace - Libération des inodes

Pour commencer, je mentionnerai l'histoire de la façon dont le problème est survenu et ensuite comment le résoudre.

Mon équipe est un Netbook Sony Vaio m120AL que je possède depuis environ 3 longues années avec un disque dur de 320 Go où ils coexistent Windows 7, Chakra , ma partition de travail avec Xubuntu 12.04, la partition swap, la partition / home et une partition d'informations supplémentaires avec laquelle je partage des informations Windows.

Pour ces raisons, mes partitions racine sur les deux systèmes sont considérablement petites selon la plupart des normes (environ 6 Go chacune) mais elles ne m'ont jamais posé de problème car elles sont plus que suffisantes pour tous les paquets dont j'ai besoin.

Maintenant, entrant dans la situation spécifique, il y a quelques jours en appliquant quelques mises à jour dans Xubuntu (parmi lesquels un nouveau noyau a été inclus) Je vois que le gestionnaire de mise à jour affiche une erreur disant qu'il essaie d'installer linux-image-3.2.0-51-generic mais que sa dépendance linux-headers-3.2.0-51 Il ne sera pas installé, je passe en revue l'erreur en détail et je remarque que dpkg se plaint qu'il n'y a pas d'espace disponible.

L'erreur a dit quelque chose de ce style, bien que pas identique parce que je ne l'ai pas écrit:

impossible de créer `/usr/src/linux-headers-3.2.0-43/arch/xtensa/include/asm/coprocessor.h.dpkg-new '(pendant le traitement` ./usr/src/linux-headers -3.2.0 .43-XNUMX / arch / xtensa / include / asm / coprocessor.h '): Il ne reste plus d'espace sur l'appareil

À une certaine occasion, la même chose m'est arrivée mais c'était parce que j'avais laissé plusieurs anciens noyaux s'accumuler sans les supprimer, mais cette fois je vérifie et j'ai pratiquement 600 Mb disponibles selon conky à partir de ce que je ne comprends pas, mais pour confirmer si cela peut être une erreur dans la façon dont je l'avais configuré ou similaire, je lance un df -h:

Mais j'ai encore de la place dans /!

Donc je ne me trompe pas et c'est plus qu'assez d'espace pour effectuer la mise à jour (je l'ai fait de cette façon plusieurs fois au cours de la longue année depuis que je suis avec Xubuntu) de toute façon je fais un sudo apt-se nettoyer pour nettoyer les paquets que j'ai téléchargés et réessayer, mais avec les mêmes résultats.

Je trouve toujours cela étrange mais de toute façon j'essaye de sortir / des thèmes d'icônes que j'utilise toujours et que j'ai beaucoup modifiés (Faenza y Réveillé) pour libérer plus d'espace, et ainsi finalement réussir à effectuer la mise à jour, en procédant à nouveau pour les renvoyer à /.

Cependant, l'idée restait dans ma tête que l'affaire devait aller ailleurs mais je ne savais pas laquelle. Quelques heures plus tard, lorsque j'essaye d'installer des paquets supplémentaires, j'obtiens à nouveau l'erreur susmentionnée, et encore une fois, il y avait assez d'espace libre, alors je fais mes recherches.

Une recherche internet m'amène à plusieurs fils sur les forums de ubuntu-est, mais la réponse de certains individus il y a toujours la même: vous n'avez pas assez d'espace supprimez les fichiers ou développez la partition racine, mais j'ai remarqué quelque chose en commun dans les différents threads que j'ai trouvés, toujours la partition racine qui avait de l'espace libre, mais c'était similaire au mien (~ 600-900 Mo) et la taille de la partition n'a jamais dépassé 10 Go alors j'ai fini de me convaincre que le problème devait en être un autre, et c'est ainsi que je suis arrivé au titre du post grâce à cette page, le problème est que la partition racine avait 100% des inodes utilisés.

L'utilisation des inodes peut être vue avec la commande df -je:

100% inodes utilisés

Et maintenant vient l'explication.

Les inodes sont dans le mot de Dennis Ritchie:

Un index, en raison de la structure quelque peu inhabituelle d'un système de fichiers qui stockait les informations d'accès aux fichiers sous forme de liste plate sur le disque, laissant de côté toutes les informations hiérarchiques des répertoires

et par conséquent, il peut arriver que pour un système de fichiers donné, il y ait encore de l'espace libre pour stocker les fichiers, mais il n'y a pas d'inœuds disponibles pour les indexer car il y a beaucoup de fichiers dans le système et donc de nouveaux ne peuvent pas être créés.

Le fait est que le nombre d'inodes dans une partition Ext4 ne peut pas être modifié (il existe d'autres types de systèmes tels que JFX o XFS où ce n'est pas une limitation car il est dynamique) c'est un nombre fixe qui est calculé lors de la création de la partition avec mkfs.ext4 en fonction de sa taille avec un ratio d'octets par inode selon les préférences situées dans /etc/mke2fs.conf.

Lors de l'installation du système, il est habituel d'utiliser les préférences par défaut qui incluent une relation inode = 16384, qui pour les petites partitions pourrait être trop grande et ne pas créer assez (comme dans mon cas). La seule façon de le changer est de créer / formater la partition et de la spécifier avec l'option -i.

Cependant, ce n'était pas une option pour moi, car j'ai déjà mentionné que les inodes sont liés au nombre de fichiers existants, j'ai donc utilisé le script bash suivant trouvé dans débordement de pile et qui est lié sur la page que vous avez mentionnée précédemment pour trouver quels étaient les répertoires de la partition racine avec plus de fichiers:

#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -mount -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$

Ce qui donne le résultat suivant:

Et voici les coupables!

Le numéro qui apparaît à gauche indique le nombre de fichiers présents et le chemin indique le répertoire associé, une ligne en dessous apparaît le répertoire / var / lib / dpkg / info mais comme toujours je purge mes paquets ici il n'y a rien à faire .

Cependant, si je reconnais deux problèmes, le premier et bien que le catpura ne monte pas de là, plusieurs autres entrées incluent les icônes Réveillé, donc je dois les déplacer oui ou oui, d'ailleurs cela explique pourquoi quand je l'ai fait, j'ai pu mettre à jour les paquets, puisque j'ai libéré de nombreux inodes de la partition racine lorsque je les ai déplacés, mais le problème est revenu lorsque je les ai déplacés.

Et deuxièmement, le plus grand nombre d'entrées suivant est associé aux en-têtes de plusieurs anciens noyaux, et je me rends compte que la procédure que j'utilise toujours pour éliminer les anciens noyaux n'élimine pas les en-têtes, ce que j'utilise habituellement est le suivant, dans un terminal j'écris:

dpkg --get-sélections | grep image linux

qui me montre les noyaux installés puis j'utilise:

paquet sudo apt-get purge

Où package est le nom du noyau en question, mais cela ne supprime pas les en-têtes associés, je fais donc un:

dpkg --get-sélections | grep linux

Et puis je procède à la suppression des anciens en-têtes, avec:

sudo apt-get purge linux-headers-3.2.0-41 linux-headers-3.2.0-44 linux-headers-3.2.0-45 linux-headers-3.2.0-48

Et voilà, mais bien sûr il y avait aussi la question des icônes Réveillé donc je décide de les déplacer vers ~ / .icons et de les rendre disponibles pour tout le système je fais juste un lien symbolique dans / usr / share / icons, le premier résultat de df -je C'est à l'élimination des en-têtes et le second après avoir déplacé les icônes.

Inodes libérés par le tas!

Avec cela le problème est résolu, et je peux installer / mettre à jour des packages sans problème, j'espère que ce post sera utile à quelqu'un, ou servira de référence future sur les installations dans de petites partitions et démystifier le sujet si répandu par les forums du manque De l'espace.