[pacman db] échec de mise à jour de db de dépôt (résolu)

[Ghostofkendo]

Bonjour,

J'ai depuis hier une drôle (et surtout inexplicable) erreur à la mise à jour de les dépôts core et community, jugez plutôt par vous même :

Code : Tout sélectionner

[root@GOK-ARCH ghost]# yaourt -Sy
:: Synchronisation des bases de données de paquets...
 core                      33,1K   68,5K/s 00:00:00 [#############################################] 100%
Erreur: la suppression de l'entrée de base de données coredevice-mapper a échoué
Erreur: la mise à jour de core a échoué (la suppression de l'entrée de base de données a échoué)
 extra est à jour;
 community                363,0K  181,8K/s 00:00:02 [#############################################] 100%
Erreur: la suppression de l'entrée de base de données communitythoggen a échoué
Erreur: la mise à jour de community a échoué (la suppression de l'entrée de base de données a échoué)

Cette erreur me semble donc inexplicable car la dernière chose en date que j'ai fait avec yaourt/pacman (et donc susceptible d'avoir cassé quelque chose), c'est juste mettre à jour firefox et mpg123.

J'ai donc cherché sur les forums et wikis du site officiel et d'archlinux.fr mais je n'ai pas trouvé grand chose qui s'approche de mon cas, si ce n'est ce sujet. Or quand j'essaye de faire la même chose que ce qui a résolu son problème, à savoir supprimer le dossier d'un paquet récalcitrant dans /var/lib/pacman/sync/core/, je n'y parviens pas :

Code : Tout sélectionner

[root@GOK-ARCH ghost]# cd /var/lib/pacman/sync/core/
[root@GOK-ARCH core]# rm -r device-mapper-1.02.31-1/
rm: ne peut détruire le répertoire `device-mapper-1.02.31-1': Le dossier n'est pas vide
[root@GOK-ARCH core]# ls -a device-mapper-1.02.31-1/
./  ../

Voilà, je suis un peu désemparé et sollicite donc vos avis.
Merci d'avance

Tchuss

[mélodie]

rm: ne peut détruire le répertoire `device-mapper-1.02.31-1': Le dossier n'est pas vide
# ls -a device-mapper-1.02.31-1/
./ ../[/code]

Donc toi, tu ne vois rien dans ce dossier, c'est bien ça ? Et le supprimer en le montant depuis un live CD ça ne fonctionne pas ? (Et l'option -f de rm ? -> "rm -Rf device-mapper-1.02.31-1/")

PS: dans le fil vers lequel tu as pointé, la solution a été de changer l'attribut d'un fichier.

When I manually try to remove this file:
Code:

[root@senna gnomebaker-0.6.2-1]# pwd
/var/lib/pacman/sync/community/gnomebaker-0.6.2-1
[root@senna gnomebaker-0.6.2-1]# ls
depends
[root@senna gnomebaker-0.6.2-1]# rm -vRf depends
rm: cannot remove `depends': Operation not permitted

Bref, ce n'est pas ce dont tu parles qu'il veut supprimer, et il a pu supprimer "depends" après avoir changé l'attribut du fichier (lsattr -i, c'est expliqué dans les posts suivants de ce fil).

[Guillawme]

Je n'ai pas d'idée a priori qui puisse t'aider à résoudre ton problème (donc désolé).
Par contre tu essayes de supprimer un répertoire vide avec rm, je pense que rmdir convient déjà mieux à ce cas, non ?

[Ghostofkendo]

De mieux en mieux : ce matin, en faisant un yaourt -Sy pour vérifier que mon problème ne s'était pas résolu par je ne sais quelle magie noire (on peut espérer, vu comment il est apparu), j'ai constaté qu'en plus de core et community, c'est au tour d'extra de me faire le même coup, toujours sans raison apparente

@Guillawme : J'avais essayé avec rmdir aussi mais je n'ai pas eu de résultat plus convaincant.

Code : Tout sélectionner

[root@GOK-ARCH core]# rmdir -v --ignore-fail-on-non-empty device-mapper-1.02.31-1/
rmdir: destruction du répertoire `device-mapper-1.02.31-1/'
[root@GOK-ARCH core]# ls | grep device
device-mapper-1.02.31-1/

@mélodie : Je n'arrive toujours pas à supprimer le dossier en question, que ce soit avec rm -Rf ou depuis un live CD.

PS: dans le fil vers lequel tu as pointé, la solution a été de changer l'attribut d'un fichier. [...] Bref, ce n'est pas ce dont tu parles qu'il veut supprimer, et il a pu supprimer "depends" après avoir changé l'attribut du fichier (lsattr -i, c'est expliqué dans les posts suivants de ce fil).

Oui, je sais, j'avais bien lu le sujet mais ça ne peut pas s'appliquer dans mon cas puisque le fichier depends n'existe pas et les commandes lsattr et chattr ne s'appliquent qu'à des fichiers.

Est-ce qu'une piste pourrait être que ma partition racine (qui contient /var) est en XFS ?

Également, est-ce que changer la variable DBPath dans pacman.conf pour un autre répertoire (disons /var/lib/pacman-alt/) dans lequel on aurait préalablement copié /var/lib/pacman/local/, règlerait mon problème ? C'est peut-être un peu trop bidouillé, il existe peut-être une commande pour re-générer la base de données de pacman ?

Bye

EDIT : J'ai résolu le problème. En fait, mon intuition par rapport à XFS était correcte.
Ce qui m'a mit la puce à l'oreille, c'est qu'en faisant un xfs_repair -n (xfs_repair répare un système de fichiers XFS et l'argument -n précise que la commande n'effectue pas les réparations potentielles, elle ne fait que dire ce qu'elle aurait fait), il y avait mention, dans le rapport des réparations possibles, de fichiers desc ou d'autres portants des noms de paquetages incriminés dans notre affaire. J'ai donc fait un xfs_repair sans l'argument -n sur ma partition racine, depuis un autre OS (j'en ai 4 sur ma machine ) et au reboot, de retour sous Arch, le rafraichissement des dépôts fonctionnais à nouveau !

Merci de votre aide