Vous n'êtes pas identifié(e).
Dernière modification par Philou92 (14-06-2015 23:20:13)
Tousse antique Ovide !
Hors ligne
Dernière modification par misaine (29-05-2015 22:13:06)
amd phenom 7650 , 4 Go DDR2 ,GeForce N210
Hors ligne
Tousse antique Ovide !
Hors ligne
Hors ligne
Tousse antique Ovide !
Hors ligne
Tousse antique Ovide !
Hors ligne
Dernière modification par misaine (30-05-2015 13:44:04)
amd phenom 7650 , 4 Go DDR2 ,GeForce N210
Hors ligne
Puis df -hT
puis j'ai démonté /dev/sda1 et lancé le fsck dessus:
Bon il demande si je suis d'accord pour la réparation. Si j'ai bien compris la prose de maître "Smolki", à priori je dois répondre "y".
Est-ce bien cela?
Dernière modification par Philou92 (30-05-2015 17:28:51)
Tousse antique Ovide !
Hors ligne
Tousse antique Ovide !
Hors ligne
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
Tousse antique Ovide !
Hors ligne
Tout est OK.
Je ne serais pas aussi optimiste. C'est plutôt "jusqu'ici tout va bien".
Plusieurs inodes (fichiers) partageaient les mêmes blocs. C'est une incohérence grave du système de fichiers. fsck a cloné (dupliqué) les blocs en question afin que chacun n'appartienne qu'à un seul fichier. Le souci, c'est que la situation de départ est anormale, il y avait des mélanges entre le contenu de plusieurs fichiers et ce problème n'a pas été corrigé.
Dans l'exemple ci-dessus, les fichiers /var/log/dpkg.log.1 partageait 55 blocs avec le fichier /var/lib/dpkg/info/libasprintf0c2:amd64.list. Or /var/lib/dpkg/info/libasprintf0c2:amd64.list (installé avec le paquet libasprintf0c2, dont il contient la liste des fichiers), ne devrait contenir que quelques lignes, soit moins d'un bloc. Si tu examines son contenu, je soupçonne qu'il s'agit de logs de dpkg provenant de /var/log/dpkg.log.1. Dans ce cas le contenu de /var/lib/dpkg/info/libasprintf0c2:amd64.list est corrompu, et cela se manifestera probablement par des erreurs à la prochaine opération sur ce paquet (désinstallation, mise à jour).
As-tu conservé la liste des fichiers impactés pour les vérifier ?
Il vaut mieux montrer que raconter.
Hors ligne
Philou92 a écrit :Tout est OK.
Je ne serais pas aussi optimiste. C'est plutôt "jusqu'ici tout va bien".
Plusieurs inodes (fichiers) partageaient les mêmes blocs. C'est une incohérence grave du système de fichiers. fsck a cloné (dupliqué) les blocs en question afin que chacun n'appartienne qu'à un seul fichier. Le souci, c'est que la situation de départ est anormale, il y avait des mélanges entre le contenu de plusieurs fichiers et ce problème n'a pas été corrigé.
Dans l'exemple ci-dessus, les fichiers /var/log/dpkg.log.1 partageait 55 blocs avec le fichier /var/lib/dpkg/info/libasprintf0c2:amd64.list. Or /var/lib/dpkg/info/libasprintf0c2:amd64.list (installé avec le paquet libasprintf0c2, dont il contient la liste des fichiers), ne devrait contenir que quelques lignes, soit moins d'un bloc. Si tu examines son contenu, je soupçonne qu'il s'agit de logs de dpkg provenant de /var/log/dpkg.log.1. Dans ce cas le contenu de /var/lib/dpkg/info/libasprintf0c2:amd64.list est corrompu, et cela se manifestera probablement par des erreurs à la prochaine opération sur ce paquet (désinstallation, mise à jour).
As-tu conservé la liste des fichiers impactés pour les vérifier ?
Oups!
Concernant la liste des fichier, je n'ai pas plus d'info que le résultat (ci-dessus) renvoyé par la commande "fsck" exécutée à partir du cd live. Je n'ai pas pensé (par ignorance) conserver les traces de son exécution. A priori je pense qu'il n'y a que ce fichier qui est concerné.
J'ai vérifié le contenu du fichier "libasprintf0c2:amd64.list", tu as vu juste, il est identique au contenu du log "dpkg.log.1" (3124 lignes).
Du coup quelle est la marche à suivre pour corriger cette anomalie?
Tousse antique Ovide !
Hors ligne
Le contenu correct du fichier /var/lib/dpkg/info/libasprintf0c2:amd64.list est le suivant :
Pour les autres, il faudra voir au cas par cas si et comment il est possible de les restaurer.
Il vaut mieux montrer que raconter.
Hors ligne
Désolé d'être l'oiseau de mauvais augure.
Bien au contraire j'apprécie beaucoup l'aide que tu m'apportes et t'en remercie. Elle me permet également de comprendre les aspects fondamentaux du système.
J'ai donc exécuté la commande suivante:
Résultats:
j'ai consulté à la "mano" le contenu des fichier du répertoire /var/lib/dpkg/info et les autres répertoires. Excepté pour "libasprintf0c2:amd64.list" je n'ai pas constaté à priori d'anomalie. Les contenus me semblent cohérents avec leur titre. Mais bon c'est avec une vue de béotien, donc si tu vois d'autre vérifications à faire n'hésite pas à me les signaler.
Je vais corriger "libasprintf0c2:amd64.list"avec le contenu que celui que as fourni. Merci car je ne sais pas ou j'aurais pu trouver cette source.
Pour info, je vais m'éloigner de mon PC (snif....) pendant une semaine.
Dernière modification par Philou92 (11-06-2015 21:23:18)
Tousse antique Ovide !
Hors ligne
Je soupçonne très fortement que l'un des fichiers de chaque paire a le contenu de l'autre, et donc que son contenu originel est perdu.
Les fichiers d'archives de paquets .deb téléchargés dans /var/cache/apt/archives/ peuvent être supprimés s'ils sont corrompus.
Les fichiers de backup de dpkg /var/backups/dpkg.* ne sont pas indispensables.
Le fichier dans /var/tmp est un fichier temporaire, sa perte n'est pas grave.
Les fichiers dans /lost+found ont été récupérés par fsck, à voir ce qu'ils contiennent.
Une part importante des fichiers est dans /var/lib/dpkg/info et contient des informations sur les paquets installés. Cele finira immanquablement par poser des problèmes avec dpkg ou apt.
A noter qu'ils y a dans la liste des répertoires comme /var/cache/man qui partagent leur contenu avec un fichier. Je me demande ce que cela se produit, dans un sens ou dans l'autre.
Il vaut mieux montrer que raconter.
Hors ligne
Conclusion, comme Raleur l'a correctement analysé, j'ai un nombre non négligeable de fichiers corrompus :
Les fichiers que je peux à priori supprimer sans risque
Les fichiers qu'il va falloir que je corrige:
Enfin les fichiers dont je ne sais pas s'il faut les corriger ou si je peux les supprimer sans risques:
Pour ces deux derniers item j'ai lu sur le forum Ubuntu qu'il serait possible de s'en sortir avec la commande dpkg mais pour moi c'est pour le moment des opérations de haut niveau et à haut risque. Aussi votre aide me sera la bien venue car là je sèche.
Dernière modification par Philou92 (13-06-2015 13:09:41)
Tousse antique Ovide !
Hors ligne
Tousse antique Ovide !
Hors ligne
Méthode "Bourrin" qui m'a pris 3 heures, mais efficace. Si quelqu'un à une méthode plus élégante à me proposer, je suis preneur.
Sachant seulement après coup le temps consommé, et nonobstant l'aspect formateur de ce que tu as fait, je mettrais en balance une réinstallation complète.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Pour les permissions de "man", j'ai un peu galéré car la commande "cp -a" ne conserve pas les permissions en passant à travers les deux mondes "Virtualbox" et mon PC. J'ai donc cherché et trouvé une commande magique (find) susceptible d’intéresser la communauté:
Cette commande permet de modifier les permissions du répertoire et récursivement des sous-répertoires sans toucher aux fichiers (qui étaient OK).
Elle doit être exécutée à la racine du répertoire à modifier.
Donc pour fixer la permission drwxr-sr-x aux répertoires de "man" j'ai procédé en deux commandes:
la première pour tout passer en drwxr-xr-x
la seconde pour donner la permission sguid aux répertoires (drwxr-sr-x)
A noter que si vous souhaitez modifier les permissions uniquement des fichiers et pas des répertoires c'est la commande suivante qu'il aurait fallu taper:
Exemple pour une permission commune de chaque fichier en -rw-r--r--
J'ai appliqué les dernières mises à jour des paquets (passage en Debian 8.1 entre autre) et à priori tout s'est déroulé correctement.
Je vais donc marquer le titre comme RESOLU.
Je tiens vraiment à remercier encore une fois la communauté du site et plus particulièrement "Raleur" pour son aide. Sans ses connaissances pointues sur le fonctionnement du système de fichier Gnu/Linux j'aurais probablement été obligé de passer par la case "ré-installation" et je serai resté ignorant sur beaucoup d'aspects techniques fort utiles à connaître.
En conclusion de mes mésaventures j'oserais deux conseils qui m'ont fait défaut: faites des sauvegardes système, ayez une image iso debian-live sous la main sur DVD cela vous sera utile en cas de pépin.
Dernière modification par Philou92 (18-06-2015 21:15:34)
Tousse antique Ovide !
Hors ligne
En conclusion de mes mésaventures j'oserais deux conseils qui m'ont fait défaut: faites des sauvegardes système, ayez une image iso debian-live sous la main sur DVD cela vous sera utile en cas de pépin.
Et une autre machine reliée au net ...
Hors ligne
Et une autre machine reliée au net ...
Bah, si tu savais que j'ai téléchargé mon live debian avec mon vieux bousin sous Windows (honte suprême ) tu rigolerais moins
Dernière modification par Philou92 (15-06-2015 19:50:17)
Tousse antique Ovide !
Hors ligne
Hors ligne
Debian Stable est ce qui rend la vie plus intéressante que l'informatique ( voir Robert Filliou pour l'origine de cette citation
Debian c'est pas difficile !
https://lescahiersdudebutant.fr/
Pour une aide efficace sur le forum : https://debian-facile.org/viewtopic.php?id=13352
Hors ligne