Mémoire/Partitionnement : rootfs à 100%

Support Debian
#1

Bonjour,

Je débute sur Debian, je m’en suis sortie jusqu’à présent, mais là je mélange les pinceaux avec toutes les solutions que j’ai trouvé (que je ne comprends pas toutes) sans résultat

résultat de la commande df

Sys. fich.                                             1K-blocks     Util. Disponible Uti% Monté sur
rootfs                                                    330215    330213          0 100% /
udev                                                       10240         0      10240   0% /dev
tmpfs                                                     405232       656     404576   1% /run
/dev/disk/by-uuid/4ae9b673-6cee-4dca-8c63-b35a75319b22    330215    330213          0 100% /
tmpfs                                                       5120         0       5120   0% /run/lock
tmpfs                                                    2483660        88    2483572   1% /run/shm
/dev/sdb9                                              594829624 153279456  411334540  28% /home
/dev/sdb8                                                 376807     10257     347094   3% /tmp
/dev/sdb5                                                8649992   3294816    4915780  41% /usr
/dev/sdb6                                                2882592    594508    2141652  22% /var

J’ai déjà supprimé les fichiers *.gz du répertoire /var/log. Mais cela n’a rien changé au problème.
D’autre part j’ai pas mal erreurs sur l’installation, la mise à jour, ou la suppression de package. ça pourrait être lié :

[quote]ldconfig: Échec d’écriture des données du cache: Aucun espace disponible sur le périphérique
[/quote]

Et Bonne Année

#2

Citer les messages d’erreur exacts et, requête humaine de la part d’humains, on n’est pas des machines, user de l’option -h comme humain près de [mono]df[/mono] (et si ça s’impose par la suite de ce fil, près de [mono]du[/mono], de [mono]ls[/mono]… )

Regarde le retour de df que tu nous as copié et note le détail à propos de /var :

/dev/sdb6 2882592 594508 2141652 22% /var
/var n’est pas solidaire de la racine.Décharger /var/log ne décharge en rien la racine. Les données que tu devrais délester de la racine doivent se trouver en /boot, /root, /etc, /lib …
Commencer par voir les noyaux installés :

Si tu as plusieurs versions de noyau installées,désinstaller une version de noyau ancienne pourrait te libérer un peu de place.

#3

Merci de ta réponse et de tes conseils. Ma réponse est un peu tardive, je n’ai pas activé les alertes sur le suivi du sujet :confused:
alors df -HaT :# df -haT Sys. fich. Type Taille Util. Dispo Uti% Monté sur rootfs rootfs 323M 323M 0 100% / sysfs sysfs 0 0 0 - /sys proc proc 0 0 0 - /proc udev devtmpfs 10M 0 10M 0% /dev devpts devpts 0 0 0 - /dev/pts tmpfs tmpfs 396M 672K 396M 1% /run /dev/disk/by-uuid/4ae9b673-6cee-4dca-8c63-b35a75319b22 ext4 323M 323M 0 100% / tmpfs tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs tmpfs 2,4G 564K 2,4G 1% /run/shm /dev/sdb9 ext4 568G 148G 391G 28% /home /dev/sdb8 ext4 368M 11M 339M 3% /tmp /dev/sdb5 ext4 8,3G 3,2G 4,7G 41% /usr /dev/sdb6 ext4 2,8G 582M 2,1G 22% /var rpc_pipefs rpc_pipefs 0 0 0 - /var/lib/nfs/rpc_pipefs binfmt_misc binfmt_misc 0 0 0 - /proc/sys/fs/binfmt_misc

# ls -sha /boot total 15M 1,0K . 127K config-3.2.0-4-amd64 10M initrd.img-3.2.0-4-amd64 2,8M vmlinuz-3.2.0-4-amd64 1,0K .. 6,0K grub 2,1M System.map-3.2.0-4-amd64

ça me parait correct non ?

du -sh /boot 17M /boot

ls -sha /lib/modules total 5,0K 1,0K . 3,0K .. 1,0K 3.2.0-4-amd64

après je parcours d’abord les plus gros dossiers qui sont dépendant de “/”, si j’ai bien compris ?

du -sh /* 7,3M /bin 17M /boot 0 /dev 4,4M /etc 147G /home 0 /initrd.img 129M /lib 1,0K /lib64 12K /lost+found 2,0K /media 1,0K /mnt 85M /opt du: impossible d'accéder à « /proc/7177/task/7177/fd/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/7177/task/7177/fdinfo/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/7177/fd/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/7177/fdinfo/4 »: Aucun fichier ou dossier de ce type 0 /proc 64M /root 1,3M /run 7,3M /sbin 1,0K /selinux 1,0K /srv 0 /sys 98K /tmp 3,0G /usr 514M /var 0 /vmlinuz

je commence par /lib ? je fais un “du” ou un “ls” ?

#4

Absurdité d’une racine de 323 Mo comparé aux actuels /var (2,8G), /usr (8,3G) ou /home (568Go en toutes lettres cinq cent soixante-huit gigas) sous-exploités et ça vient se plaindre du manque d’espace . Tu te rends compte ? 391 Go libres en /home, en toutes lettres trois cent quatre-vingt-onze gigas. De quoi installer $CHAISPASCOMBIEN de debian.

Tu n’as qu’un noyau. Il n’est donc pas envisageable de délester le système de son seul noyau.
Dans le retour de du, nous remarquons surtout /root(64 M) et /opt(85M). Se permettre de garnir /root et /opt est un luxe tapageur superflu quand on dispose d’une pauvre petite racine de 323 Mo. Dans ces conditions chiches, rien en /opt, le minimum en /root.
Tu peux momentanément déplacer les fichiers de /root et de /opt vers un stockage qui dispose de plus d’espace libre le temps d’installer.

Pour une solution plus durable, songer à agrandir ou déplacer la racine vers une partition plus grande.
Une solution possible serait de déplacer la racine en faisant de /var ou de /usr la nouvelle racine.

#5

Je soupçonne que le responsable à blâmer est encore le partitionnement en mode assisté de l’installateur qui crée des volumes bien trop petits pour / et même /usr.

D’accord sur /root et /opt, avec une racine aussi petite on ne peut pas se permettre de les remplir. Le contenu de /root non indispensable (qui n’est pas utile lorsque seule la racine est accessible) peut être déplacé dans un sous-répertoire dans /home, et /opt devrait pouvoir être transformé en un point montage avec son contenu déplacé ailleurs s’il n’est pas utilisé dans les premières phases de l’initialisation du système. Ainsi il sera possible de libérer jusqu’à 150 Mo sur la racine, ce qui devrait permettre de tenir jusqu’à la prochaine Debian stable jessie. Par contre, il n’y aura pas assez de place pour installer le nouveau noyau de jessie dont les modules occupent environ 150 Mo sur la racine, auxquels il faudra rajouter l’inévitable augmentation de taille des autres paquets et les nouveaux paquets.

#6

Oui j’ai fait confiance à l’assistant, en me disant que, vraiment, Debian n’était pas gourmand XD.
Merci de vos réponses. Je sais maintenant où est le problème. Encore une activité de plus dans la todo list du week-end.

Je passe le sujet à résolu