Je ne connais pas spécialement le fonctionnement des systèmes live en général ni Parrot en particulier. Si je comprends bien ce qui est affiché, la racine du système de fichiers / résulte d’une union par OverlayFS entre
-
un système de fichiers en lecture seule de type Squashfs de 1,6 Gio contenu dans un fichier image monté en loop (anglais) sur /run/live/rootfs/filesystem.squashfs pour la partie statique
-
un système de fichiers temporaire en mémoire de type tmpfs de 4 Gio (soit la moitié de la RAM, valeur par défaut) monté sur /run/live/overlay pour la partie volatile
Le tmpfs contient les fichiers modifiés ou créés lors de l’exécution du système live. Or il est plein. Je suis surpris qu’un système live qui vient de démarrer ait eu besoin d’écrire 4 Gio dans sa racine. Si ça avait été un système installé de façon classique, j’aurais soupçonné une inflation des logs dans /var/log causée par des messages répétitifs mais j’ignore comment ce système live gère ses logs.
En tout cas le résultat de la commande free
indique que ce n’est pas un manque de mémoire.
Il est néanmoins possible d’appliquer la méthode habituelle pour identifier ce qui prend le plus d’espace. La commande suivante classera les répertoires de la racine par taille décroissante.
du -hxd1 /run/live/overlay | sort -h
Ensuite on peut recommencer avec les répertoires les plus volumineux, par exemple si c’est /var :
du -hxd1 /run/live/overlay/var | sort -h
Et ainsi de suite récursivement.