Partition racine pleine sans raison
- Anmelden oder Registrieren um Kommentare zu schreiben
Bonjour à tous,
J'ai un problème assez handicapant. Ma partition racine est pleine (j'ai un message d'erreur m’annonçant qu'il reste 0 octet de disponible...). Je ne comprends pas.
Il y a quelque temps j'ai reçu quelques alertes me disant que l'espace disque était faible "Le volume "Racine du système de fichiers" n'a plus que 809 Mio d'espace disponible." Du coup, j'avais supprimé les anciens noyaux (sauf les deux derniers), j'avais également passé un coup d'"autoremove" et d"autoclean". Je pensais avoir résolu le problème mais voilà que les alertes sont revenues. A tel point qu'aujourd'hui j'ai un message d'erreur qui m'indique qu'il ne reste plus d'espace.
Je soupçonne quelque chose d'anormal étant donné que rien ne justifie ce remplissage intempestif.
Mon répertoire home est sur une autre partition. Je n'ai pas installé de logiciel ces derniers temps.
Ma partition racine fait 18G.
J'ai un peu regardé les répertoires et à part le mystérieux répertoire "proc" (annoncé à la taille de 140,7To?!!!) et le répertoire "usr" (6G), les autres répertoires semblent très léger. Que se passe-t-il donc?
Une idée?
Qui peut m'aider?
D'avance merci!
voilà ce que me renvoi "df -h":
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 3,9G 4,0K 3,9G 1% /dev
tmpfs 795M 1,2M 794M 1% /run
/dev/sda1 19G 18G 90M 100% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 3,9G 47M 3,9G 2% /run/shm
none 100M 28K 100M 1% /run/user
overflow 1,0M 1,0M 0 100% /tmp
/dev/sda6 199G 80G 120G 40% /home
Utilise donc l'"Analyseur d'utilisation des disques" dans les "Paramètres système" et choisis d'analyser la partition racine. Tu obtiendras, après quelques minutes, un beau diagramme qui te montrera ce qui occupe de la place. Peut-être un fichier de log plein d'un même message répété ad nauseam...
Merci pour ta réponse Magic Banana!
A vrai dire j'ai déjà ouvert l'analyseur mais ça ne semble pas fonctionner:
"Impossible d'analyser le dossier « / » ou certains de ces sous-dossiers." Permission non accordée
J'arrive toutefois à voir un diagramme. Le plus gros dossier semble être /usr/lib (3,1G) ensuite /usr/share (2,2G)
Le reste des dossier est en dessous du giga.
La racine est supposée avoir 18G d'espace, qu'est-ce donc qui pourrait utiliser cet espace?
Je suggérais un fichier dans /var/log. Mais voyons donc, avec la ligne de commande suivante (à exécuter dans un terminal), l'espace pris par les fichiers et répertoires (ou plutôt ce qu'ils contiennent) à la racine :
$ sudo du -ahxd 1 /
Tu peux ensuite regarder de plus près un sous-répertoire (/var das mon exemple), qui prendrait beaucoup de place, en le spécifiant à la place de / :
$ sudo du -ahxd 1 /var
Si tu veux comprendre la commande (ce qui est une bonne idée lorsque quelqu'un t'invite à exécuter des commandes commençant par 'sudo'), vois le manuel de 'du' et cherche les options ("-a", "-h", "-x" et "-d") utilisées :
$ man du
Au fait, /proc et /sys sont des répertoires où sont montés des systèmes de fichiers dits "virtuels". Ils fournissent une interface avec le noyau sous la forme d'un système de fichiers mais il ne s'agit pas de fichiers "normaux" qui occuperaient de la place sur le disque.
Merci pour ton aide Magic Banana.
Alors, d'abord la commande "$ sudo du -ahxd 1 /" me renvoie:
"453M /opt
80M /etc
16K /media
3,5M /lib32
9,7M /bin
19M /sbin
4,0K /lib64
0 /initrd.img.old
16K /lost+found
400M /lib
4,0K /mnt
4,0K /srv
766M /var
0 /vmlinuz
0 /initrd.img
5,7G /usr
76M /boot
316K /root
24K /tmp
4,0K /cdrom
0 /vmlinuz.old
7,5G /"
/var ne fait que 766M, j'en deduis donc que le problème viendrait du répertoire "/usr" qui fait 5,7G
J'entre donc la commande: $ sudo du -ahxd 1 /usr, qui me renvoie:
7,4M /usr/lib32
247M /usr/bin
17M /usr/sbin
164K /usr/lib64
2,1G /usr/share
2,9G /usr/lib
176K /usr/local
836K /usr/games
254M /usr/src
184M /usr/include
5,7G /usr
Rebelote avec les dossiers "share" et "lib".
$ sudo du -ahxd 1 /usr/share qui me renvoie une liste partielle (comme un bug dans le terminal). Le haut de l'écran du terminal est noir, je vois que les dernières lignes qui sont:
16K /usr/share/foo2qpdl
8,0K /usr/share/alsa-source
36K /usr/share/nautilus-sendto
20K /usr/share/language-support
360K /usr/share/python
12K /usr/share/session-migration
504K /usr/share/ncat
2,1M /usr/share/gthumb
4,3M /usr/share/rakarrack
32K /usr/share/purple
176K /usr/share/emoticons
8,0K /usr/share/acpi-support
1,4M /usr/share/minitube
328K /usr/share/gtkhtml-4.0
736K /usr/share/polkit-1
124K /usr/share/git-core
6,0M /usr/share/gutenprint
1,8M /usr/share/yelp
12K /usr/share/metacity
164K /usr/share/soundconverter
316K /usr/share/menu
124K /usr/share/unity-greeter
217M /usr/share/locale
8,1M /usr/share/gir-1.0
28K /usr/share/gdict-1.0
18M /usr/share/backgrounds
12K /usr/share/gnome-tweak-tool
1,5M /usr/share/gettext
428K /usr/share/gnome-disk-utility
2,1G /usr/share
Vu que la liste n'est pas complète... je ne peux pas voir ce qui prend tant de place.
Même "bug" avec la commande "$ sudo du -ahxd 1 /usr/share", qui me renvoi aussi une liste partielle:
232K /usr/lib/libedata-cal-1.2.so.23.0.0
0 /usr/lib/libkate.so.1
1,6M /usr/lib/libperl.so.5.18.2
0 /usr/lib/libxml++-2.6.so.2
0 /usr/lib/libmpcdec.so.6
0 /usr/lib/libgvpr.so
308K /usr/lib/dbus-1.0
100K /usr/lib/libtbbmalloc.so.2
5,9M /usr/lib/locale
116K /usr/lib/libkrosscore.so.4.13.3
84K /usr/lib/libkdesu.so.5.13.3
0 /usr/lib/liblinear.so.1
0 /usr/lib/libknotifyconfig.so.4
744K /usr/lib/openssh
0 /usr/lib/libkfile.so.4
316K /usr/lib/libpq.a
52K /usr/lib/libchromeXvMCPro.so.1.0.0
1,3M /usr/lib/librhythmbox-core.so.8.0.0
1,1M /usr/lib/libcwidget.so.3.0.0
0 /usr/lib/libbrasero-utils3.so.1
0 /usr/lib/libgnome-media-profiles-3.0.so.0
0 /usr/lib/libgtkglext-x11-1.0.so.0
52K /usr/lib/gettext
20K /usr/lib/libvte-2.90-9
0 /usr/lib/libgirepository-1.0.so.1
72K /usr/lib/libpanel-applet-4.so.0.1.1
0 /usr/lib/liblangtag.so.1
12K /usr/lib/cruft
156K /usr/lib/libwvdbus.so.4.6
2,9G /usr/lib
Dans ces listes partielles rien d'alarmant. Le problème c'est que je ne peux pas voir ce qui semble prendre de la place...
Concernant le bug du terminal, je fais l'hypothèse que ma racine est tellement remplie que le terminal et d'autres programmes n'arrive pas à travailler correctement (comme si elle n'arrivait plus à mettre avoir suffisamment de mémoire cache). Pour l'instant, il est presque impossible lire une vidéo en streaming sur abrowser. Libreoffice bug sévère également. Impossible de faire une modification dans le fichier et de sauver, puis de rouvrir le fichier sans avoir plein de message d'erreur, etc.
J'ai donc essayé de désinstaller une série de programme en espérant retrouver quelques Mo pour pourvoir voir la liste au complet mais rien n'y fait.
Pour info il m'est également impossible de lancer le gestionnaire de paquet.
Je me sens un peu démuni. Ça fait quelques temps que ma machine est instable. J'hésite réinstaller Trisquel proprement. Le problème c'est que autant je me sentais relativement à l'aise de le faire avec le bios, autant, j'ai un peu peur de le faire avec mon x200 qui tourne sous libreboot. Cet amorceur étant moins connu, les infos quasi inexistantes, mes connaissances étant ce qu'elle sont... en bref, si je ne l'ai pas fait jusqu'à présent c'est en grande partie parce que j'ai peur de briquer ma machine.
Que feriez-vous dans ma situation?
7,5G /
Cela ne correspond pas à la sortie de 'df' que tu nous as montrée (18G d'utilisation). Il semblerait que tu ais réellement libéré de la place (et même beaucoup) depuis l'exécution de 'df -h' dont tu nous as montré la sortie. Pourrais-tu exécuter de nouveau 'df -h' pour confirmer ?
Si, comme tu l'écris, 'sudo du -ad 1' ne renvoie pas toujours une ligne par fichier/répertoire dans le répertoire passé en argument, alors c'est inquiétant ! Mais en es-tu certain ?
Tes problèmes suggèrent une défaillance matériel. Peut-être bien du disque. Pour tester la santé de ton disque dur, utilise l'utilitaire "Disques" (dans les "Paramètres système"). Choisis le disque, à gauche de l'interface, puis "Données SMART et auto-tests..." dans le menu avec une icône d'engrenage, en haut à droite de l'interface. Depuis la fenêtre qui s'ouvre, tu peux "Démarrer l'auto-test" (que tu peux choisir "étendu") avec le bouton éponyme, en bas à gauche. L'"estimation globale", en haut, t'informera si ton disque dur est sain ou non.
La mémoire vive peut aussi être en cause. 'memtest86+' (à laisser tourner pendant une nuit) permet de tester la mémoire. Il se trouve dans le dépôt Trisquel. Tu peux par exemple l'installer depuis le "Gestionnaire de paquets Synaptic". 'memtest86+' se lance depuis les "Options avancées de Trisquel GNU/Linux" du chargeur de démarrage, GRUB, pas depuis Trisquel. L'ennui c'est que, par défaut, l'installateur Trisquel colle un mot de passe aléatoire à GRUB. GRUB demande ce mot de passe pour pouvoir lancer autre chose que Trisquel (par exemple 'memtest86+'). Ce mot de passe ne sert qu'à t'ennuyer. Même les développeurs de GRUB le disent : https://www.gnu.org/software/grub/manual/grub.html#Security
Bref, soit tu lances un 'memtest86+' qui se trouverait aux côtés d'un GNU/Linux live (pas Trisquel : les ISOs Trisquel n'ont pas 'memtest86+') soit tu commences par supprimer le mot de passe GRUB inutile (ou à l'apprendre, si tu ne veux pas le supprimer) : https://trisquel.info/fr/wiki/mot-de-passe-grub
D'accord, je m'étais demandé ce que voulait dire "7,5G /". J'ai cru que c'était la somme des fichiers contenu dans dans la racine. Tu sembles dire que c'est l'espace disponible. Étrange en effet.
Après redémarrage, voici déjà la nouvelle réponse à l'exécution de df -h:
udev 3,9G 4,0K 3,9G 1% /dev
tmpfs 795M 1,2M 794M 1% /run
/dev/sda1 19G 18G 0 100% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 3,9G 47M 3,9G 2% /run/shm
none 100M 24K 100M 1% /run/user
/dev/sda6 199G 80G 120G 40% /home
J'ai encore exécuté "sudo du -ad 1" et pareil, j'ai seulement la fin de la liste qui s'affiche et si je scroll pour remonter dans la fenêtre du terminal je vois du noir, donc oui je suis certain.
Le résultat de l'auto-test "étendu": Le disque est sain.
C'est déjà ça!
Concernant memtest, j'ai réussi à ouvrir le gestionnaire de fichier synaptique et à l'installer.
j'en ai profité pour "recharger" et "tout remettre à niveau".
Concernant le mot de passe de Grub, j'ai essayé de le supprimer mais ça ne fonctionne pas
gksu gedit /etc/grub.d/01_PASSWORD me donne droit à l'ouverture d'une fenetre pop up qui me dit:
"Impossible de lancer gedit '/etc/grub.d/01_PASSWORD' en tant qu'utilisateur root." Impossible de copier le fichier Xauthorization de l'utilisateur.
Je néanmoins pu récupérer ce mot de passe. Je vais donc suivre ton conseil et faire tourner memtest86+ cette nuit.
Encore merci Magic Banana!
D'accord, je m'étais demandé ce que voulait dire "7,5G /". J'ai cru que c'était la somme des fichiers contenu dans dans la racine.
C'est exactement cela. Et 'df' indique que 18G sont utilisés : plus du double ! Alors que tu viens de redémarrer (donc cela ne s'explique pas par des suppressions de fichiers non actées par le système de fichiers).
Essaie donc depuis un système Live de vérifier le système de fichier sur /dev/sda1 (ici avec l'option -a pour automatiquement réparer ce qui peut l'être):
$ sudo fsck -a /dev/sda1
Alors, voici les nouvelles. Plutôt bonnes en fait.
D'abord, après avoir installé memtest, j'ai essayé de le lancer depuis grub. Sans succès. Quand j'entrais "enter" sur la ligne memtest86+, un message d'erreur apparaissait puis l'image du fond d'écran avec le pinguin et le gnou... et rien ne se passait. Pas l'écran bleu de memtest que je suis sensé voir apparaitre.
Je suis passé par la case live system.
Outre le fait que faire tourner un live system sur libreboot demande une procédure particulière (cf https://libreboot.org/docs/gnulinux/grub_boot_installer.html), depuis ce dernier, j'ai essayé d'entrer la commande "$ sudo fsck -a /dev/sda1". Sans réponse. En recherchant un peu (https://doc.ubuntu-fr.org/fsck), j'ai cru voir qu'il fallait d'abord démonter la partition avant d'utiliser fsck.
J'ai donc entré "$ sudo umount /dev/sda1" avant d'entrer "$ sudo fsck /dev/sda1" et de valider les multiples proposition de réparation. Redémarrage et voilà que le problème semble résolu!!!
voici ce que me donne "$ df -h"
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 3,9G 8,0K 3,9G 1% /dev
tmpfs 795M 1,2M 794M 1% /run
/dev/sda1 19G 7,5G 9,8G 44% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 3,9G 47M 3,9G 2% /run/shm
none 100M 28K 100M 1% /run/user
/dev/sda6 199G 83G 117G 42% /home
Le problème le problème d'affichage de terminal semble résolu du même coup.
Quand j'entre la commande "$ sudo du -ahxd 1 /usr/share", je n'ai plus le problème que j'avais auparavant.
Merci Magic Banana!
Maintenant la question est de comprendre pourquoi les erreurs sont elles apparues afin de prévenir leurs réapparitions.
ps: Deux éléments à relever. Avant la réparation, lorsque j'entrais la commande "$ dmesg", j'obtenais une longue réponse avec ces dernières lignes qui me semble intéressante:
".....
[ 47.537678] systemd-hostnamed[2360]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
[ 52.757425] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 218.630468] perf samples too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[ 303.072052] EXT4-fs (sda1): error count since last fsck: 2
[ 303.072059] EXT4-fs (sda1): initial error at time 1457949994: ext4_journal_check_start:56
[ 303.072063] EXT4-fs (sda1): last error at time 1457949994: ext4_journal_check_start:56"
Cela faisait écho au fait que j'avais un message d'erreur lorsque j'entrais une commande dans le terminal disant "impossible de déterminer le nom de l'hôte XXXXX"
En fait, "$ cat /etc/hosts" et "$ cat /etc/hostname" ne me renvoyait pas le même nom de machine. J'ai suivi la procédure indiquée ici: https://forum.ubuntu-fr.org/viewtopic.php?id=1944501 et le problème s'est résolu depuis. Maintenant ma machine a retrouvé son nom originel (donné par minifree). Je ne sais pas trop s'il est judicieux de changer le nom pour celui que j'avais choisi. Ce n'est pas le plus urgent, je vais d'abord m'assurer que tout est en ordre avant de résoudre ce détail.
Cela dit, il semble qu'il existe un bug relatif à un message d'erreur du hostname ( Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname! )... je l'ai toujours mais, si j'ai bien compris, je peux me contenter de l'ignorer (http://askubuntu.com/questions/453072/what-is-nss-myhostname-and-why-is-it-not-installable).
Concernant le message d'erreur "perf samples too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 50000" il semble aussi que ça soit un bug connu: https://bugzilla.redhat.com/show_bug.cgi?id=1013708
Par contre, les 3 derières lignes "EXT4-fs (sda1)" relèvent les erreurs que je n'ai plus depuis que j'ai exécuté fsck. Voilà, je ne suis pas certain qu'il y ai un rapport mais on ne sait jamais...
Pour le reste, je vais quand même essayer d'exécuter memtest, c'est quand même étrange que je ne puisse pas le lancer. Je vous tient au courant.
Encore merci!
'df' est maintenant d'accord avec 'du' (7,5G de la partition racine sont utilisés) :
/dev/sda1 19G 7,5G 9,8G 44% /
'fsck' a résolu ton problème. Tu as donc souffert d'une corruption du système de fichiers, de type ext4, sur cette partition. Une corruption qui a apparemment affecté son journal (deux fois) vu les trois dernières lignes de 'dmesg' que tu nous montres. Ceci dit, selon Ted Ts'o, développeur principal des systèmes de fichiers ext, un message commençant par "EXT4-fs (sda1)" et non "EXT4-fs error (sda1)" ou "EXT4-fs warning (sda1)" est seulement informatif : https://lkml.org/lkml/2010/9/26/105
Une corruption du système de fichiers peut arriver après un arrêt brutal du système (coupure d'alimentation, plantage du noyau, etc.), alors que les partitions n'ont pas été correctement synchronisées et démontées. Le journal du système de fichiers sert justement à garantir l'intégrité des données dans ces cas là. Je suppose que, dans ton cas, l'arrêt brutal a eu lieu alors que le journal de ext4 était écrit. Vois https://fr.wikipedia.org/wiki/Syst%C3%A8me_de_fichiers_journalis%C3%A9 pour en savoir plus sur la journalisation (si le sujet t'intéresse).
- Anmelden oder Registrieren um Kommentare zu schreiben