Help debugging yum error on nexus 3

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…

How can i debug this ?

Thanks for any help !

Hi Martin,

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

yum clean all

and if that doesn’t help try

rm -r /var/cache/yum

Thanks,

Joe

Thanks for your help.

I’ve cleared local cache and deleted /var/cache/yum but the problem still ocur.

I’ve downloaded the RPM from NXRM and the primary xml file but it seems that they are up to date :

sha256sum python3-3.6.6-1.rpm
8e8ead5da531e37b3ad4c19f7a4728bee91cd45c2734ab72c93d9938dcc96ccc python3-3.6.6-1.rpm

<checksum type="sha256" pkgid="YES">8e8ead5da531e37b3ad4c19f7a4728bee91cd45c2734ab72c93d9938dcc96ccc</checksum>

I don’t understand…

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.

It’s an hosted repository.

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

Thanks

Seems like something might be wrong with the coordinates stored inside the source rpm?

Suggest running "rpm -qip " against both rpm’s to see what it reports back.

rpm -qip python3-3.6.6-1.src.rpm
Name        : python3
Version     : 3.6.6
Release     : 1
Architecture: x86_64
Install Date: (not installed)
Group       : Development/Languages
Size        : 22983406
License     : PSF
Signature   : (none)
Source RPM  : (none)
Build Date  : Tue 30 Oct 2018 01:06:30 PM CET
Build Host  : osboxes
Relocations : (not relocatable)

rpm -qip python3-3.6.6-1.rpm 
Name        : python3
Version     : 3.6.6
Release     : 1
Architecture: x86_64
Install Date: (not installed)
Group       : Development/Languages
Size        : 22983406
License     : PSF
Signature   : (none)
Source RPM  : (none)
Build Date  : Wed 17 Oct 2018 03:15:28 PM CEST
Build Host  : osboxes
Relocations : (not relocatable)

What should i see ?

I wonder if this is another variation of https://issues.sonatype.org/browse/NEXUS-17884

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

Changed RPM binary Source entry but same result :

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.

Changed repo depth of 1 but same result…

Should I delete the first level repodata folder ?

With :

curl -k https://userread:password@repo/nexus/content/repositories/reponame/SRPMS/repodata/b131b0edf188893a3b66e17b30e3e71ca742d6dfa573a51d2d68d96a814b9e8a-primary.xml.gz | gunzip | xmllint --format /dev/fd/0

We have x86_64 instead of src (we are in the SRPMS folder).

I try today with the same rpms in nexus 2, it works.

I have src instead of x86_64 in field arch, in primary.xml file

So it’s a bug in nexus 3, as say before.

I have the same problem. Running latest release.

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.

I suspect this is caused by https://issues.sonatype.org/browse/NEXUS-17884. Please feel free to vote on that ticket.

@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?

Rebuilding metadata did not fix the issue. Only removing every single file

I have repodepth=2 and have separated RPMs and SRPMs.

I had the problem in te ticket you’re referring to, when both RPM and SPRM shared the same repodata, but I then split those up and it worked.

The fault here is triggered by a redeploy with a different rpm (binary wise), but the same package version in the rpm metadata.

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