Le contenu de /tmp est normalement supprimé à chaque redémarrage contrairement à ceux de /var/tmp qui ont vocation à perdurer d'avantage.
Donc une solution simple (si possible) => # reboot
Peut-être que justement la machine tourne depuis (trop) longtemps ???
Pour les "gros fichiers" fichiers du groupe lp
si tu es l'unique utilisateur du système,
tu devrais savoir à quel travaux d'impression ils correspondent.
sinon faire une copie sur un support externe et supprimer au moins le plus dodu
Tu verras bien si un autre utilisateur râle....]]>
ça m'est déjà arrivé ce genre de chose la clé pas détecté au démarrage , mais détecté après un reboot
Effectivement, le boot sur la clé est alors proposé.
Mais hélas le PC démarre quand même sur W10. La clé contient un iso Gparted, qui fonctionne sur d'autres PC.
Et pendant que je le tripotais il a commencé des màj . . .
Merci d'être venus mais j'abandonne ]]>
Dans la colonne "Help" de la seconde image, je lis "'Delete' deletes an unprotected device".
C'est bien ce qu'il fallait faire. J'avais essayé mais sans résultat. Le boot debian disparaît, mais après le re-démarrage du PC "ce à quoi je n'ai pas pensé".
Merci à vous deux.]]>
Merci, je vais donc mettre à jour avec un "apt update && apt upgrade" au-lieu des "apt update && apt dist-upgrade"
Merci beaucoup]]>
Ah ben oui: pas de table de partition sur le disque HDD 'sdb', le disque entier est «en direct» avec le système de fichier BTRFS...
Je rejoins raleur, c'est plus lisible avec l'utilisation d'une table de partition.
Quelques liens:
Dans le wiki Ici (date de 2014, mais les principes demeurent sans doute)
Un article là (m'énerve les articles non datés !)
Afficher l'utilisation de l'espace disque :
$ btrfs filesystem df -h /data
$ btrfs filesystem show /dev/vdb1
@+]]>