Yum has issues accessing the metadata of a channel on Red Hat Satellite or cannot find updated packages

Solution Verified - Updated -


  • Red Hat Satellite 5


  • yum cannot retrieve metadata from the satellite:

    # yum check-update 
    Loaded plugins: rhnplugin, security 
    Error: Cannot retrieve repository metadata (repomd.xml) for repository: rhel-i386-server-5.
    Please verify its path and try again 
  • Client system shows 0 packages in base channel:

    # yum repolist
    Loaded plugins: rhnplugin, security
    repo id               repo name                                             status
    rhel-s390x-server-5   Red Hat Enterprise Linux (v. 5 64-bit IBM System z)   enabled:  0
  • yum update on the client fails with Missing Dependency errors for already-installed packages:

    Error: Missing Dependency: libpango-1.0.so.0 is needed by package sound-juicer-2.16.0-3.el5.i386 (installed)
    Error: Missing Dependency: libpango-1.0.so.0 is needed by package vte-0.14.0-2.el5.i386 (installed)
    Error: Missing Dependency: libpangocairo-1.0.so.0 is needed by package gnome-keyring-0.6.0-1.fc6.i386 (installed)
  • client fails to list the latest package available in Satellite


  • Verify that satellite-sync has completed successfully for the channel.
  • Make sure that the Taskomatic service starts successfully on the Satellite server:
# /etc/init.d/taskomatic restart
  • Monitor /var/log/rhn/rhn_taskomatic_daemon.log for any errors during startup.
  • On the client side, check if yum rhnplugin enabled in yum configuration:
# grep plugins /etc/yum.conf 
# grep ^enabled /etc/yum/pluginconf.d/rhnplugin.conf
enabled = 1
  • If the above steps do not resolve the issue, then clean the satellite and client cache files manually:
On the Satellite
  • Clean the channel cache:
    • For Satellite 5.3 and later (the channel label can be found by viewing the channel details page in the Satellite web interface):
Move repodata to a backup location,

# mv /var/cache/rhn/repodata/<channel-label> /some/backup/directory/
  • For Satellite 5.2 and earlier (the channel id can be found by viewing the value of "cid" in the URL when viewing the channel details page in the Satellite web interface):
Move repodata to a backup location,

# mv  /var/cache/rhn/repomd*-<channel-id> /some/backup/directory/
  • Restart taskomatic:
#  /etc/init.d/taskomatic restart
On the client
  • Clean cache on the client:
# yum clean all
  • Force the Satellite to start generating the channel cache files, by running a yum command from the client:
# yum check-update
On the Satellite
  • Check if the previously-deleted files are being created, and be patient: the regeneration process can take upwards of 30 minutes for large base channels.
  • If, once the files have been regenerated, "yum update" on the client still yields "Missing Dependency" errors, and the Satellite server is on version 5.4 or later, then repeat the above steps after first deleting the repodata information stored in the Oracle database:
# service taskomatic stop
# python regen-repodata.py -c <channel-label> --cleandb --force --db --url https://satellite.example.com/rpc/api

# service taskomatic start

The regen-repodata.py script is attached to this kbase and available on github

Information on the usage of regen-repodata are available through the usage of

# python regen-repodata.py -h

Root Cause

  • For system to be able to receive updates from Satellite, yum rhnplugin have to be active.
  • On Red Hat Network Satellite version 5.2 and earlier, the repomd.xml files of a channel will only be generated after a client makes a request for that particular channel, so if a channel is updated and the clients request the data they will keep getting an error until the repomd.xml files are ready.
  • On Red Hat Network Satellite version 5.3 and later, the taskomatic service will automatically regenerate channel cache when a channel has been created or updated, or if a client make a request for a channel that currently has no cache. If a client makes a request for the repomd.xml file while new cache files are still being generated, then the old repomd.xml file (if it exists) will be delivered to the client, and no error will be reported.


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.


Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.