Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-16512

yum repo metadata out of sync between repomd.xml and other XML files


    • Type: Bug
    • Status: Resolved
    • Priority: Normal
    • Resolution: Duplicate
    • Affects Version/s: 5.9.1
    • Fix Version/s: 5.11.0
    • Component/s: YUM
    • Labels:
    • Regression:


      Occasionally when copying/deploying multiple RPMs to a yum repo, it seems as if the repodata files generated by Artifactory get into an out of sync state where the repomd.xml files end up referencing a <chksum>-primary.xml.gz file that doesn't exist. (There are multiple copies of these in the repodata directory, none of which are the ones referenced by repomd.xml)  This results in clients using the repo throwing errors such as:

      failure: repodata/7ac063e0a5b17e46fdfe8ec44ae9cb6ce1408cdd-primary.xml.gz from myafreponame: [Errno 256] No more mirrors to try.

      Running yum clean all on the client seems to have no effect so it appears as if it's a server side problem.

      The only apparent fix is to manually remove the "repodata" directory from Artifactory and force it to recreate the metadata (which is a little more difficult than would be expected since using the calculate yum repository metadata API endpoint generally gives a 409 error "Unable to perform immediate YUM metadata calculation on a repository with auto-async calculation enabled"

      I've seen this issue now happen a couple of times Artifactory Professional 5.9.1 rev 50901900 (but also previously saw it on 5.8.x as well).  Prior to 5.8 I never saw this issue at all.

      Is there some other workaround for this issue to get the repodata in a "sane" state again?  We use some of our yum repos for public software deployment so it is not a good experience for them to get errors while downloading software from our repos.

      This kinda seems like the reverse case of https://www.jfrog.com/jira/browse/RTFACT-7494


          Issue Links



              • Assignee:
                smuskiew Steve Muskiewicz
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: