Forum

Bonsoir à toutes et à tous, cet après-midi je me suis connecté sur un système Debian que j'ai en parallèle de Mageia 8.
Quand j'ai voulu me reconnecter sur Mageia 8 je n'ai pas pu, je passais le menu Grub puis choix Mageia 8 mais la connexion ne se faisait pas. Je suis allé sous un terminal (alt F2) j'ai essayé en root: startx mais ça ne marchait pas.
Ensuite il m'a mis le message suivant: "Failed to start update UTMP about system runlevel changes".
Je suis allé voir sur le web et j'ai cru comprendre qu'il pouvant y avoir un problème avec le pilote propriétaire NVIDIA.
Euh ... oui j'ai oublié de dire que j'utilise mageia-prime. Je me suis reconnecté sur un terminal root et j'ai passé la commande : "mageia-prime-uninstall -z". Et là ça a marché, j'ai retrouvé le système.
Par contre un truc qui m'étonne, j'ai voulu mettre mon système à jour et il me dit que la racine est pleine, ce que me confirme la commande df -h !!
Je suis un peu surpris, et je voulais savoir s'il y aurait un moyen qui pourrait confirmer ou infirmer cet état de fait ?!
Autre question, est-ce qu'un urpme --auto-orphans (ou autre commande ...) pourrait me libérer de la place, bien entendu sans plomber le système ?!
Je vous remercie pour les réponses que vous pourrez m'apporter.
Question subsidiaire: est-ce que les commandes "mageia-prime-uninstall -z" et "mageia-prime-install -z" passées relativement souvent peuvent avoir une incidence sur la place occupée par la racine ?

Ça a fait de la place (maigre, mais place) qui a permis de démarrer.

S'il dit que c'est plein, ça l'est. Et un symptôme : ne boot plus car il ne peut plus écrire les logs :-D
Tu peux analyser avec :

Et ainsi de suite pour trouver un fichier obèse d'un paquet à désinstaller ou un fichier (par exemple un log) a supprimer.

Non, il faut analyser avant, ça peut potentiellement plomber le système. Mais c'est a faire.

Je ne pense pas.

Bonjour,
Vérifie en plus si tu n'aurais pas tout un stock de noyaux qui ne servent plus. Ceux-ci ne sont pas supprimés automatiquement et créent de l'embonpoint morbide.
Tu peux aussi lancer cette commande qui permet d'effacer des résidus qui ne servent plus dans /var/lib/urpmi/rpms :

voi aussi dans /var/log/journal/XXXXXXXXX/

Attention, il me semble que journal est géré par journalctl qui a des argument pour vider ses journaux, limiter, tronquer, virer les plus vieux, …

Bonjour,

Il est possible de limiter la taille des journaux.

Mais avant tout, savoir quelle taille font les journaux.

Lancer une console, puis passer en root ( su- votre mot de passe et valider).

Taper la commande :


Dans mon cas, la commande retourne : Archived and active journals take up 16.0M in the file system

Première étape, relancer les journaux avec la commande rotate :

Toujours en root :



Puis, nous allons nettoyer et seulement conserver les derniers journaux, disons les 10 derniers Mo.

En root :

Pour s'assurer que la taille a bien diminuée : En root, de nouveau :

Pour limiter la taille des fichiers de façon pérenne, modifier le fichier /etc/systemd/journald.conf .

Toujours en root :

Décommenter la ligne : SystemMaxUse=

Et mettre la valeur souhaitée. J'ai personnellement mis 100M

Ce qui donne : SystemMaxUse=100M

Faite la combinaison de touche Ctrl+x, il vous sera demandé si vous souhaitez modifier le fichier, taper O, puis validez.

Puisque vous êtes toujours en root, on relance le service pour que les modifications soinet prise en compte :



Et voilà, vos journaux ne dépasserons plus la taille de 100M

Édité par Visiteur Le 13/04/2021 à 10h25

Bonjour à toutes et à tous, merci beaucoup pour toutes ces infos
Aujourd'hui je ne suis pas chez moi, mais ce soir quand je rentrerai, je vais relire toutes vos indications et faire tout ça puis je posterai ensuite le résultat.

Bonjour, avant de partir de chez moi, j'ai pu faire ce que dit vigen c'est à dire limiter la taille des journaux, effectivement ça a un peu diminué mais je reste quand même à 100 % d'utilisation pour la racine.


Ensuite:
J'ai mis le premier résultat dans un fichier que je joins:
pax.txt

Il y a un truc bizarre 31G . !!!!!!!!!!!!! c'est quoi ?

Ensuite
ça plante:


Euh ensuite j'ai fait un rebuilddb il y avait une rpmold qu'il ne pouvait pas détruire, je l'ai détruite à la main puis repassé un rpm --rebuilddb ça a marché et maintenant urpmi --clean a marché également (enfin je n'ai plus de message d'erreur.

Bon pour le moment j'en suis là, j'ai toujours 100 % d'utilisation pour la racine,

pour votre aide.

Salut !



Après verif, ce matin j'avais 4Go de journeaux !!!

Un petit régime, ça ne fait pas de mal

De plus, 5% du système de fichiers ext4 est réservé à l'utilisateur "root". Il peut s'agir de nombres énormes (des dizaines de gigaoctets), en fonction de la taille de la partition.

Définir une valeur de 1%:


Voir combien est réservé:


Toutes les informations du système de fichiers sur /dev/sda1:

Édité par Visiteur Le 13/04/2021 à 19h39

ah zut, j'ai oublié le h...

Pour savoir ce que c'est, tu peux faire :

On voit qu'il y a un .
On peut regarder en détail :

C'est un dossier, donc on peut l'ouvrir, ou on peut demander de lire le lien réel :

Bon le lien existe bien, on peut l'ouvrir :

Le dossier existe bien, on a pu l'ouvrir, où sommes nous ?

Où sommes nous ?! Ahhh je suis perdu !

Bon j'arrête de déconner. le dossier . est un lien vers le dossier actuel, et le dossier .. est un lien vers le dossier parent. Tu as souvent du lire cd ../ ou lancé des commandes comme ./configure, on ne fait que préciser le chemin

Ta partition root me parait vite chargée...
Peux tu faire :

pour voir sa taille ?

Avec la commande "du -Phax -d 1 | sort -rh"
du affiche le "disk usage" des fichiers, avec -Pax on évite de sommer ce qui n'appartient pas au système de fichier (par exemple, la racine / a sa partition, mais /home (qui est dans la racine) est sur une autre partition, donc on l'exclue, pareil pour /sys, /dev, ...) avec -d 1 on ne vient afficher que les premiers répertoires (sans afficher les sous répertoires, sinon ça vient lister tous les fichiers, quelques milliers, millions ?).
la portion sort -rh vient afficher dans l'ordre du plus "gros" au plus petit.

Il y a quelques trucs dans ton résultat qui me "saute" au yeux :
1,4 Go dans root → mon mien ne fait pas 1Mo. Tu as quelque chose qui a créé des data en root.
18 Go dans usr → tu as plein de truc d'installer, il faudra examiner.
600 Mo dans opt → mageia ne propose RIEN dans ce répertoire, tu as installé des logiciels tiers ne venant pas de Mageia dedans.
(preuve : urpmf /opt/ | grep ":/opt" )

Pour analyser usr :

Bonjour,
Moi, ce qui m'interpelle en outre, c'est /var, 11 Go. C'est prévu pour y stocker des données, mais pas les fichiers utilisateur.
On y trouve aussi des logs, aussi. Des fois, ça peut partir en vrille.

Édité par Papoteur Le 13/04/2021 à 14h09

Bonjour, Jybz merci pour ta réponse. Bon je ne comprends pas tout ce que tu me dis, peut-être que tu te moques un peu de mon ignorance mais ça ne me vexe pas du tout.

Quand tu dis que "le dossier . est un lien vers le dossier actuel" veux-tu dire que c'est un lien vers /home/user/ ?
Si oui, ce que je ne comprends pas c'est qu'un lien fasse plus de 30 Go !! ça me parait beaucoup pour un lien non ? et si c'est le dossier pointé par le lien qui fait 30 Go alors je peux te dire que chez moi /home/user/ fait beaucoup plus que 30 Go ...!!!
Bref, pour le moment je ne suis pas chez moi, je ne peux donc pas intervenir sur ma machine, mais dès que je rentre je vais voir tout ça.



Pour les logs j'ai déjà fait le nécessaire avec ce que m'a dit vigen, ensuite trouver un fichier obèse d'un paquet à désinstaller, soit mais je ne sais pas trop comment je vais décider que tel ou tel fichier est obèse et désinstaller le paquet heu ... si je sais ce que c'est ok mais sinon ? ... bon à voir.
Je vais également faire ce que me disais Papoteur: voir si je n'aurai pas un stock de noyaux que je pourrais supprimer.
Ensuite je posterai pour dire où j'en suis.
à toutes et à tous pour votre aide.