la partition /dev/mapper/trisquel--vg-root est plaine
- Inicie sesión o regístrese para enviar comentarios
Salut à tous,
Je dois être damné car je reviens encore une fois avec un problème de "bourrage"...
En 2017, il y avait : https://trisquel.info/fr/forum/espace-libre-insuffisant-sur-le-disque
En 2020, il y avait : https://trisquel.info/fr/forum/espace-libre-insuffisant-sur-le-disque-2%C3%A8me
Aujourd'hui, c'est la partition /dev/mapper/trisquel--vg-root
root@machin-chose:~# df -hT
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
udev devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs tmpfs 780M 1.5M 779M 1% /run
/dev/mapper/trisquel--vg-root ext4 19G 17G 588M 97% /
tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mapper/trisquel--vg-home xfs 677G 415G 262G 62% /home
/dev/sda1 ext4 704M 156M 497M 24% /boot
tmpfs tmpfs 780M 44K 780M 1% /run/user/1000
Alors, si j'ai tout bien compris, cela correspond au dossier /root que j'ai analysé avec GdMap.
GdMap me dit que la taille des données est de 17.50G (ce qui correspond au "df")
/usr fait 10.67G
/var fait 5.93G
/lib fait 567.2M
/opt fait 248.3M
etc...
Ceci est correspond grosso merdo* à cela :
root@machin-chose:~# du -hd1 /usr /var /lib /opt | sort -hr
12G /usr
6.0G /usr/share
4.3G /usr/lib
4.0G /var
3.0G /var/lib
806M /var/log
783M /usr/bin
602M /lib
546M /lib/modules
270M /usr/src
255M /opt/ubports-installer
255M /opt
239M /var/cache
46M /usr/include
39M /usr/sbin
25M /lib/x86_64-linux-gnu
20M /usr/games
17M /lib/udev
16M /var/backups
8.7M /lib/systemd
4.7M /lib/i386-linux-gnu
2.1M /usr/libexec
956K /var/spool
324K /lib/firmware
216K /lib/terminfo
184K /usr/man
180K /usr/local
104K /lib/cryptsetup
64K /lib/netplan
56K /var/tmp
52K /lib/recovery-mode
52K /lib/crda
36K /lib/lsb
28K /lib/modprobe.d
24K /lib/security
16K /lib/init
16K /lib/hdparm
16K /lib/bridge-utils
16K /lib/apparmor
12K /opt/containerd
12K /lib/partman
12K /lib/linux-sound-base
12K /lib/ifupdown
12K /lib/console-setup
8.0K /lib/modules-load.d
4.0K /var/opt
4.0K /var/mail
4.0K /var/local
Bref, avec GdMap, je ne vois rien de particulièrement gros ou d'anormal...
Le plus gros fichier et /var/lib/clamav/daily.cld (173.6M) et /var/lib/clamav/main.cvd (162.6M) et le contrôle en lignes de commande donne :
root@machin-chose:~# du -hd1 -a /var/lib/clamav | sort -hr
337M /var/lib/clamav
174M /var/lib/clamav/daily.cld
163M /var/lib/clamav/main.cvd
288K /var/lib/clamav/bytecode.cvd
4.0K /var/lib/clamav/mirrors.dat
4.0K /var/lib/clamav/freshclam.dat
Voyez-vous quelque d'anormal là dedans ?
Est-il possible de faire quelque chose comme :
rm /var/log/*
Sauf erreur, cela ne risque rien et me permettrais déjà de gagné ~800M ?
Autrement il faut que je redonne 10G ou 20G à cette partition, mais là je n'ose pas trop faire sans votre aide...
Je souhaite résoudre ce problème avant de faire le saut vers T10 (je suis sous T9). Pour info, j'ai fait une sauvegarde total hier soir.
Merci d'avance à vous tous et happy hack ;-)
Références :
Alors, si j'ai tout bien compris, cela correspond au dossier /root que j'ai analysé avec GdMap.
Pas /root mais / (sans /boot et surtout /home qui sont sur des partitions différentes).
Voyez-vous quelque d'anormal là dedans ?
Tu pourrais analyser plus finement ce que /usr contient pour identifier peut-être un paquet (typiquement un jeu vidéo) qui prend beaucoup de place et que tu pourrais supprimer. Une application graphique pratique pour une telle analyse est l’« analyseur d’utilisation des disques » de GNOME, qui correspond au paquet appelé « baobab ».
Avant cela, tu peux toujours exécuter ces deux commandes pour faire un peu de ménage :
$ sudo apt autoremove
$ sudo apt clean
Autrement il faut que je redonne 10G ou 20G à cette partition, mais là je n'ose pas trop faire sans votre aide...
Je n’ai pas non plus d’expérience avec LVM. Néanmoins, je ne crois pas qu’il permette de réduire un système de fichiers XFS, que tu utilises pour /home et est le seul endroit ou tu pourrais prendre des Go. Il faudrait, je crois, sauvegarder les données des utilisateurs, supprimer la partition avec /home, étendre la partition racine dans l’espace libéré, et recréer /home dans l’espace restant pour y remettre les données sauvegardées. Cela demande aussi d’adapter /etc/fstab... et, encore une fois, je ne sais pas trop quoi d’autre qui viendrait de l’utilisation de LVM.
Salut Magic Banana,
Alors oui, je ne l'ai pas préciser, mais les commandes autoremove, clean et autoclean je les lance tout le temps depuis mes problèmes précédant ;-D
Avec le visualiseur GdMap, je vais chercher "système de fichier" et j'ai sélectionné le dossier /root et ca semble correspondre exactement à ce que tu dis : c'est "/" (la racine sans /boot et sans /home). Mais il y a bien tous les autres dossier /usr, /var, /lib, /opt, /bin et /sbin (si je n'ai rien oublier). De plus, comme je l'ai dis, les tailles semble bien correspondre. C'est peut-être une astuce intéressante si c'est juste ;-)
Effectivement, c'est le dossier /usr/share avec ses 6.0G qui peut certainement contenir des choses effaçable. Je vais voir tout ça après la rédaction de ce message.
Par contre, pour le redimensionnement, vu ce que tu dis, ça me coupe tout de suite l'envie de me lancer :-/
A ce tarif là, je refais une installation complète avec T10 et je restaure ma sauvegarde. Ce serait plus simple. A réfléchir...
Si tu fais une réinstallation, je te suggère d'utiliser ext4 pour /home, pas xfs. Comme ça, si un jour tu as de nouveau un problème de taille de /, tu peux redimmensionner /home par une simple commande lvresize et récupérer la place gagnée dans / par une autre commande lvresize.
Pour moi, utiliser xfs dans LVM pour prendre toute l'espace disponible pour /home est absurde à cause de cet impossibilité de diminuer /home, alors qu'avec ext4, c'est trivial.
J'ajoute que pour ceux qui veulent utiliser Guix pour avoir certains logiciels non disponibles dans Trisquel, Guix prend une place considérable dans /.
Salut Avron,
Super, merci pour ces conseils ;-)
En effet, je n'y connais pas grand chose à ce niveau là... :-(
Pour le chiffrement du DD, j'ai utilisé les config par défaut fourni à l'installation de Trisquel. N'y connaissant pas grand chose, je n'ose pas trop modifier ces paramètres par peur de faire une bêtise.
Je vais encore chercher un peu pour voir si je peux reprendre de la place (et j'aurai probablement des question à vous poser).
Mais il est fort probable qu'au lieu de faire le upgrade vers T10, je refasse une installation complète avec tes conseils et directement augmenter la taille de cette partition à 30G.
Je crois que je vais aussi réinstaller Trisquel sur le laptop sur lequel j'ai installé Trisquel 10 avec les paramètres LVM chiffré par défaut (donc /home en xfs), à cause du même problème, plus assez de place sur la partition root de 20G.
Dans mon cas, c'est à cause de Guix que c'est presque plein, et j'ai installé exactement 10 paquets de Guix, en comptant glibc-locales et fontconfig.
@Avron
Si tu réinitialise, tu pourras juste me faire un mini résumé de comment modifier les paramètres ?
L'un des soucis que j'avais eu, était la gestion des tailles de partition. En effet, il faut inscrire le chiffre de la taille souhaitée pour la partition, mais je ne sais pas si je devais modifier, dans les même proportion, les autres partitions manuellement ou si ça fait automatiquement ?
Du coup, si tu pouvais prendre juste quelques notes pendant ta procédure, ça m'aiderais beaucoup pour éviter de faire des bêtises.
Merci d'avance ;-)
Finalement, j'ai résolu le problème sans réinstaller, et tout a l'air de marcher.
Il faut:
- démarrer sur un système GNU/Linux sur une autre disque (ou partition)
- un espace disque suffisant pour une archive compressée de /home
Comme j'ai un deuxième disque avec Parabola, c'est ce que j'ai utilisé pour démarrer et pour la copie temporaire. Tu peux aussi démarrer sur une clé USB avec une image ISO d'installation Trisquel (choisir "essayer Trisquel sans l'installer") et connecter un autre disque pour le stockage de l'archive compressée de /home.
Sur mon disque, /home est dans une partition chiffrée. J'ai fait:
# cryptsetup luksOpen /dev/sda4 crypt_sdba
/dev/sda4 est à remplacer par la partition sur ton disque, le nom crypt_sda n'a pas d'importance. Cela te demande le mot de passe de chiffrement.
Ensuite, lsblk montre
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 223,6G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 513M 0 part
├─sda3 8:3 0 732M 0 part
└─sda4 8:4 0 222,4G 0 part
└─sda4_crypt 253:0 0 222,3G 0 crypt
├─vgtrisquel-root 253:1 0 18,6G 0 lvm
├─vgtrisquel-swap_1 253:2 0 1,9G 0 lvm
└─vgtrisquel-home 253:3 0 201,8G 0 lvm
sdb 8:16 0 465,8G 0 disk
├─sdb1 8:17 0 1G 0 part /boot
└─sdb2 8:18 0 464,3G 0 part
└─crypt_sdb 253:4 0 464,3G 0 crypt
├─maingroup-swapvol 253:5 0 8G 0 lvm [SWAP]
├─maingroup-rootvol 253:6 0 32G 0 lvm /
└─maingroup-homevol 253:7 0 200G 0 lvm /home
Je monte /home en lecture seule dans /mnt/trisquel-home
# mkdir /mnt/trisquel-home
# mount -o ro /dev/vgtrisquel/home /mnt/trisquel-home
D'après la sortie de lsblk, pour toi, /dev/vgtrisquel/home est probablement à remplacer par /dev/trisquel-vg/home
J'ai un seul utilisateur, disons arthur, je crée une archive
# cd /mnt/trisquel-home
# tar cvzf /home/arthur/arthur.tar.gz arthur
Pour la commande tar, après cvzf (c: créer une archive, v: montrer les fichiers, z: compresser, f: la mettre dans un fichier), c'est le fichier archive (à mettre sur le disque où tu peux écrire, moi c'est dans /home/arthur de mon système Parabola mais si tu as démmaré sur une clé USB, c'est le chemin d'un autre disque où tu peux écrire), puis c'est le répertoire de home à archiver.
Pour garder les permissions et propriétaire, il faut être root pour la commande tar.
S'il y a plusieurs utilisateurs, en faire une par utilisateur.
Une fois qu'on est sûr que les fichiers .tar.gz a ont été créés pour tous les utilisateurs:
# umount /mnt/trisquel-home
# lvresize -L -10G /dev/vgtrisquel/home
Ici, j'ai enlevé 10 Go à /dev/vgtrisque/home.
Attention, cette commande rend les données de /dev/vgtrisquel/home inutilisables, et lvresize demande confirmation. Il faut que les archives aient bien été créées avant, sinon on perd ses données.
# lvresize -r -L 10G /dev/vgtrisquel/root
Je rajoute les 10 Go au volume root et je redimmensionne le système de fichier de root en même temps (option -r, ça marche parce que root est en ext4).
Si home était en ext4, il aurait suffit d'utiliser l'option -r dans la commande sur home, et on aurait réduit directement le volume et le système de fichier en même temps, et ça serait tout, même pas besoin d'archive (mais en cas de fausse manip, une sauvegarde, c'est toujours mieux).
Comme on a réduit home sans redimmensionner le système de fichier, il est inutilisable, il faut en refaire un:
# mkfs.ext4 /dev/vgtrisquel/home
La commande prévient qu'il y a déjà un système de fichier xfs, on le sait, on veut l'écraser, donc on confirme. Ensuite, on le monte à nouveau et on y ajoute les fichiers archivés.
# mount /dev/vgtrisquel/home /mnt/trisquel-home
# cd /mnt/trisquel-home
# tar xvzf /home/arthur/arthur.tar.gz
# umount /mnt/trisquel-home
tar décompresse l'archive et extrait les fichiers (x, au lieu de c) dans /mnt/trisquel-home. S'il y a plusieurs utilisateurs, il faut le faire une fois pour chaque, puis umount.
Dernière chose: mettre à jour /etc/fstab.
# mkdir /mnt/trisquel-root
# mount /dev/vgtrisquel/root /mnt/trisquel-root
# nano /mnt/trisquel-root/etc/fstab
Il faut mettre à jour la ligne où il y a /home. Sur mon système, c'est:
/dev/mapper/vgtrisquel-home /home xfs relatime 0 0
Cela veut dire que /home est repéré par "/dev/mapper/vgtrisquel-home", ce qui n'a pas changé. Donc la seule chose à faire: changer "xfs" en "ext4", sauvegarder et quitter.
Au lieu de "/dev/mapper/vgtrisquel-home", il pourrait y avoir quelque chose comme "UUID=05da7c88-bf6f-4b4d-8774-0349dc682391" ou "LABEL=quelquechose".
Si c'est UUID, faire
# blkid /dev/vgtrisquel/home
Cela donne une autre valeur, il faut la mettre sur la ligne /home après "UUID=" à la place de la valeur actuelle.
Si c'est LABEL, d'après les docs, pas besoin de changer "LABEL=quelquechose" dans /etc/fstab, on peut mettre le label sur le système de fichier:
# tune2fs -L quelquechose /dev/vgtrisquel/home
Dans tous les cas, il faut quand même changer xfs en ext4 sur cette ligne. Aucune autre ligne ne doit être modifiée.
Quand c'est enregistré, on démonte:
# umount /mnt/trisquel-root
Et c'est fini, on peut redémarrer. Pour moi, tout à l'air de marcher.
Cela dit, je vais quand même essayer d'installer Trisquel sur un disque externe et voir si je trouve comment demander d'utiliser ext4 et pas xfs pour home.
WAW, magnifique Avron !
Par contre, je ne suis pas certain que j'oserai me lancer là-dedans :-/
Mais du coup, il faudrait transposer ta magnifique explication dans la partie wiki du site !
Je te ferai un retour si je me lance. Sauf que je suis quelque peu occupé à cause de la guerre donc ce ne sera pas tout de suite.
- Inicie sesión o regístrese para enviar comentarios