Satellite - Package does not match intended download

Latest response

I added an rpm to a custom channel in Satellite for an AvamarClient. When I try to install or update this rpm, I get the following error for the package : "Package does not match intended download". Note that this is a self signed package. The error is below.

Any thoughts on how to get past this error?

Thank you.

[root@iportaldbqa3 ~]# yum update AvamarClient
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package AvamarClient.i586 0:6.1.102-46 will be updated
---> Package AvamarClient.x86_64 0:7.0.101-61 will be an update
--> Finished Dependency Resolution

Dependencies Resolved


Package Arch Version Repository Size

AvamarClient x86_64 7.0.101-61 clone-2-rhel-x86_64-server-6-20140414 37 M

Transaction Summary

Upgrade 1 Package(s)

Total download size: 37 M
Is this ok [y/N]: y
Downloading Packages:
AvamarClient-7.0.101-61.x86_64.rpm | 63 MB 00:02

Error Downloading Packages:
AvamarClient-7.0.101-61.x86_64: failed to retrieve getPackage/AvamarClient-7.0.101-61.x86_64.rpm from clone-2-rhel-x86_64-server-6-20140414
error was [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=clone-2-rhel-x86_64-server-6-20140414 clean metadata


Hi Bruce,
It sounds like your repomd.xml is not up-to-date.
It is simple enough to fire off that job from the Web UI.
Login as the Satellite Adminstrator
Click on the Admin tab, Click on Task Schedules (left-hand), click channel-repodata-bunch (right-hand)
then click Single Run Schedule

I recommend that you login to the Satellite system and get an idea of how busy it is.. then watch the load change and return. I don't know if there is any way to monitor progress of the repodata sync.

These appear to accomplish the same goal (but I have not tested them).

Also - this task happens daily. So, if you wait until tomorrow.. it will probably fix itself ;-)

Formatting tip: to post code output, start the code bit with 3 tilde (without the double-quotes)
code here


I checked my satellite server, the task named: "channel-repodata", under "channel-repodata-bunch" is running every minute on one of my satellite servers (v5.6).

I'm still at 5.5 (upgrade from 5.whoknows ;-) but... mine runs daily at 5am

0 1 5 ? * *     2013-01-02 15:24:45 EST     channel-repodata-bunch

Now - when I go to schedule a Single Run... I do see a bunch of runs that appear to be running (but never are) which I don't quite grasp. I used to recall how I could manually review the progress. Something like watching the files in /var/cache/rhn/repodata with du -sh and ls -lart to see which channels had been modified.

I have a v5.5 server I can check later...
edited, see next comment below...

James, I checked another satellite server I have, v5.5, and that task name "channel-repo" under "Bunch channel-repodata-bunch" runs every minute.

I've never altered these.

my job runs hourly:

channel-repodata-default  0 * * * * ?  2011-05-23 07:33:09 EDT  channel-repodata-bunch  

I ran the single task and then checked the task status and it shows as running (has been for well over an hour:

Last Execution Times 
Channel Repodata:  2014-04-10 05:35:00 EDT  RUNNING 

Will this updated when it completes? Should it take this long?

When I look at the history for this job, it appears to attempt to run every minute, but gets skipped for some reason:

Task Name Start Time End Time Status 
channel-repodata  2014-06-25 11:23:00 EDT  2014-06-25 11:23:00 EDT  SKIPPED  
channel-repodata  2014-06-25 11:22:00 EDT  2014-06-25 11:22:00 EDT  SKIPPED  
channel-repodata  2014-06-25 11:21:00 EDT  2014-06-25 11:21:00 EDT  SKIPPED  
channel-repodata  2014-06-25 11:20:00 EDT  2014-06-25 11:20:00 EDT  SKIPPED  
channel-repodata  2014-06-25 11:19:00 EDT  2014-06-25 11:19:00 EDT  SKIPPED  


3rd Edit (thanks James for the catch),

Bruce, - did you call support?

I found these links...

Lastly... (call support first/prior) perhaps you can reingest your custom channel? **NOTE: the solution ID 41427 is for a RHN-supplied channel, but it does mention (odd) "custom channel" at that page, but at best it is not clear and I'd call support. The link is at this reference, rh solution 41427 (do not execute the solution there, this is reference only).
- It seems a higher issue is causing this and should certainly be sought out... But perhaps create a new test channel with the set of rpms you have and subscribing a few systems as a test to see if it works and take it from there.

If you haven't already, I'd recommend contacting RH Support.

Hope it's working for you by now...

Hey Remmele - Can you validate that 41427 applies to custom channels in addition to RHN channels? It looks like it's RHN only.

I'm looking forward to running that script though ;-)

Very good point James, thanks for that catch (going to edit that post).

It seems that only applies to RHN synced channels.

Bruce, Call Red Hat support.

Bruce, one more possibility, this link with a similar error:
- 'yum install/update or rhn_check fails with "[Errno -1] Package does not match intended download" error'

Thanks to the comments on this discussion and Red Hat support, the problem is fixed based on this solution:

Followed these steps:

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):

# rm -rf /var/cache/rhn/repodata/<channel-label>/*

•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

I can now install or update the custom rpm.

Ahh.. the most obvious step.. restart taskomatic (once the repos are cleared out) ;-)

Thanks for updating the thread, as I believe this is a reasonably frequent enough occurance that someone else will be able to use this data as well.

Glad it worked out Bruce,

Thanks for updating this discussion - I bet James' words will prove true and someone else will need your fix.

Bruce, are you using satellite version 5.5 or 5.6?

Kind Regards,

Just today (for the first time), I noticed this issue on some of my clients for one of my satellite servers.
I am looking at which leads to

I'll post later on this...

We went through the soultion id 19303, and landed upon trying the python script version 3.2.1, but taskomatic would never cleanly generate the repodata when restarted and fell. We're going to examine that further.

We copied the repodata from another like satellite server (with identical channel dumps, rhel5server channel) and it is working for the moment. We have a case in with Red Hat Support as well...