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

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

BP
Log in to join the conversation

Responses

james.radtke@siriusxm.com's picture Guru 6863 points
24 June 2014 3:46 PM

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).
http://dazdaztech.wordpress.com/2014/02/17/creating-redhat-satellite-server-repodata/

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
"~~~"

R. Hinton's picture Guru 6827 points
24 June 2014 5:57 PM

James,

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

james.radtke@siriusxm.com's picture Guru 6863 points
24 June 2014 6:12 PM

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.

R. Hinton's picture Guru 6827 points
24 June 2014 9:18 PM

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

R. Hinton's picture Guru 6827 points
24 June 2014 11:59 PM

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.

BP Community Member 33 points
25 June 2014 3:25 PM

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
R. Hinton's picture Guru 6827 points
28 June 2014 12:36 AM

Bruce,

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...

james.radtke@siriusxm.com's picture Guru 6863 points
28 June 2014 1:06 AM

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

R. Hinton's picture Guru 6827 points
28 June 2014 1:30 AM

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.

R. Hinton's picture Guru 6827 points
28 June 2014 2:16 AM

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'

BP Community Member 33 points
3 July 2014 2:55 PM

Thanks to the comments on this discussion and Red Hat support, the problem is fixed based on this solution: https://access.redhat.com/solutions/19303

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.

james.radtke@siriusxm.com's picture Guru 6863 points
3 July 2014 3:05 PM

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.

R. Hinton's picture Guru 6827 points
4 July 2014 9:40 PM

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,

R. Hinton's picture Guru 6827 points
9 July 2014 6:14 PM

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 https://access.redhat.com/solutions/37213 which leads to https://access.redhat.com/solutions/19303

I'll post later on this...

R. Hinton's picture Guru 6827 points
9 July 2014 8:04 PM

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...