Hi
We have an “[Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=repo clean metadata” problem with one of our repository. Of course doing an yum --enablerepo=repo clean metadata doesn’t solve the problem.
It is strange because the download start and then fail at some point :
python3-3.6.6-1.rpm FAILED ===================- ] 0.0 B/s | 18 MB --:–:-- ETA
We use Nexus OSS 3.14.0-04, with an hosted yum repository. We have other repositories that works well.
I have no clue of the cause of the problem because there is nothing in the logs, both on the client and server…
This can happen if the size or checksum of the RPM is different to what is listed in primary.xml. I’m not sure how the two would get out of sync. You could try downloading the RPM directly from NXRM as well as the primary.xml.gz file and make a comparison to see if somehow NXRM is out of sync.
It is also possible that you have locally cached metadata that doesn’t match the metadata on the remote so you could start by clearing your local cache
Is this a proxy repository or a hosted repository? If it’s a proxy it could be a problem with the upstream, you could try cutting out NXRM in that case to work out where the problem lies.
I discovered that the problem came from the src package. When i remove SRPMS/python3/3.6.6/python3-3.6.6-1.src.rpm i can download python3-3.6.6-1.x86_64.rpm. But if the src package is present, yum try to download the src instead of binary rpm…
To upload them we use curl : curl -v -k -u $CURLUSER:$CURLPSSWD --upload-file python3-3.6.6-1.x86_64.rpm https://repo/nexus/content/repositories/DEV/x86_64/python3/3.6.6/python3-3.6.6-1.x86_64.rpm curl -v -k -u $CURLUSER:$CURLPSSWD --upload-file python3-3.6.6-1.src.rpm https://repo/nexus/content/repositories/DEV/SRPMS/python3/3.6.6/python3-3.6.6-1.src.rpm
A possible workaround would be to separate the source RPM files from the binary RPM files. If you set your yum hosted repository to a repo depth of 1 and then have two separate folders, one for RPMs and one for the src RPMs you will get two different sets of metadata
It’s not the cause of this problem but it is weird that neither RPM has the source RPM set. According to this post the binary should have SOURCE RPM set: Re: how to differentiate between binary and source rpm. That would possibly prevent us fixing the above bug (NEXUS-17884) in the future
rpm -qip python3-3.6.6-1.x86_64.rpm
Name : python3
Version : 3.6.6
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : Development/Languages
Size : 116488704
License : PSF
Signature : (none)
Source RPM : python3-3.6.6-1.src.rpm
Build Date : Tue 30 Oct 2018 01:06:30 PM CET
Build Host : osboxes
Relocations : (not relocatable)
Summary : Version 3 of the Python programming language aka Python 3000
Description :
Python 3 is a new version of the language that is incompatible with the 2.x
line of releases. The language is mostly the same, but many details, especially
how built-in objects like dictionaries and strings work, have changed
considerably, and a lot of deprecated features have finally been removed.
Result :
python3-3.6.6-1.src.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo= clean metadata
Trying other mirror.
python3-3.6.6-1.x86_64: [Errno 256] No more mirrors to try.
It may be because I redeployed the rpm packages with exactly the same version.
Rebuilding the metadata from the admin panel did not help. (should that be rebuilding the repodata folders?)
I wiped out all repodata folders and “redeployed” the rpm packages and that did not fix it.
I had to remove everything from the repository, old rpm’s and repodata folders, and completely start over. (which is quite annoying because you have to remove each file individually). Only that helped.
@jan Yes running the yum rebuild metadata task does recreate the metadata files that are stored in the repodata folders. Also uploading a new RPM or deleting an RPM will trigger a rebuild of the metadata for the associated repodata folder. Was it a source RPM that caused this for you? If so removing just the source RPM should suffice?
@jan it would be helpful if you could file a ticket at issues.sonatype.com with the exact steps you took to produce the issue and what the symptoms were.