How to forcefully regenerate metadata of a content view or repository on Red Hat Satellite 6?

Solution Verified - Updated -


  • Red Hat Satellite 6


  • How to recreate metadata of a Content View or Repository?
  • Unable to update package(s) and the below error is faced: [Errno 14] HTTPS Error 404 - Not Found


  • To forcefully regenerate metadata of a Content View or Repository, the below steps need to be followed on the Red Hat Satellite WebUI:

    • For a Content View:

      • Go to Content -> Content Views -> Select the particular Content View -> Click on Publish New Version -> Check mark the box of Force Yum Metadata Regeneration -> Save.
    • For an existing version of Content View:

      • Go to Content -> Content Views -> Select the content view -> Click Versions tab -> Click in Actions column beside Promote drop down arrow -> Regenerate Repository Metadata
    • For a particular repository:

      • Go to Content -> Products -> Select the Product -> Click on the particular repository -> Select Action -> Republish Repository Metadata.
    • Via hammer:

      # hammer content-view version republish-repositories --content-view-id 4  --version 2.0

      Replace 4 and 2.0 according to your environment.

          # hammer content-view list    ==> this gives the content-view-id for the concerned content view
          # hammer content-view info --id=4    ==> this gives the version of that content view. [ replace 4 by the id from previous command ]

For more KB articles/solutions related to Red Hat Satellite 6.x Content View Issues, please refer to the Red Hat Satellite Consolidated Troubleshooting Article for Red Hat Satellite 6.x Content View Issues

Root Cause

  • The repodata of a Content View or Repository is unavailable or corrupted.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.


In case # 02488539, this procedure helped resolve the issue with subsequent versions of a content view showing the same package count for a couple of months.

Is there a permanent fix for metadata corruption issue? We have many capsules and many products. Looking into the metadata corruption issue for all these capsules and products become hectic.

Hello, you suspect many/all repos on Capsule(s) have corrupted metadata? Then I would rather suspect some generic problem that is worth discussing via a support case.

Normally, if this problem is ever hit, it is detected sporadically only and on per repo basis - when it suffices to regenerate metadata for one or very few repos.

This did not resolve an issue I'm having with my Satellite server.

[root@gibba027 ~]# yum clean all; rm -rf /var/cache/yum/*; yum --disablerepo=epel whatprovides /usr/libexec/qemu-kvm
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Cleaning repos: epel rhel-7-server-extras-rpms rhel-7-server-optional-rpms
              : rhel-7-server-rpms rhel-ha-for-rhel-7-server-rpms
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
rhel-7-server-extras-rpms                                        | 2.0 kB  00:00:00     
rhel-7-server-optional-rpms                                      | 2.0 kB  00:00:00     
rhel-7-server-rpms                                               | 2.0 kB  00:00:00     
rhel-ha-for-rhel-7-server-rpms                                   | 2.0 kB  00:00:00     
(1/12): rhel-7-server-extras-rpms/x86_64/group                   |  147 B  00:00:00     
(2/12): rhel-7-server-extras-rpms/x86_64/updateinfo              | 245 kB  00:00:00     
(3/12): rhel-7-server-extras-rpms/x86_64/primary                 | 422 kB  00:00:00     
(4/12): rhel-7-server-optional-rpms/x86_64/updateinfo            | 2.9 MB  00:00:00     
(5/12): rhel-7-server-optional-rpms/x86_64/group                 |  21 kB  00:00:00     
(6/12): rhel-7-server-optional-rpms/x86_64/primary               | 6.5 MB  00:00:00     
(7/12): rhel-7-server-rpms/x86_64/group                          | 639 kB  00:00:00     
(8/12): rhel-7-server-rpms/x86_64/updateinfo                     | 4.0 MB  00:00:00     
(9/12): rhel-7-server-rpms/x86_64/primary                        | 520 kB  00:00:00     
(10/12): rhel-ha-for-rhel-7-server-rpms/x86_64/group             |  16 kB  00:00:00     
(11/12): rhel-ha-for-rhel-7-server-rpms/x86_64/updateinfo        | 137 kB  00:00:00     
(12/12): rhel-ha-for-rhel-7-server-rpms/x86_64/primary           | 229 kB  00:00:00     
rhel-7-server-extras-rpms                                                     1367/1367
rhel-7-server-optional-rpms                                                 22802/22802
rhel-ha-for-rhel-7-server-rpms                                                  829/829
rhel-7-server-extras-rpms/x86_64/filelists                       | 737 kB  00:00:00     
rhel-7-server-optional-rpms/x86_64/filelists                     |  32 MB  00:00:00     
rhel-7-server-rpms/x86_64/filelists                              |  44 MB  00:00:00     

 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=<repoid> ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable <repoid>
            subscription-manager repos --disable=<repoid>

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice

            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

pkgKey 476 doesn't exist in repo rhel-7-server-rpms