Why there is an Exclamation mark in front of repositories id when running yum on clients registered with Red Hat Satellite 6?

Solution Verified - Updated -


  • Red Hat Satellite 6.X.
  • Yum


  • Why there are Exclamation mark in front of pulp repository names on Client system's registered with Red Hat Satellite 6 ?
# yum repolist
Loaded plugins: product-id, search-disabled-repos, subscription-manager
repo id                                                               repo name                                                                     status
!rhel-7-server-extras-rpms/x86_64                                     Red Hat Enterprise Linux 7 Server - Extras (RPMs)                               188
!rhel-7-server-optional-rpms/7Server/x86_64                           Red Hat Enterprise Linux 7 Server - Optional (RPMs)                            8483
!rhel-7-server-rh-common-rpms/7Server/x86_64                          Red Hat Enterprise Linux 7 Server - RH Common (RPMs)                            183
!rhel-7-server-rpms/7Server/x86_64                                    Red Hat Enterprise Linux 7 Server (RPMs)                                      10643
repolist: 19497


  • As per yum Man page yum repolist output's first column as ! if the repository has expired metadata.
  • This has been purposefully set to be expired, so it re-downloads the repomd.xml file (which is very small) to always keep repositories up to date.

In order to enforce the resync of repomd.xml file you can run the command below:

# yum clean expire-cache

The command above will enforce to remove the file cachecookies located in /var/cache/yum/x86_64/*/*/. After that, on the next yum repolist the file repomd.xml will be downloaded again.

Attention Note: The ! mark is not an issue and it's expected when the Content Host is registered on Satellite/Capsule Server.

Root Cause

  • When Content view's are promoted to a newer version with changes,the clients are not able to see the changes unless a cache on the client is manually cleared or is regenerated by yum after a set interval of time period,so to spare the time required for cache regeneration on client end yum would try to fetch cache on each run.
  • Component
  • yum

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.


But the repos always show expired metadata. Doing a yum clean all, then yum update, yum repolist, still shows all the repos with the exclamation point.

There's nothing in this entry that states how to keep it up to date. On RHN systems you'll get a message stating that the cache is old and suggestions to fix it, (Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast).

Manually delete /var/cache/yum and it'll fix it.

This is because of the metadata_expire value in /etc/yum.repos.d/redhat.repo

The default value when connected to CDN is:

metadata_expire = 86400

When connected to Satellite 6 the client has:

metadata_expire = 1

FYI: metadata_expire Time (in seconds) after which the metadata will expire. So that if the current metadata downloaded is less than this many seconds old then yum will not update the metadata against the repository. If you find that yum is not downloading information on updates as often as you would like lower the value of this option. You can also change from the default of using seconds to using days, hours or minutes by appending a d, h or m respectively. The default is 6 hours, to compliment yum-updatesd running once an hour. It's also possible to use the word "never", meaning that the metadata will never expire. Note that when using a met‐ alink file the metalink must always be newer than the metadata for the repository, due to the validation, so this timeout also applies to the metalink file. Also note that "never" does not override "yum clean expire- cache"

Yes this is an intentional design in Satellite 6.

For Example, consider that you are patching your hosts with an emergency security errata (like shellshock), you use Incremental update feature in Satellite 6 to just push that one errata to your required Convent views - publish/promote and apply immediately to your hosts. If the hosts does not have the 1 sec yum metadata expiry - they may not see the new errata packages immediately and will fail updating packages.

I understand the intent/motive behind setting the metadata_expire value to such a low value. But 1 second seems a bit extreme. This means that every single time a yum update is done, it has to refresh everything, even when package updates don't happen that often, which can take a good while to do at times. The default in Satellite 5 with RHN was 6 hours (same as with the RH CDN), so going from that to the default now in Satellite 6 is a big change. I'd like to make it a value somewhere in between the two defaults.

Is there a way to change this value on the Satellite 6 system side, through some parameter/setting some place (so that it gets applied to all hosts next time they refresh their content)? Or would this have to be changed directly on every content host, either by directly modifying the repo file or using the "subscription-manager repo-override" command? It seems like this should be something that can be changed on the satellite side since the satellite is the one creating this repo file in the first place when the machine is registered.


somewhat informative, but there's NO Resolution. (though deleting the yum cache is a workaround, would be nice to get rid of this...)