Le volume "racine du système de fichiers" ne dispose plus que de 0 octet d'espace disque?
J'ai installé 11.10 ~ il y a deux semaines et j'ai récemment rencontré des problèmes étranges.
L'installation s'est faite sur un ordinateur portable flambant neuf avec SSD de 160 Go. J'ai opté pour le cryptage du répertoire personnel. En dehors de cela, j'ai accepté les paramètres par défaut lors de l'installation. Il n'y a pas d'autre système d'exploitation sur mon ordinateur portable.
J'avais environ 40 Go en utilisation quand (pour la troisième fois) j'ai pu voir cette fenêtre très désagréable:
La situation à deux reprises était plutôt mauvaise et tout le système a considérablement ralenti. Après le redémarrage, je ne pouvais plus me connecter à l'interface graphique (avec un message d'erreur signalant un espace insuffisant) et je devais d'abord supprimer certains fichiers de la ligne de commande.
La troisième fois, j'ai quand même réussi à supprimer rapidement certains fichiers et cela a aidé.
Mon ordinateur portable est principalement un environnement de travail: donc pas de torrents, de jeux, juste deux films. Seul l’espace remplissant les supports contient environ 20 Go d’images et un ensemble de fichiers PDF. Travaillant principalement sur PostgreSQL & PostGIS, GeoServer et QGIS récemment.
Bien que j'aie eu beaucoup d'occasions de tester et de pratiquer mes sauvegardes, je serais extrêmement reconnaissant si quelqu'un pouvait m'indiquer des solutions potentielles à ce problème.
Mon ordinateur portable a été acheté juste avant l'installation d'Ubuntu, et il est venu sans système d'exploitation. Cela pourrait-il être un problème matériel?
Ou est-ce que le homechiffré me cause des maux de tête?
Merci pour l'aide!
Mise à jour 1: comme suggéré par @ maniat1k , voici la sortie actuelle de fdisk -l:
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sda1 1 312581807 156290903+ ee GPT
Mise à jour 2: comme suggéré par zanfur , sortie de dfname__:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 149802648 31411456 110781576 23% /
udev 1959764 4 1959760 1% /dev
tmpfs 788276 992 787284 1% /run
none 5120 0 5120 0% /run/lock
none 1970684 2716 1967968 1% /run/shm
/dev/sda1 19363 129 19234 1% /boot/efi
/home/rdk/.Private 149802648 31411456 110781576 23% /home/rdk
Et Sudo parted -l:
Model: ATA INTEL SSDSA2BW16 (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 20.0MB 20.0MB fat16 boot
2 20.0MB 156GB 156GB ext4
3 156GB 160GB 4177MB
Mise à jour 3:
Encore une autre fenêtre avec un message de faible mémoire: /
Travaillant récemment principalement sur VirtualBox et utilisant Remmina.
Suite à cette information, j'ai pratiquement tout supprimé de mon répertoire personnel. Redémarré. Après cela, il y avait environ 20 Go [environ 10 Go pour l’image disque VirtualBox que je voulais conserver si possible]. Après SarveshLad comment j'essayais de récupérer plus d'espace et d'exécuter l'application Bleachbit quand j'ai eu une autre erreur de faible espace sur HD. Ensuite, le système a gelé. Comment mon Ubuntu peut-il remplir la HD avec plus de 100 Go en quelques minutes?
Ceci est presque certainement dû au manque d'espace sur le système de fichiers racine. Si vous avez beaucoup d'espace libre sur votre lecteur, vous disposez probablement d'un système de fichiers distinct pour vos données utilisateur. C'est une configuration commune.
Pour rechercher la quantité d'espace libre sur toutes vos partitions, exécutez la commande "disk free", dfname__. Vous n'avez pas besoin d'être root. Vous obtiendrez quelque chose comme ceci:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 9614116 8382396 1134048 89% /
none 1541244 284 1540960 1% /dev
none 1546180 4804 1541376 1% /dev/shm
none 1546180 372 1545808 1% /var/run
none 1546180 0 1546180 0% /var/lock
none 1546180 0 1546180 0% /lib/init/rw
none 9614116 8382396 1134048 89% /var/lib/ureadahead/debugfs
/dev/sda3 32218292 12333212 19885080 39% /home
Comme vous pouvez le constater, j'ai un système de fichiers racine distinct (le premier répertorié) et un système de fichiers utilisateur (le dernier répertorié), et ma partition racine est presque saturée. Si votre sortie dfvous indique que votre système de fichiers racine est en fait plein, vous devez supprimer certains fichiers (attention à ceux qui sont!) Ou redimensionner vos partitions.
Une commande de terminal utile pour trouver ce qui consomme tout l'espace est la commande "usage du disque", duname__. Appelé sans aucun paramètre, il commence par répertorier les tailles de chaque fichier du répertoire actuel et de tous les répertoires ci-dessous. Votre scénario est plus utile pour suivre l’utilisation: Sudo du -s -h -x /*, ce qui vous donnera la quantité totale d’espace utilisé (-s) par chaque fichier ou répertoire situé en haut de votre système de fichiers racine (/*), sans consulter d’autres systèmes de fichiers (-x). , en nombres lisibles par l’homme tels que "124M" (-h). Ne vous inquiétez pas si cela prend un certain temps, cela vous prendra environ quelques minutes à la première.
Ne supprimez pas les fichiers sans savoir d’abord ce qu’ils sont, bien sûr. Mais, en général, vous ne casserez pas votre système si vous supprimez des fichiers dans les répertoires suivants:
/tmp(données temporaires de l'utilisateur - elles sont généralement toutes supprimées à chaque redémarrage)/var/tmp(spools d'impression et autres données temporaires du système)/var/cache/*(celui-ci peut être dangereux, faites des recherches avant!)/root(répertoire de base de l'utilisateur root)
En plus des endroits ci-dessus, les endroits suivants sont les coupables:
/opt(de nombreuses applications tierces s'installent ici et ne nettoient pas après elles-mêmes)/var/log(les fichiers journaux peuvent occuper beaucoup d'espace s'il y a des erreurs répétitives)
Alors, vérifiez ceux en premier. S'il s'avère que les choses semblent correctes et que votre partition racine est tout simplement trop petite, vous devrez redimensionner vos partitions pour l'adapter. Il existe une multitude de façons de le faire, mais le plus simple est probablement de démarrer à partir d'un LiveCD Ubuntu (à télécharger depuis le site page de téléchargement de Ubuntu) et d'exécuter l'éditeur de partition GNOME gpartedname__. Vous devrez peut-être installer le package gparted(dans l’environnement LiveCD, exécutez Sudo apt-get install gparted ou utilisez le centre de logiciel). Dans tous les cas, il s’agit d’un utilitaire graphique qui vous permettra de cliquer avec le bouton droit de la souris sur la partition et de sélectionner "redimensionner".
N.B. - n’avez pas de système d’exploitation hiberné lorsque vous redimensionnez des partitions , sinon cela ne fonctionnera pas ou ne fera pas très mal à votre système d’hibernation.
Selon votre liste dfname__, vous avez beaucoup d’espace libre sur /. Une fois que vous avez reçu l'un de ces messages, vérifiez à nouveau dfet, s'il reste encore beaucoup d'espace libre, vérifiez si dmesgaffiche des erreurs. Il est possible que vous obteniez une erreur entraînant le remontage du système de fichiers en lecture seule, ce qui pourrait prêter à confusion pour le notificateur d'espace libre. À partir du livecd, ouvrez l’utilitaire de disque et vérifiez l’état du lecteur SMART pour vous assurer qu’il ne contient aucun secteur défectueux. Exécuter l'autotest long peut également être une bonne idée, et vérifier le système de fichiers par la suite.