Le PC bloque au démarrage, refuse de faire les mises à jour ou comportement bizarre. Peut-être que le disque dur est plein...

Ceci dit, il peut être plein, même s'il n'en a pas l'air... Ceci est du aux inodes, qui peuvent être à 100% alors que le disque n'est pas plein à proprement dit...

(en savoir plus ici : http://doc.ubuntu-fr.org/systeme_de_fichiers#particularite_des_systemes_de_fichiers_nixinode )

Tester la commande :

df -i

pour voir si tous les inodes sont utilisés.. Si IUti% est à 100%, c'est le cas.. Du coup, il faut faire un peu de ménage (c'est du entre autre à la présence de beaucoup de petits fichiers..).

En général, cela vient du fait que pas mal de noyaux obsolètes sont toujours présents.

voir aussi : https://forum.ubuntu-fr.org/viewtopic.php?id=1970941

Maj du 07/07/2023

Après pas mal d'essais infructueux, j'ai enfin réussi à mettre en place une alerte auto par mail si le disque es trop rempli...

voir ici : https://blog.acrona.com/index.php?post/2023/07/07/Alerte-automatique-par-mail-en-cas-de-disque-plein

Maj du 02/07/2021

on peut aussi regarder du /var/log/journal.

S'il est trop volumineux, on peut le réduire automatiquement à une certaine taille

sudo journalctl --vacuum-size=100M

plus d'info sur https://linuxhandbook.com/clear-systemd-journal-logs/

On peut aussi créer une alerte automatique si le disque se remplit trop:

voir

https://it.izero.fr/script-bash-surveiller-lespace-disque-et-recevoir-une-alerte-mail-via-un-seuil-critique/ (url plus accessible, voir plus haut)

Vérifier les paquets snap :

snap list --all

Pour supprimer les versions désactivées:
snap list --all | awk '/désactivé|disabled/{print $1, $3}' | while read snapname revision; do sudo snap remove "$snapname" --revision="$revision"; done

Maj du 17/10/2017

on peut mettre en place des scripts tout fait dans /etc/cron.weekly, dispo ici : https://forum.ubuntu-fr.org/viewtopic.php?pid=21300891#p21300891

en one shot, à copier/coller dans un terminal: echo -e "#\x21/bin/bash\n\nif [[ \$(apt-mark showmanual | egrep linux-.*[0-9] | grep -v \"hwe\") ]]; then\n apt-mark auto \$(apt-mark showmanual | egrep linux-.*[0-9] | grep -v \"hwe\")\nfi\n/etc/kernel/postinst.d/apt-auto-removal \\\\\n\$(dpkg -l | awk '/linux-image-[0-9]/{k=\$2}\\\\\nEND{sub(/linux-image-/,\"\",k);print k}')\n\nexit 0" | sudo tee /etc/cron.weekly/apt-mark-auto-kernels
echo -e "#\x21/bin/bash\n\napt-get autoremove --purge -y\n\nexit 0" | sudo tee /etc/cron.weekly/autoremove
echo -e "#\x21/bin/bash\n\nif [[ \$(dpkg -l | grep ^rc) ]]; then\n dpkg -P \$(dpkg -l | awk '/^rc/{print \$2}')\nfi\n\nexit 0" | sudo tee /etc/cron.weekly/purge-rc
sudo chmod -v +x /etc/cron.weekly/apt-mark-auto-kernels
sudo chmod -v +x /etc/cron.weekly/autoremove
sudo chmod -v +x /etc/cron.weekly/purge-rc


Maj du 07/06/2016:

Si jamais le problème ne vient pas des noyaux, ces commandes permettent de connaitre le nbre de fichier dans un répertoire (histoire d'aider à localiser le problème...)

ls -lR | grep ^d | wc -l (pour les répertoires)
ls -lR | grep ^- | wc -l (pour les fichiers)

en fait, dans mon cas d'aujourd'hui, le problème vient de /var/lib/php5 qui est rempli de fichiers sess_

Cela pourrait être du par wordpress / plugin / autres qui n'efface pas les sessions derrière lui...

Bref, il suffit de purger les sessions plus vieilles de 2 jours avec la commande: (elle a mis plus de 20mn à s'exécuter, et je suis passé de 100% d'inodes à ...18% !!)

find /var/lib/php5/ -type f -atime +2 -name 'sess_*' -exec rm -f {} \;

(l'idéal étant de faire ensuite un cron avec cette commande...)

voir http://blog.nicolargo.com/2011/06/wordpress-et-le-trop-plein-de-fichiers-sess_.html

Maj du 11/03/2016:

Le problème vient sans doute d'un bug qui empêche les anciens noyaux d'être enlevés, car marqués en install manuelle (bien qu'ils aient été installé de façon automatique). La réponse se trouve là :

https://doc.ubuntu-fr.org/kernel#suppression_des_anciens_noyaux

En résumé, si la commande suivante donne une liste de résultat, c'est bien le cas:

apt-mark showmanual | egrep 'linux-.*[0-9]'

Il faut alors les marquer en installé auto avec la commande suivante:
sudo apt-mark auto $(apt-mark showmanual | egrep 'linux-.*[0-9]')


puis il suffit d'exécuter simple la commande suivante pour d'un coup retrouver plein de place (bien souvent 5 à 10 Go..):
sudo apt-get autoremove --purge

Si le système semble bien mal en point et que la méthode ci-dessus ne marche pas, on peut procéder à la méthode dite de "A la ouane again..."

Jeter un oeil sous /usr/src/ et effacer éventuellement les linux-header-xxx, linux-images-xxx.

Par prudence, essayer d'en effacer juste 2,3 (les plus anciens) histoire juste de libérer un peu de place pour débloquer...

ATTENTION à toujours laisser les plus récents dans tous les cas (le 2 ou 3 derniers..)

IMPORTANT : pour éviter de rester bloquer au redémarrage, si le système est resté bloqué sur une mise à jour et à déjà commencé à installer un nouveau noyau, pour pouvoir facilement choisir de démarrer sur un ancien noyau, éditer le fichier (en admin)  /etc/default/grub et commenter les lignes :

#GRUB_HIDDEN_TIMEOUT=0
#GRUB_HIDDEN_TIMEOUT_QUIET=true

Cela permettra de choisir les options avancées au démarrage et de choisir un noyau plus ancien (prendre le 2ème ou 3ème de la ligne...)

Ne pas oublier de lancer la commande suivante pour mettre à jour le grub.

sudo update-grub

puis redémarrer et normalement la méthode ci-dessus devrait être applicable...

Une fois débloqué, éventuellement faire :

sudo apt-get -f install

(si problème de mise à jour bloquée, paquets cassés)

sudo apt-get autoremove

sudo apt-get clean

(histoire de faire un peu plus de place...)