Bonsoir,
petit (?) problème avec mon système ?
total dispo
/ 326,6 Mo 86,5 Mo
/home 274,3 Go 227,4 Go
/tmp 372,2 Mo 342,9 Mo
/usr 4,6 Go 1,5 Go
/var 2,8 Go 2,3 Go
J’ai laissé debian partitionner, ces valeurs sont-elles acceptables ?
Si je prends sur /home avec gparted, je risque pas de perdre des données ?
[quote=“blaisoth”]Si je prends sur /home avec gparted, je risque pas de perdre des données ?[/quote]Avec gparted EN LIVE-CD (j’insiste sur le live-cd, on ne travaille JAMAIS sur des partitions “montées”…) il y a peu de risque, mais le risque est là quand même… rien ne vaut une sauvegarde… quand on touche aux partitions, la moindre erreur peut être fatale…
Pourquoi ne pas faire le ménage sur le / en enlevant les noyaux dont tu ne te sers plus? (fais une recherche sur le forum… je suis sûr qu’il y a quantité de fils là dessus…) 
Je croyais n’avoir ‘que’ deux noyaux. Quand on aime …
debian:/home/eric# dpkg -l |grep linux-image
ii linux-image-2.6-amd64 2.6.26+17+lenny1 Linux 2.6 image on AMD64
ii linux-image-2.6.26-2-amd64 2.6.26-21 Linux 2.6.26 image on AMD64
ii linux-image-2.6.30-bpo.1-amd64 2.6.30-6~bpo50+1 Linux 2.6.30 image on AMD64
Comment supprimer proprement un noyau (j’ai cru lire que ça libérait pas des masses de place) ?
et dans ‘menu.lst’ je n’en ai que deux ?
[quote]title Debian GNU/Linux, kernel 2.6.30-bpo.1-amd64
root (hd0,0)
kernel /boot/vmlinuz-2.6.30-bpo.1-amd64 root=/dev/sda1 ro quiet
initrd /boot/initrd.img-2.6.30-bpo.1-amd64
title Debian GNU/Linux, kernel 2.6.30-bpo.1-amd64 (single-user mode)
root (hd0,0)
kernel /boot/vmlinuz-2.6.30-bpo.1-amd64 root=/dev/sda1 ro single
initrd /boot/initrd.img-2.6.30-bpo.1-amd64
title Debian GNU/Linux, kernel 2.6.26-2-amd64
root (hd0,0)
kernel /boot/vmlinuz-2.6.26-2-amd64 root=/dev/sda1 ro quiet
initrd /boot/initrd.img-2.6.26-2-amd64
title Debian GNU/Linux, kernel 2.6.26-2-amd64 (single-user mode)
root (hd0,0)
kernel /boot/vmlinuz-2.6.26-2-amd64 root=/dev/sda1 ro single
initrd /boot/initrd.img-2.6.26-2-amd64[/quote]
ii linux-image-2.6-amd64 2.6.26+17+lenny1 Linux 2.6 image on AMD64
est-il un noyau ?
je peux faire “apt-get remove --purge linux-image-2.6-amd64” ?
Qu’est-ce que tu as dans /root ? t’aurais pas laissé traîner des choses? …
Normalement le / n’a pas besoin d’être très gros… (ce qui “est” dans /: bin boot etc lib root sbin et lost+found si des fichiers se sont “perdus”… le reste étant, dans ton cas, des “points de montages”… regardes dans ces répertoires ce qui cloche…)
[quote=“Num’s”]Qu’est-ce que tu as dans /root ? t’aurais pas laissé traîner des choses? …
Normalement le / n’a pas besoin d’être très gros… (ce qui “est” dans /: bin boot etc lib root sbin et lost+found si des fichiers se sont “perdus”… le reste étant, dans ton cas, des “points de montages”… regardes dans ces répertoires ce qui cloche…)
[/quote]
Sur la premiere sid, j’ai fait un / de 1go, et je le regrette, trop petit : il se rempli à la vitesse grand V avec les nombreuses mises à jour, et si je fais pas sans arrêt des apt-get clean, ma partition est pleine et ca pose des problèmes de lancement de services… 
Commence par un
apt-get clean
ça ne mange pas de pain.
ensuite, vire, au moins, un noyau :
apt-get remove --purge linux-image-le+vieux
Ne pas oublier ensuite de virer le dossier équivalent dans /lib/modules.
ensuite, tu reviens ici avec un
$ df -h
comme le dit ricardo # apt-get clean doit déjà libérer pas mal de place
je rajoute aussi d’installer localepurge et de lancer en root # localepurge
Pour utiliser gparted j’aime bien le livecd rescuecd qui comme son nom l’indique a tout pour retrouver un pc et il est très fiable.
-Enlever un noyau ne fait pas gagner “énormément” de place
-localepurge en revanche, parfois si
-idem, aptitude clean fait de la place
-le plus efficace à ton stade, c’est aussi d’installer xdiskusage (si tu peux encore, sinon y va falloir se farcire du en console) et localiser ce qui mange le plus de place. Y a 2 jours je m’apercevais grâce à ça que la doc de LaTeX me bouffait plusieurs centaines de mégas.
-tu n’as bien que 2 noyaux (comme Papa) : un des 3 paquets en est un virtuel qui en a juste installé un des 2 autres.
Par contre, si j’ai bien compris : d’après ton tableau, ton / fait 326,6 Mo. C’est pas “extrêmement” petit, pour rester poli ?
De mémoire et sans vouloir jouer mon chieur, lorsqu’on fait un apt-get/aptitude clean, c’est dans /var que ça libère de la place, hors chez notre ami, /var est une partition “à part”… du coup, pas très convaincu que ça lui libère de la place sur / … … 'fin bon… j’dis ça, j’dis rien… (tout comme pour le “localpurge” d’ailleurs…)
bien vu l’aveugle 
Mais du coup ca complique le problème 
[quote=“Num’s”]De mémoire et sans vouloir jouer mon chieur, lorsqu’on fait un apt-get/aptitude clean, c’est dans /var que ça libère de la place, hors chez notre ami, /var est une partition “à part”… du coup, pas très convaincu que ça lui libère de la place sur / … … 'fin bon… j’dis ça, j’dis rien… (tout comme pour le “localpurge” d’ailleurs…)
[/quote]
Exact !
Quant aux noyaux inutiles, excuse-moi mais 40 Mo, c’est quand même bon à prendre.
Oui enfin… Avant de virer les noyaux, y a tout le reste à voir. D’autant que dans son cas, c’est le noyau stable + un noyau backport, donc c’est pas du luxe question stabilité d’avoir le 2.6.26 pour retomber sur ses pattes au cas où (même si bon, OK, le 2.6.30 fait ses preuves depuis un moment déjà).
Par contre, je continue à penser qu’un xdiskusage pour voir où ça déborde, ça serait intéressant.
effectivement,apt-get clean n’a rien libéré sur /
J’ai raté ton post seb-ksl, du coup j’ai viré le 2.6.26
debian:/lib/modules# df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/sda1 327M 203M 108M 66% /
tmpfs 2,0G 0 2,0G 0% /lib/init/rw
udev 10M 832K 9,2M 9% /dev
tmpfs 2,0G 0 2,0G 0% /dev/shm
/dev/sda9 275G 34G 227G 13% /home
/dev/sda8 373M 11M 343M 3% /tmp
/dev/sda5 4,6G 2,9G 1,6G 65% /usr
/dev/sda6 2,8G 314M 2,4G 12% /var
apt-get remove --purge linux-image-2.6.26-2-amd64
a fait le ménage lui-même dans menu.lst et /lib/modules
[quote]Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances
Lecture des informations d’état… Fait
Les paquets suivants seront ENLEVÉS :
linux-image-2.6-amd64* linux-image-2.6.26-2-amd64*
0 mis à jour, 0 nouvellement installés, 2 à enlever et 0 non mis à jour.
Après cette opération, 80,1Mo d’espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? O
(Lecture de la base de données… 115016 fichiers et répertoires déjà installés.)
Suppression de linux-image-2.6-amd64 …
Suppression de linux-image-2.6.26-2-amd64 …
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory … found: /boot/grub
Searching for default file … found: /boot/grub/default
Testing for an existing GRUB menu.lst file … found: /boot/grub/menu.lst
Searching for splash image … none found, skipping …
Found kernel: /boot/vmlinuz-2.6.30-bpo.1-amd64
Updating /boot/grub/menu.lst … done
The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old
you may need to re-run your boot loader
The link /initrd.img.old is a damaged link
Removing symbolic link initrd.img.old
you may need to re-run your boot loader
Purge des fichiers de configuration de linux-image-2.6.26-2-amd64 …
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory … found: /boot/grub
Searching for default file … found: /boot/grub/default
Testing for an existing GRUB menu.lst file … found: /boot/grub/menu.lst
Searching for splash image … none found, skipping …
Found kernel: /boot/vmlinuz-2.6.30-bpo.1-amd64
Updating /boot/grub/menu.lst … done
[/quote]
… dit la tortue 
C’est sur que c’est beaucoup plus emmerdant pour toi, si tu retombes sur le dos
Ce n’est quand même pas inintéressant 
pour le module, quand il est bien luné, en effet, il le vire aussi mais il arrive que ça ne soit pas le cas.
Maintenant, avec 66% occupation, c’est acceptable.
Bon, ok, si tu avais une tonne de modules, c’est vrai que ça prend de la place. Donc ça c’est fait.
Maintenant, pour une solution plus durable (et pour ma culture) : une partition / de 327Mo, est-ce vraiment viable ?
Dans son cas, la majorité est déjà délocalisée (/dev, /tmp, /usr et /var), mais ça laisse /bin, /lib, /etc et autres. Donc est-ce vraiment judicieux ?
Edit : @dric : c’était tentant et c’est joliment tourné, j’accepte 
Moi aussi, je trouve que c’est ridiculement faible, surtout à l’heure où on a des DD de 1000 GO 
Quand certains fichiers ont mal été supprimés, il existe un fichier .local dans le fichier racine (ou root, j’ai un trou); il suffit de le supprimer.