Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#26 Le 24/04/2006, à 17:57

YBM

Re : [résolu] : E: Sub-process /usr/bin/dpkg returned an error code (2)

"Dans des conditions normales un sudo mv aurait du fonctionner"

ben vala, on était bien d'accord (dans ce cas pourquoi demander un stat ?) Les droits sur le fichier lui même sont sans pertinence quant au droit d'effacer un fichier (en plus root peut effacer même si en apparence il ne peut écrire dans le répertoire), la situation anormale provenait des structures corrompues du système de fichiers.

dpkg pouvait lire le fichier, l'erreur "Aucun périphérique ou adresse" particulièrement cryptique dans ce contexte provenait du fait qu'il n'y avait aucun pilote d'actif pour gérer un périphique ayant ces numéros majeurs et mineurs (et heureusement ! imagine la marmelade si c'était tombé sur les numéros correspondant à hda1 par exemple)

Hors ligne

#27 Le 24/04/2006, à 18:12

cep_

Re : [résolu] : E: Sub-process /usr/bin/dpkg returned an error code (2)

On va en rester là de ce petit jeu qui ne m'amuse pas du tout.

Je te rappelle que tu conseillais un rm sur ce fichier alors que d'entrée je demandais un e2fsck et éventuellement, si nécessaire, l'utilisation de debugfs. Je pensais aussi qu'il devait y avoir d'autres problèmes sur le périférique. En outre tu me parles de stat alors que je parlais de stat sous debugfs. Je ne pensais pas avoir à remonter le topic ainsi, mais puisque tu m'y pousses, pas de problème.

Donc, après coup tu sors les leçons d'évidence de pilote non actif. Pas très logique avec ton cheminement de début.

Je te laisse continuer tout seul, si cela t'interesses, en ce qui me concerne l'affaire est close.

cep

#28 Le 24/04/2006, à 18:23

YBM

Re : [résolu] : E: Sub-process /usr/bin/dpkg returned an error code (2)

tu t'énerves tout seul ! (et non le coup du pilote non actif ne pouvait vraiment pas se deviner au premier abord, et si dpkg lisait le fichier et recevait bien un message correspondant à un périphérique absent, absolument exotique dans ce contexte : pourquoi dpkg irait accéder directement à quelque périphérique que ce soit ?)

Quand tu as dit "Oui, mais vu les droits sur le fichier et les caractéristiques, il va falloir jongler" en réponse à "on devrait déjà pouvoir enlever ce satané fichier de sur la voie de dpkg". ou "Dans le cas qui nous occupe /var/lib/ appartient à root donc je ne vois pas comment il pourrait renommer ce fichier puisqu'il n'a pas les droits sur le fichier", ça pouvait quand même sérieusement laisser croire que tu entendais que déplacer/renommer/supprimer un fichier était lié aux droits sur le fichier lui-même. C'est d'ailleurs une idée assez naturelle qui se trouve être fausse sous UNIX (sauf cas particulier du sticky bit).

On arrive bien tout deux à la conclusion d'un problème de système de fichiers.

Bref, je suis heureux d'apprendre que tu le savais, même si tu as exprimé le contraire. De toute façons mon explication succinte de la question ne t'étais pas spécialement destinée, mais plutôt à l'initiateur de ce fil, puisqu'apparemment ça te vexe de penser qu'une explication correcte de la sémantique de fichier UNIX t'est destinée...

Hors ligne

#29 Le 24/04/2006, à 18:41

cep_

Re : [résolu] : E: Sub-process /usr/bin/dpkg returned an error code (2)

YBM a écrit :

... ou "Dans le cas qui nous occupe /var/lib/ appartient à root donc je ne vois pas comment il pourrait renommer ce fichier puisqu'il n'a pas les droits sur le fichier", ça pouvait quand même sérieusement laisser croire que tu entendais que déplacer/renommer/supprimer un fichier était lié aux droits sur le fichier lui-même. ...

/var/lib/ appartient à root en effet, donc sudo rm doit pouvoir supprimer le fichier.
Or au poste #9 on lit :

root@totoro:/var/lib/dpkg# rm -f statoverride
rm: ne peut enlever `statoverride': Opération non permise

Donc le problème est autre.
Et moi je poste seulement au #10

Puis tu reparles de renommer ce fichier au poste #14 etje t'invite à relire mon poste #15.

Je ne m'énèrve pas du tout, mais n'éprouve nulle envie, et encore moins besoin, d'épancher quelque "sémantique de fichier UNIX" que ce soit.

À tort peut-être, je me borne simplement à suggérer de manière très succinte (trop peut-être) quelques manipulations pour essayer de résoudre un problème, sans faire ensuite étalage de "science" après coup ou d'anatomie de la pensée.