yum: package does not match intended download

Latest response

I have installed RedHat Linux Server 7 on a x86_64 machine.
After the installation completed, I tried to install some updates and in particular openssl-libs but I get the following error:

yum upgrade openssl-libs

Loaded plugins: langpacks, product-id, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package openssl-libs.x86_64 1:1.0.1e-34.el7 will be updated
--> Processing Dependency: openssl-libs(x86-64) = 1:1.0.1e-34.el7 for package: 1:openssl-1.0.1e-34.el7.x86_64
---> Package openssl-libs.x86_64 1:1.0.1e-34.el7_0.6 will be an update
--> Running transaction check
---> Package openssl.x86_64 1:1.0.1e-34.el7 will be updated
---> Package openssl.x86_64 1:1.0.1e-34.el7_0.6 will be an update
--> Finished Dependency Resolution

Dependencies Resolved


Package Arch Version Repository Size

openssl-libs x86_64 1:1.0.1e-34.el7_0.6 rhel-7-server-rpms 941 k
Updating for dependencies:
openssl x86_64 1:1.0.1e-34.el7_0.6 rhel-7-server-rpms 706 k

Transaction Summary

Upgrade 1 Package (+1 Dependent package)

Total size: 1.6 M
Total download size: 941 k
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for rhel-7-server-rpms
openssl-libs-1.0.1e-34.el7_0.6 FAILED ] 20 kB/s | 83 kB 00:00:41 ETA
https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os/Packages/openssl-libs-1.0.1e-34.el7_0.6.x86_64.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=rhel-7-server-rpms clean metadata
Trying other mirror.

Error downloading packages:
1:openssl-libs-1.0.1e-34.el7_0.6.x86_64: [Errno 256] No more mirrors to try.

I have tried to run yum --enablerepo=rhel-7-server-rpms clean metadata as suggested but I still get the same error.
I don't use Satellite.


This seems like an issue with repo at the CDN. Which will likely resolve itself (once the repomd is recreated).

I would open a ticket/case to make sure they are aware and can engage the right folks.

I did the following:

# yum clean all

and tried again a little later and now everything works fine.

great - thanks for posting an update!

Posting Tip:
To post output from a command, use 3 x tilde's at the beginning and end of the post
post here

doesnt work

please provide solid engineering response with action steps.

Hi Gokhan,

This is an issue that sometimes occurs ... in addition to yum clean all execute rm -r /var/cache/yum.
In most of the cases this solves the problem ... if not, wait some time and repeat these two commands again. :)



Hi Joseph, the dot (.) ... what do you want to ask or tell me ? :)

Does not help, have completed yum clean all and rm -r /var/cache/yum and waited for hours and retried to the nth degree...

Require action steps with engineering fix.

Please try the solution suggested here (and by Christian above): https://access.redhat.com/solutions/1357043

This solution does not resolve the problem in my case using connected satellite 6.4 and publishing a new CV with metadata recreate forced. I assume it needs to be resolved upstream on CDN before it will resolve on our satellite.

libvirt-libs-4.5.0-10.el7_6.3. FAILED                                                                        ]  0.0 B/s |    0 B  --:--:-- ETA
https://xxxxx.xxxx.xxx/pulp/repos/XXXXXX_ORG/Library/Red_Hat_7Server/content/dist/rhel/server/7/7Server/x86_64/os/Packages/l/libvirt-libs-4.5.0-10.el7_6.3.x86_64.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=rhel-7-server-rpms clean metadata
Trying other mirror.

Somtimes this means your satellite has a bad rpm it downloaded from the CDN.

Run these commands to validate/synchronize the content on satellite:

# Get the repo id
hammer repository list --organization "yourOrgName"
# validate/resync the repo
hammer repository synchronize --validate-contents=true --id=affectedRepoID

This is also my experience. When I go to verify the checksum of the rpm it does not match and I have a bad file. I spent hours and hours googling this and trying to figure it out when in the end a quick dl from RH of the rpm fixed the problem.

Will there be a fix soon available?