Re: Impossible de démarrer en GUI , partition /dev/sdax utilisé à 100%
Le mercredi 18 septembre 2013 à 15:11, Dorian Carpentier de Changy a écrit :
> J'ai voulu prendre un peu de distanciation. J'ai résolu le cas dans
> la foulée.
Bonne nouvelle !
> Primo, prendre par le début.
> >Dans le répertoire de travail j'ai retrouvé le fichier et l'ai supprimé.
> >Le fichier n'existe bien plus, pensais-je. df m'indique tjs 100%
> >d'utilisation sur /dev/sda5
> Le fichier existait dc bien par qq moyen que ce soit, je ne saurai
> pas si il s'agissait d'un symlink, j'ai négligé # ls -l ou d'un
> point de restauration (comme ds la corbeille sous Win) car ça y
> ressemble fort
Il n'y a pas de « point de restauration ». En revanche, les bureaux fournissent
une corbeille et la suppression d'un fichier l'envoie en général dedans. Il faut
ensuite vider la corbeille. Processus habituel maintenant.
Un lien symbolique n'occupe pas d'espace disque (hormis la taille de bloc
utilisée par l'inode).
> Deuxio,
> >T as surement un symlink ou un truc en cache qui fou le bordel,
> >t'aurais pas renommé ton dossier au lieu de le supprimer par
> >hasard ?
> (Il n'y avait pas du tout de lien symbolique de ma part, à
> fortiori. Et puis à ma connaissance rm doit détruire définitivement
> le fichier! Vrai-Faux ? Lorsque j'avais encore la main sur le GUI et
> que j'ai détruit le fichier sur un mode fenêtré (exit cli ),
> l'effacement ne s'est pas opérée de la même manière qu'un rm en mode
> cli?)
« rm doit détruire définitivement le fichier! Vrai-Faux ? »
Vrai ET faux !
Tu peux faire la manip toi-même.
Dans un premier terminal :
# touch /tmp/toto && tail -f /tmp/toto
Dans un autre terminal :
# rm /tmp/toto && lsof +L1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
tail 14112 sni 3r REG 0,18 0 0 253909 /tmp/toto (deleted)
Tu as donc un fichier supprimé mais toujours ouvert.
Si tu fais un CTRL-C dans le premier terminal, il disparaîtra.
> Tertio,
> Un memo sur mon modus op:
> >lancer un fsck m'averti que le système de fichier est monté, que
> >je ****VAIS**** causer des dommages ****SEVERES**** au système de
> >fichier.
> Moi pas bille en tête j'ai poliment décliné plutôt que de sauter
> sans parachute…. Au lieu j'ai suivi effectivement:
> http://doc.ubuntu-fr.org/verification_de_fichiers
> et http://doc.ubuntu-fr.org/fsck où # touch /forcefsck && reboot
> était explicite
> La vérification n'a retourné aucune erreur. Ce qui aura eu pour
> mérite de m'orienter sur la solution introduisant §2 et m'y coller.
Point rassurant, ton système de fichiers n'est pas corrompu !
> CCL:
> Voici l'opération de remédiation/guérison finale:
>
> _/*Google est ton ami! _*/: # find -L /chemin_du_répertoire_cible
> |more (logiquement retourne les liens symboliques)
> J'ai repéré l'un de ces chemin: "
> /home/dorian/.local/share/Trash/infos ET files". Surprise un fichier
> comportant le nom du fichier visé y figurait.
> Avec la contagion refluant le foirage je n'ai pas vérifié ses
> paramètres (espace disque -déjà connu,mais type, erreur ?) , j'ai
> lancé un rm sur le contenu du dossier (pas de mal ici)...x )
En gros tu as vidé la corbeille :-)
> JE ne suis pas un fan des liveCD, je pars du principe que depuis le
> DVD/CD d'install ou même le démarrage en mode réparation, il y a
> moyen de curer le système. Pour preuve! ... Enfin, le proverbe
> <avoir une main "éclairée" sur le système>, en faisant usage d'un
> live cd ne prend pas tout son sens, puisque il commence à avoir son
> crédit quand "effectivement" le système freeze, est inaccessible ou
> que des utililtaires ne sont que accessibles par un support externe.
> En résumé, voilà le critique que je fais aux non-croyants et
> incrédules.
Tu verras par toi-même que parfois, on n'y coupe pas, mais je suis d'accord avec
toi que la plupart des cas trouvent une solution sans avoir à aller jusque là.
Seb
Reply to: