Erreur: le type de données principal demandé n'est pas disponible


8

Par l'erreur, je ne peux installer aucun paquet. Et je ne peux pas non plus mettre à jour vers la dernière version. Je ne sais plus quoi faire maintenant. Toute aide très appréciée.

Erreur: le type de données principal demandé n'est pas disponible

Info OS

  • Système d'exploitation: Fedora 18
  • Architecture: X86_64

Depuis Internet, j'ai essayé les commandes suivantes pour reconstruire le référentiel. Mais je reçois toujours la même erreur.

Exécution des commandes

# yum clean all
# rpm rebuilddb
# yum grouplist or yum list

Plus d'informations

Voici mes fichiers Repo:

adobe-linux-x86_64.repo
epel.repo
fedora.repo
fedora-updates.repo
fedora-updates-testing.repo
livna.repo
mysql-community.repo
mysql-community-source.repo
pgdg-92-fedora.repo
rpmfusion-free-rawhide.repo
rpmfusion-free.repo
rpmfusion-free-updates.repo
rpmfusion-free-updates-testing.repo
rpmfusion-nonfree-rawhide.repo
rpmfusion-nonfree.repo
rpmfusion-nonfree-updates.repo
rpmfusion-nonfree-updates-testing.repo

Réponses:


12

Nettoyer le cache

Pour commencer, je nettoierais ma zone de cache.

$ sudo yum clean all

Test de chaque dépôt

Si cela ne résout pas le problème, j'essaierais de désactiver chaque référentiel 1 à la fois, puis de réexécuter la yum listcommande pour voir si cela résout votre problème.

Vous pouvez le faire via la ligne de commande temporairement, mais vous devez d'abord obtenir les noms réels des référentiels, les noms des fichiers ne sont pas nécessairement la même chose.

Ici, j'utilise Fedora 19, par exemple:

$ yum repolist | expand
Loaded plugins: auto-update-debuginfo, changelog, langpacks, refresh-packagekit
repo id                                       repo name                   status
fedora/19/x86_64                              Fedora 19 - x86_64          36,253
fedora-debuginfo/19/x86_64                    Fedora 19 - x86_64 - Debug   6,635
google-chrome                                 google-chrome                    3
rpm-sphere                                    RPM Sphere                   7,679
rpmfusion-free/19/x86_64                      RPM Fusion for Fedora 19 -     462
rpmfusion-free-debuginfo/19/x86_64            RPM Fusion for Fedora 19 -     157
rpmfusion-free-updates/19/x86_64              RPM Fusion for Fedora 19 -     414
rpmfusion-free-updates-debuginfo/19/x86_64    RPM Fusion for Fedora 19 -     149
rpmfusion-nonfree/19/x86_64                   RPM Fusion for Fedora 19 -     219
rpmfusion-nonfree-debuginfo/19/x86_64         RPM Fusion for Fedora 19 -      62
rpmfusion-nonfree-updates/19/x86_64           RPM Fusion for Fedora 19 -     497
rpmfusion-nonfree-updates-debuginfo/19/x86_64 RPM Fusion for Fedora 19 -     170
*updates/19/x86_64                            Fedora 19 - x86_64 - Update 17,597
*updates-debuginfo/19/x86_64                  Fedora 19 - x86_64 - Update  2,241
virtualbox/19/x86_64                          Fedora 19 - x86_64 - Virtua     10
repolist: 72,548

Activation d'un dépôt à la fois

Je peux donc voir les noms de mes repos dans la toute première colonne. Ensuite, vous voudrez faire la liste `yum où vous désactivez tout, puis activez un seul dépôt, pour confirmer que cela fonctionne bien.

$ yum --disablerepo=* --enablerepo=google-chrome list available
Loaded plugins: auto-update-debuginfo, changelog, langpacks, refresh-packagekit
Available Packages
google-chrome-beta.x86_64                                                                               33.0.1750.91-1            

Lorsque vous arrivez au dépôt qui cause un problème, vous devriez obtenir la même erreur que vous avez mentionnée dans votre message.


Merci pour les conseils de dépannage. J'ai suivi les instructions. Et finissez par suivre des faits intéressants. FAIT 1 --- Je reçois la même erreur avec cette commande yum repolist | expand FACT 2 --- J'ai ensuite vérifié chaque dépôt en l'activant individuellement. epel repo produit l'erreur dont nous parlons. Et un autre facteur intéressant est d'obtenir une autre erreur comme "Erreur lors de l'obtention des données du référentiel pour ------, référentiel introuvable". Ces repo sont fedora-updates, fedora-updates-testing, mysql-community-source, mysql-community, pgdg-92-fedora.
ArunRaj

1
@ user2959196 - Vous pouvez également aller dans les fichiers .repo et changer également enabled = 1 en enabled = 0.
slm

1
Dans mon cas, l'exécution yum --disablerepo=* --enablerepo=repo_name updatede chaque dépôt individuel a résolu le problème de toute façon. J'arrivais Error: requested datatype filelists not availableavant.
Maxim Mazurok

4

Je rencontrais la même erreur: le fichier de type de données demandé n'est pas disponible . J'ai suivi le processus @slm ci-dessus pour préciser quel fichier .repo était à l'origine du problème, mais maintenant quel dépôt individuel?

J'ai mis enable = 1 sur tous les dépôts individuels dans le fichier .repo à 0 , puis j'ai testé la commande list après avoir activé chaque dépôt individuel. Finalement, j'ai trouvé le référentiel individuel à l'origine du problème.

Nous hébergeons le cache de référentiel avec Artifactory ... mais même avec des référentiels hébergés en externe, si vous pouvez parcourir les référentiels (comme http://mirror.centos.org/centos/7.5.1804/os/x86_64/repodata/ ), vous voir filelist.xml.gz, c'est le fichier manquant dont l'erreur parle.

Pour Artifactory, j'ai trouvé: https://www.jfrog.com/confluence/display/RTF/RPM+Repositories

Indexing the File List 
The filelists.xml metadata file of an RPM repository contains a list of all
the files in each package hosted in the repository. When the repository
contains many packages, reindexing this file as a result of interactions
with the YUM client can be resource intensive causing a degradation of
performance. Therefore, from version 5.4, reindexing this file is initially
disabled when an RPM repository is created. To enable indexing
filelists.xml, set the Enable File List Indexing checkbox.

J'ai donc pu accéder à Admin -> local -> "repo" et cocher la case pour créer la liste de fichiers.

Après cela, j'ai nettoyé le cache:

$ yum clean all

$ rm -rf /var/cache/yum

et rediffuser

$ yum list iostat

et cela a résolu mon problème.


0

Dans mon cas, cela soulevait cette erreur lors de l'exécution de "yum update" en raison d'un répertoire local que j'ai ajouté manuellement au /etc/yum.repo.drépertoire.

J'ai créé un fichier myrepo.repo, et dans le "baseurl" j'ai mis deux fois "http: //", je veux dire:

baseurl = http://http://isblcncldrp0001.scisb.isban.corp:8900/cm/5/

Donc, comme vous pouvez le voir, le baseurl est faux. J'ai supprimé le supplément "http: //" et "yum update" exécuté avec succès.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.