Je suis débutant dans le monde linux et je me retrouve avec un serveur Debian qui a un problème !!!
Mon rootfs est full, et malheureusement ça ne viens pas des fichier temporaires qui se trouve dans le var ><
J’ai déjà essayer d’utiliser quelque sujet du site comme :
Quand on fait une racine de moins de 400mo (?!, normalement c’est 1Go minimum je crois), on s’assure d’avoir des partitions tel que /var et /usr de monté, ailleurs.
Voici quelques commandes qui devraient faire un peu de ménage du côté de /var et apt:
Typiquement, /lib prend la moitié de ta racine, c’est pas cool non plus.
Comme je disais, même si tu sépares toutes les partitions il faut donner un peu d’espace à /, 3** mo je trouve ça vraiment léger. Ou alors faut monter aussi des partitions comme /lib ailleurs. /boot aussi peut prendre un peu de place avec le temps. Sinon le reste à l’air ok, tes autres partitions un peu lourdasse sont ailleurs (j’ai mal lu la première fois ).
Pour moi la seule solution est soit de séparer /lib de ta racine soit d’augmenter la taille de /, personnellement je te conseil de faire les deux, au moins 500mo, voir 1Go pour ta / au cas où ! En plus tu me semble en LVM, ça doit être plutôt simple de modifier ton partitionnement sans que ça prenne 15h.
GNU/Linux sait prendre peu de place mais faut pas non plus le faire vivre dans une boite à chaussure !
En cherchant un peu j’admets ne pas avoir trouvé comment.
Je te conseil, avant tout, de faire un backup de ton système (dd te permettra de faire une image de ton disque dur et de toutes tes partitions que tu pourra ré-injecter en inversant la commande). Ensuite il faudra que tu modifie ton /etc/fstab pour ajouter l’UUID de la partition (avec la commande blkid pour obtenir l’UUID) ainsi qu’ajouter les options adéquates.
Regarde la place prise par /lib/modules. Tu as probablement installé plus d’un noyau. Désinstalle les noyaux qui ne te servent plus.
/root mobilise 73Mo. Tu pourrais effacer ou déplacer les fichiers qui s’y trouvent (ne pas déplacer /root, déplacer les fichiers).
Copie nous le retour de la commande
fdisk -l
(ou # parted -l)
afin que nous voyions si retailler les partitions serait envisageable sans trop de complications.
Quant à l’idée du lien symbolique /lib, ça ne m’inspire pas confiance.
Je pense que tu t’exposerais à des problèmes avec cette disposition. Ça risquerait de ne pas passer lorsque tu aurais besoin de démarrage de secours.
$ man hier
/lib This directory should hold those shared libraries that are necessary to boot the
system and to run the commands in the root file system.
Le contenu de /lib est relatif à la même racine (the root file system) et devrait être immédiatement accessible.
/lib fait partie des dossiers qui ne devraient être désolidarisés de la racine au même titre que /etc ou /bin .
Faire de /lib un lien symbolique semble avoir cours chez les archers : bbs.archlinux.org/viewtopic.php?id=144990
L’idée du lien symbolique /lib qui a cours chez arch est de considérer /usr/lib pour remplacer /lib.
Ce que tu voudrais faire est différent. Il s’agirait de déplacer /lib et non pas de l’effacer au seul profit de /usr/lib (de plus, /usr est un montage séparé chez toi ce qui ne rendrait pas /usr/lib || /lib immédiatement disponible).
J’y vois une complication : la racine à agrandir /dev/sda1 jouxte l’étendue /dev/sda2.
/dev/sda1 ne pourrait être agrandi sans retoucher /dev/sda2. À son tour, /dev/sda2 ne pourrait être rétréci sans déplacer le début de /dev/sda5.
Utiliser un live-cd muni de gparted pour manipuler les partitions.
Deux approches envisageables
A) "Tout droit"
Manipuler l’étendue est une opération épineuse qui prendra plusieurs temps.
Déplacement du début de la partition logique /dev/sda5 “vers la droite” déplacement des données au sein de la partition, puis de l’étendue /dev/sda2 avant d’agrandir /dev/sda1 …
Ce sera direct, ce sera lourd, brutal et risqué . Espérer qu’une coupure de courant ne survienne pas durant ce looooong exercice.
B) Éviter l’obstacle
Ne pas retoucher l’étendue.
Changer de racine. Tu pourrais faire de la racine actuelle la partition /boot. Avec une partition /boot de 331 Mo, il y a de quoi caser un bon nombre de noyaux. Convertir /usr en racine ou créer une nouvelle racine en rétrécissant la partition /dev/sda9, /home à 259Go. Copier les données, éditer /etc/fstab Ce sera un peu plus technique mais ce sera plus rapide, plus léger, moins risqué.
(Plus amples détails à venir selon approche adoptée )
Peut etre peux tu envisager de compresser tous les executables de ton /usr/bin avec upx http://upx.sourceforge.net/
upx réduit de moitié (environ) chaque executable tout en ne changeant strictement rien à la manière dont chaque appli fonctionne (elle est juste décompressée à la volée et très rapidement lorsque l’executable est invoqué)
j’ai déjà effectué la manip sur un aspire one qui n’avait qu’un ssd de 8go pour gagner un peu de place et ça m’avait bien rendu service sur le moment.
[quote=“douarn”]Peut etre peut tu envisager de compresser tous les executables de ton /usr/bin avec upx http://upx.sourceforge.net/
upx réduit de moitié (environ) chaque executable tout en ne changeant strictement rien à la manière dont chaque appli fonctionne (elle est juste décompressée à la volée et très rapidement lorsque l’executable est invoqué)
j’ai déjà effectué la manip sur un aspire one qui n’avait qu’un ssd de 8go pour gagner un peu de place et ça m’avait bien rendu service sur le moment.[/quote]
Rapide oui, sur un SSD, n’y a t’il pas une perte (plus) importante de perf sur un HDD classique?
Fais un fichier swap sur /home de 8G, vire le swap, reformatte /dev/sda7 en ext3, déplace la racine sur le /dev/sda7. Cela se fait très rapidement et minimise les manipulations.
Si tu avais regardé attentivement tu aurais vu que c’est le cas.
Faire du ménage dans /var sera donc sans effet sur l’espace libre de la racine.
D’autre part on n’a pas du tout besoin d’1 Go pour la racine seule, à moins de vouloir installer un nombre important de noyaux (il faut environ 100 Mo pour un noyau 3.2 686 en comptant l’initramfs).
C’est normal, /lib contient les modules des noyaux installés, soit la majeure partie de l’espace occupé par les noyaux. Le reste (image et initramfs) est dans /boot.
On ne peut pas, on ne doit pas séparer /lib de la racine ! Idem avec /bin, /sbin, /etc. Leur contenu doit être accessible dès le montage de la racine.
Rien ne l’indique, je me demande ce qui te fait penser ça.
Les bonnes pistes à suivre en priorité ont déjà été évoquées :
déplacer du contenu de /root ailleurs, par exemple dans un dossier /home/root ;
désinstaller un ancien noyau si le noyau actuel fonctionne bien, cela libèrera 100 Mo.
Note : Si je fais la somme des tailles dans les répertoires situés dans le volume racine à partir du résultat de du -sh, j’obtiens environ 288 Mio, ce qui n’est pas incohérent avec une taille maxi de 330 Mio en comptant 10% d’overhead (slack, journal et autres méta-données). Donc il n’y a a priori pas d’espace occupé par des fichiers qui seraient masqués sous les points de montage.
D’après la sortie de du, /opt est vide.
Deux noyaux à ~100 Mo pièce + ~70 Mo dans /root + les quelques bricoles habituelles dans /bin et autres + 10% d’overhead et le compte y est.
).
