Bonjour,

Je n'ai pas pu faire ma mise à jour système (dnf update) parce que mon disque système n'a plus assez de place.

Si je tape df -h :
Sys. de fichiers            Taille Utilisé Dispo Uti% Monté sur
devtmpfs                      7,8G       0  7,8G   0% /dev
tmpfs                         7,8G    128K  7,8G   1% /dev/shm
tmpfs                         7,8G    1,6M  7,8G   1% /run
tmpfs                         7,8G       0  7,8G   0% /sys/fs/cgroup
/dev/mapper/fedora_pc6-root    50G     45G  1,7G  97% /
tmpfs                         7,8G    8,9M  7,8G   1% /tmp
/dev/sda2                     477M    150M  299M  34% /boot
/dev/sda1                     200M    9,5M  191M   5% /boot/efi
/dev/mapper/fedora_pc6-home   401G    192G  189G  51% /home
tmpfs                         1,6G     52K  1,6G   1% /run/user/1000
Comment je pourrais prendre de la place sur /dev/mapper/fedora_pc6-home pour en redonner à /dev/mapper/fedora_pc6-root sans rien casser ?
Ca peut se faire avec GParted ?

Physiquement je n'ai qu'un seul disque dur

Je me serais bien installé Flight Gear, mais là, c'est même pas la peine... :-/
Voilà aussi le fdisk -l , si ça peut servir...
Disque /dev/sda : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 8A5C8F82-754C-4AE4-8379-FE8537D4AD39

Périphérique   Début       Fin  Secteurs Taille Type
/dev/sda1       2048    411647    409600   200M Système EFI
/dev/sda2     411648   1435647   1024000   500M Données de base Microsoft
/dev/sda3    1435648 976773119 975337472 465,1G LVM Linux


Disque /dev/mapper/fedora_pc6-root : 50 GiB, 53687091200 octets, 104857600 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Disque /dev/mapper/fedora_pc6-swap : 7,8 GiB, 8338276352 octets, 16285696 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Disque /dev/mapper/fedora_pc6-home : 407,3 GiB, 437344272384 octets, 854188032 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
50Go de / plein ça doit en faire des applications si ce n'est pas que du cache ou de la base de données.

Tu peux commencer par un 
# dnf clean all
Puis que retourne 
# df -h
# du --exclude="/home" -x -h -a / | sort -r -h | head -30
Ensuite il est effectivement possible de redimensionner ce petit monde, mais déjà commencer par le début.
Je rejoins Nicoss, la première étape est de faire du ménage.

Ensuite, comme tu utilises LVM, c'est assez facile http://blog.moncoindunet.fr/linux/redimensionner-un-volume-logique/ . Par contre, autant augmenter la taille d'une partition à chaud est faisable, autant je crois que ce n'est pas possible de la diminuer. Voici les étapes. En premier lieu, il faut noter les commandes ci-dessous, fermer la session et taper CTRL+ALT+F2 pour ouvrir une nouvelle console et s'y connecter en tant que root. Ensuite, tu tapes: 
init 3
umount /home
lvresize -r -L -10G /dev/mapper/fedora_pc6-home
lvresize -r -L +10G /dev/mapper/fedora_pc6-root
mount /home
init 5
L'option -r de lvresize veut dire resizefs. Elle te permet de redimensionner en même temps le système de fichier, ce qui fait gagner du temps et évite les erreurs.
Énorme la place prise sur /
Effectivement, avant de redimensionner, il vaudrait mieux faire de la place correctement.
#dnf clean all
#rm -rf /var/cache/PackageKit
Un petit tour ici pour packagekit
voir aussi dans /var/log/journal
entre autres... sur mon système j'ai 2Go datant de 2016...
Un moyen simple de voir de qui prend de la place est d'installer filelight par exemple. Pas très beau mais pas lourd, 270ko et efficace

Gérard
GuL wrote:Je rejoins Nicoss, la première étape est de faire du ménage.

Ensuite, comme tu utilises LVM, c'est assez facile http://blog.moncoindunet.fr/linux/redimensionner-un-volume-logique/ . Par contre, autant augmenter la taille d'une partition à chaud est faisable, autant je crois que ce n'est pas possible de la diminuer. Voici les étapes. En premier lieu, il faut noter les commandes ci-dessous, fermer la session et taper CTRL+ALT+F2 pour ouvrir une nouvelle console et s'y connecter en tant que root. Ensuite, tu tapes: 
init 3
umount /home
lvresize -r -L -10G /dev/mapper/fedora_pc6-home
lvresize -r -L +10G /dev/mapper/fedora_pc6-root
mount /home
init 5
L'option -r de lvresize veut dire resizefs. Elle te permet de redimensionner en même temps le système de fichier, ce qui fait gagner du temps et évite les erreurs.
ATTENTION au système de fichier, c'est un coup à tout perdre, les simples commandes citées ci-dessus ne suffisent pas !
Hello,

Déjà merci pour ces réponses.
J'avais déjà fait le dfn clean all

J'ai suivi le conseil de winmandrake pour le cache de PackageKit (voir le lien ci-dessous)
winmandrake wrote:Énorme la place prise sur /
Effectivement, avant de redimensionner, il vaudrait mieux faire de la place correctement.
#dnf clean all
#rm -rf /var/cache/PackageKit
Un petit tour ici pour packagekit
Et là, miracle, le df -h donne ceci maintenant (passage de 97% à 57% d'utilisé pour /dev/mapper/fedora_pc6-root) : 
# df -h
Sys. de fichiers            Taille Utilisé Dispo Uti% Monté sur
devtmpfs                      7,8G       0  7,8G   0% /dev
tmpfs                         7,8G     48K  7,8G   1% /dev/shm
tmpfs                         7,8G    1,6M  7,8G   1% /run
tmpfs                         7,8G       0  7,8G   0% /sys/fs/cgroup
/dev/mapper/fedora_pc6-root    50G     27G   21G  57% /
tmpfs                         7,8G     28M  7,8G   1% /tmp
/dev/sda2                     477M    150M  299M  34% /boot
/dev/sda1                     200M    9,5M  191M   5% /boot/efi
/dev/mapper/fedora_pc6-home   401G    192G  189G  51% /home
tmpfs                         1,6G     32K  1,6G   1% /run/user/1000
Le lvresize me fait un peu peur. Il me semble qu'il faut s'assurer qu'on a pas de données dans la zone que l'on va supprimer lors d'une réduction...

J'ai effectivement pas mal d'applications dont une petite machine virtuelle pour faire tourner un Windows XP avec une ou deux applis Windows.

Au passage, voilà ce que donne, après purge du cache PackageKit, le du --exclude="/home" -x -h -a / | sort -r -h | head -30 (excellente commande que je ne connaissais pas) 
27G	/
18G	/usr
8,6G	/usr/share
6,4G	/var
4,2G	/var/log
4,2G	/usr/lib64
4,1G	/var/log/journal/b6db2224174e4e88a1d37622652c6951
4,1G	/var/log/journal
2,4G	/opt/lampp
2,4G	/opt
2,1G	/usr/lib
1,7G	/opt/lampp/htdocs/vv
1,7G	/opt/lampp/htdocs
1,6G	/usr/share/0ad
1,5G	/usr/share/doc
1,5G	/usr/share/0ad/mods/public/public.zip
1,5G	/usr/share/0ad/mods/public
1,5G	/usr/share/0ad/mods
1,2G	/opt/lampp/htdocs/[xxxxxxxxxxxxxxx]
1,1G	/var/cache
987M	/usr/share/locale
965M	/opt/lampp/htdocs/[xxxxxxxxxxxxxxx]
629M	/var/lib
620M	/usr/share/texlive
612M	/usr/bin
611M	/var/spool
610M	/usr/share/texlive/texmf-dist
535M	/var/cache/akmods/nvidia
535M	/var/cache/akmods
527M	/var/spool/abrt
Il y a aussi un utilitaire graphique dans "Administration / Analyseur d'utilisation des disques" qui fait de beaux camemberts et qui aurait pu m'aider à voir ce qui prenait anormalement trop de place...
Tu dois en outre avoir pas mal d'applications installées.

Les modifications de tailles sont faisable en toute sécurité mais il faut être méthodique.
Il me semble qu'il faut s'assurer qu'on a pas de données dans la zone que l'on va supprimer lors d'une réduction...
Mais non, resize2fs fait le travail proprement. Ca serait différent si tu diminuais la taille d'une partition ou d'un lv sans réduire le système de fichiers avant!
moudur wrote:Hello, 
...
4,1G	/var/log/journal/b6db2224174e4e88a1d37622652c6951
4,1G	/var/log/journal
...
Il y a aussi un utilitaire graphique dans "Administration / Analyseur d'utilisation des disques" qui fait de beaux camemberts et qui aurait pu m'aider à voir ce qui prenait anormalement trop de place...
à mon avis, il y 2Go à récupérer là. As-tu été voir ?
Gérard
fgland wrote:
moudur wrote:Hello, 
...
4,1G	/var/log/journal/b6db2224174e4e88a1d37622652c6951
4,1G	/var/log/journal
...
Il y a aussi un utilitaire graphique dans "Administration / Analyseur d'utilisation des disques" qui fait de beaux camemberts et qui aurait pu m'aider à voir ce qui prenait anormalement trop de place...
à mon avis, il y 2Go à récupérer là. As-tu été voir ?
Gérard
Oui, carrément. J'ai plusieurs gros fichiers de log de 2015 et 2016 !
Par contre, je ne sais pas comment limiter automatiquement la taille des logs à une taille beaucoup plus petite (par défaut c'est 4 Go, il paraît).
Il faut modifier la configuration du fichier /etc/logrotate.conf ?
Les options se règlent dans journald.conf regarde le man.
Nicosss wrote:
GuL wrote:L'option -r de lvresize veut dire resizefs. Elle te permet de redimensionner en même temps le système de fichier, ce qui fait gagner du temps et évite les erreurs.
ATTENTION au système de fichier, c'est un coup à tout perdre, les simples commandes citées ci-dessus ne suffisent pas !
nouvo09 wrote:
moudur wrote:Le lvresize me fait un peu peur. Il me semble qu'il faut s'assurer qu'on a pas de données dans la zone que l'on va supprimer lors d'une réduction...
Mais non, resize2fs fait le travail proprement. Ca serait différent si tu diminuais la taille d'une partition ou d'un lv sans réduire le système de fichiers avant!
J'ai déjà utilisé ces commandes sans soucis, mais je confirme qu'il ne faut surtout pas oublier l'option -r de lvresize, qui est l'équivalent d'utiliser resize2fs.
-r, --resizefs
Resize underlying filesystem together with the logical volume using fsadm(8).


Avec LVM, on peut considérer le système de fichier comme des poupées russes :
partition LVM > Physical Volume (PV) > Volume Group (VG) > Logical Volume (LV) > système de fichier ext4 ou swap
Pour réduire un LV, il faut commencer par réduire le système de fichier avec resize2fs puis réduire le LV d'exactement la même taille, sous peine d'écraser des données. Pour agrandir un LV, c'est le contraire : on commence par agrandir le LV puis on agrandit le système de fichier. Dans les deux cas, lvresize --resizefs fait le travail comme il faut, en déplaçant les données si besoin, et en redimensionnant le système de fichier au bon moment.

Pour compléter, un VG peut être créé à partir de plusieurs disques et contenir des LV à cheval sur les disques.
PV1 (100 Go) et PV2 (100 Go) > VG (200 Go) > LV1 (50 Go) et LV2 (150 Go) > systèmes de fichier /root et /home
On peut même aller encore plus loin : si on dispose d'un peu de place sur un SSD, on peut accélérer les disques à plateaux par le SSD au moyen d'un Thin Pool et d'un cache SSD. Voir à ce sujet le tutoriel que j'ai réalisé. Le Thin Pool permet d'accélérer simultanément plusieurs LV.
PV1 (SSD, 64Go) et PV2 (HDD, 500 Go) > VG (564 Go) > cache SSD (64 Go) > Thin Pool (500 Go) > LV1 (50 Go) et LV2 (450 Go) > systèmes de fichiers /root et /home
@GuL, tout à fait, mais il vaut mieux dissocier les actions afin de s'affranchir de tout souci, l'opération n'étant pas anodine et nécessitant d'être bien comprise. L'utilisation de e2fsck entre les manipulations du système de fichier est préférable aussi afin de s'assurer que tout est est OK, avant et après chaque opération.

A ce propos, ton tuto pourrait avoir sa place dans le wiki Fedora-Fr https://doc.fedora-fr.org/wiki/Accueil. Si la partie documentation t'intéresse alors tu pourrais peut-être contribuer https://doc.fedora-fr.org/wiki/Contribuer.
nouvo09 wrote:Les options se règlent dans journald.conf regarde le man.
Merci !

J'ai modifié la variable SystemMaxUse dans mon fichier /etc/systemd/journald.conf, elle était non définie (#SystemMaxUse=) et je l'ai passée à 500M, comme ci-dessous.
[Journal]
...
#RateLimitBurst=1000
SystemMaxUse=500M
#SystemKeepFree=
#SystemMaxFileSize=
...
Avec la commande "du --exclude="/home" -x -h -a / | sort -r -h | head -30", on voit ci-dessous que ça a bien été pris en compte (mon /var/log/journal ne fait plus que 553 M)
24G	/
18G	/usr
8,8G	/usr/share
4,3G	/usr/lib64
3,2G	/var
2,4G	/opt/lampp
2,4G	/opt
2,1G	/usr/lib
1,7G	/usr/share/0ad/mods/public/public.zip
1,7G	/usr/share/0ad/mods/public
1,7G	/usr/share/0ad/mods
1,7G	/usr/share/0ad
1,7G	/opt/lampp/htdocs/vv
1,7G	/opt/lampp/htdocs
1,5G	/usr/share/doc
1,4G	/var/cache
1,2G	/opt/lampp/htdocs/[...]
987M	/usr/share/locale
965M	/opt/lampp/htdocs/[...]
665M	/var/log
629M	/var/lib
620M	/usr/share/texlive
617M	/usr/bin
611M	/var/spool
610M	/usr/share/texlive/texmf-dist
553M	/var/log/journal/b6db2224174e4e88a1d37622652c6951
553M	/var/log/journal
542M	/var/cache/akmods
541M	/var/cache/akmods/nvidia
527M	/var/spool/abrt

Et le df -h montre que mon système est passé de 97% d'utilisation de mon disque à 51%
Sys. de fichiers            Taille Utilisé Dispo Uti% Monté sur
devtmpfs                      7,8G       0  7,8G   0% /dev
tmpfs                         7,8G       0  7,8G   0% /dev/shm
tmpfs                         7,8G    1,6M  7,8G   1% /run
tmpfs                         7,8G       0  7,8G   0% /sys/fs/cgroup
/dev/mapper/fedora_pc6-root    50G     24G   24G  51% /
tmpfs                         7,8G     32K  7,8G   1% /tmp
/dev/sda2                     477M    150M  298M  34% /boot
/dev/sda1                     200M    9,5M  191M   5% /boot/efi
/dev/mapper/fedora_pc6-home   401G    192G  189G  51% /home
tmpfs                         1,6G     44K  1,6G   1% /run/user/1000
Et donc, ça me va très bien, je vais en rester là, merci !

Merci GuL pour tes excellentes précisions sur le redimensionnement du système de fichier et son fonctionnement en poupées russes... Ca me servira peut-être plus tard si je finis quand même par manquer de place.
Nicosss wrote:A ce propos, ton tuto pourrait avoir sa place dans le wiki Fedora-Fr https://doc.fedora-fr.org/wiki/Accueil.
Oui, carrément ! 🙂
+ le nettoyage de PackageKit et la limitation de la taille des log, peut-être ?
Nicosss wrote:@GuL, tout à fait, mais il vaut mieux dissocier les actions afin de s'affranchir de tout souci, l'opération n'étant pas anodine et nécessitant d'être bien comprise. L'utilisation de e2fsck entre les manipulations du système de fichier est préférable aussi afin de s'assurer que tout est est OK, avant et après chaque opération.

A ce propos, ton tuto pourrait avoir sa place dans le wiki Fedora-Fr https://doc.fedora-fr.org/wiki/Accueil. Si la partie documentation t'intéresse alors tu pourrais peut-être contribuer https://doc.fedora-fr.org/wiki/Contribuer.
Tu as sans doute raison, mais il me semblait que e2fsck était fait automatiquement.

Je vais envoyer une suggestion à la liste de diffusion en charge de la documentation mais je n'aurai pas le temps de faire la mise en page (3 gamins + travail prenant + thèse en cours + passions).
6 jours plus tard
Merci à tous !!
GuL wrote:
Nicosss wrote:@GuL, tout à fait, mais il vaut mieux dissocier les actions afin de s'affranchir de tout souci, l'opération n'étant pas anodine et nécessitant d'être bien comprise. L'utilisation de e2fsck entre les manipulations du système de fichier est préférable aussi afin de s'assurer que tout est est OK, avant et après chaque opération.

A ce propos, ton tuto pourrait avoir sa place dans le wiki Fedora-Fr https://doc.fedora-fr.org/wiki/Accueil. Si la partie documentation t'intéresse alors tu pourrais peut-être contribuer https://doc.fedora-fr.org/wiki/Contribuer.
Tu as sans doute raison, mais il me semblait que e2fsck était fait automatiquement.

Je vais envoyer une suggestion à la liste de diffusion en charge de la documentation mais je n'aurai pas le temps de faire la mise en page (3 gamins + travail prenant + thèse en cours + passions).
Oui je sais ce que c'est 😉

Pour le e2fsck je ne crois qu'il soit fait automatiquement. En tout cas je ne prends pas le risque, même si je genre d'opérations est à la marge pour moi.

N'hésite pas à faire un mot à la ML.