|
Hello,
Donc après tout cela c'est bien un manque de recherches avec un
fichiers trash que tu aurais pu trouver avec un simple ls -ail ou
du sur ton home avec quelques regex ou arguments.
Inutile donc de jouer du fsck et de piper du sed grep et autres
choses, au vu de tes posts j'étais persuadé d'une faute
d'inatention et c'est bien le cas il fallait creuser plus en
cherchant à faire moins compliqué. (on s'est tous retrouvés un
jour dans ton cas)
Pour finir, dire que débuger avec live CD n'a de sens que lorsque
le sytème est freezé c'est juste faire preuve d'ignorance, ca
permet d'éviter de faire n'importe quoi sur son systeme. Un live
ca n'est pas orienté debutant, ca n'a pas qu'un seule utilité et
les plus confirmé utilisent des live y compris pour y bosser en
prod sur un laptop avec un hdd chiffré.
Bref beaucoup de bruit pour rien au moins t as solutionné ton
problème en cherchant. Moi je dirais que l'erreur est humaine dans
ton cas ;)
Le 09/18/2013 03:11 PM, Dorian Carpentier de Changy a écrit :
J'ai voulu prendre un peu de distanciation. J'ai résolu le cas
dans la foulée.
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
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?)
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.
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 )
Récompense!!:
... Super! J'ai repris la "main" sur Gnome GUI. JE peux m'en aller
flatter mon ego et l'amour propre des users sur la liste Debian
:-), en support.
L'idée que le le système avait rebooté ou mêm freezé en mode
rescue est fausse. Tte mention du bug, de mon point de vue, a pris
son origine dans l'interface std et fonctionnel de Gnome "bien
entendu".
Je cherchais à comprendre pratiquement ce qui pouvait m'avoir
conduit vers ce GUI "crash", etc.
finalement et merci à votre connaissance j'ai pu varier les
commandes.
outre # find -L /chemin_du_répertoire_cible |more et la lecture
de la sortie volumineuse, est la seule et dernière qui permis de
tracer un trait sur la contrariété en la faisant suivre de # rm
sur le fichier .
Pour les dubitatifs ou les moins crédules,
Bien au contraire, il trouvera sur google
un tas de tuto pour booter en live cd et faire sa maintenance.
(en plus il va progresser)
C'est bien plus simple de suivre une doc que de jouer avec les
du df et surtout de jouer avec du forcefsck et des commandes à
tout va sur son filesystem. Travailler en live sur un os
corrompu (ou autre) c'est un peu useless c'est de la perte de
temps.
Et qui, en tant que débutant, n'a pas réinstallé environ 76 fois
sa debian pour qu'elle soir stable
JE n'en suis pas à mon coup d'essai de déboguer - tuner mon
système. Certes je suis habitué à être sous M$ et partant je
débute sous linux,tt de même pas novice de chez novice, où je
connais plus de commandes, car son atout réside e.a dans son CLI
forcément. Certains man manquent de lisibilité je trouve et
n'hésite pas à poser de question. C aussi ça la doc sur www.google.com
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.
Carpe Diem , Dura lex sed lex,
Cordialement,
Dorian
Le 17/09/2013 17:23, Johnny B a
écrit :
Hello,
Il faut prendre les choses dans le bon ordre
T as eu des problèmes de freeze avec un reboot en mode rescue
il faut donc agir autrement on a assez tergiversé sur le
pourquoi du comment, le résultat est que ton système est
foiré.
La principale chose à faire est de booter sur un live CD qui
permettra enfin d'avoir une main "éclairée" ;) pour debuguer
ton OS
Tant que t'as pas booté sur un live et monté tes filesystems
ca sert a rien d'essayer de faire quoi que ce soit
|