Project

General

Profile

Bug #12706

[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 416 Requested Range Not Satisfiable"

Added by Michael Bassler over 6 years ago. Updated almost 4 years ago.

Status:
Rejected
Priority:
Normal
Category:
Repositories
Target version:
Difficulty:
medium
Triaged:
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:
Red Hat JIRA:

Description

I've came across an issue where one of the repositories that I publish in Katello returns this error when trying to install any package from it.

Metadata is fine:
  1. yum list available --disablerepo=* --enablerepo=Katello_RHEL_6_Client
    returns the correct information
  1. curl http://company.net/pulp/repos/ORG/PROD/Content_view/custom/Katello/RHEL_6_Client/
    http shows the correct packages as well.
  1. yum install -y katello-agent
    ...
    Downloading Packages:
    https://company.net/pulp/repos/ORG/PROD/Content_View/custom/Katello/RHEL_6_Client/gofer-2.5.3-1.el6.noarch.rpm: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 416 Requested Range Not Satisfiable"
    Trying other mirror.
    ... same message above repeated 7 times once for each package that is trying to be installed from the repo.

Note: All my other repos off the same Katello server are just fine.

Any ideas on where to look for this, I've not had much look googling the error, I've tried to publish the content again but still with the same result. Please let me know what other information I can provide to assist this this.

History

#1 Updated by Eric Helms over 6 years ago

  • Legacy Backlogs Release (now unused) set to 70
  • Triaged changed from No to Yes

#2 Updated by Justin Sherrill over 6 years ago

Hi Michael,

Are you still seeing this? It would be useful to have your yum repodata (especially the primary.xml file) for this repo.

You might try re-syncing the repo and then republishing the content view to see if that helps at all.

-Justin

#4 Updated by Justin Sherrill over 6 years ago

  • Legacy Backlogs Release (now unused) changed from 70 to 113

#5 Updated by Chris Duryee over 6 years ago

Are you still experiencing this issue?

#6 Updated by Michael Bassler over 6 years ago

Chris Duryee wrote:

Are you still experiencing this issue?

I've worked around this but it is still a reproducible issue.

#7 Updated by Justin Sherrill over 6 years ago

  • Category set to 91
  • Status changed from New to Need more information
  • Assignee set to Justin Sherrill
  • Difficulty set to medium

Looking at this metadata, it looks like the repo may contain duplicates of the rpms. This could be because the RC was synced prior signing, or syncing the packages from some other source. I don't know for sure if this is the cause, but I do know it is a problem. I would try going to:

Content > Product > click the product > click the repo > 'manage packages'

and select all the packages to remove them from the repo. Then try re-syncing the repository (and republishing it in a content view).

Pulp has fixed this issue of duplicate NVREAs in a repo and it should be in the next katello. I'm curious if this does fix it, if not I will continue to investigate.

#8 Updated by Michael Bassler over 6 years ago

Overall success.

After the removal of the packages from the repo a resync was unsuccessful. (returned No new packages)
The repo was initially synced from 2.2 katello-agent. I rebased to 2.3 and ran the sync and published and things are now working. I suspect that removal of packages did not trigger metadata to be regenerated. This resulted in the issue with no new packages because the existing metadata claimed the package was there when it went to sync. That is potentially a bug, if a package is removed manually via manage packages repodata should be regenerated right?

-Michael

#9 Updated by Justin Sherrill over 6 years ago

  • Status changed from Need more information to Rejected
  • Legacy Backlogs Release (now unused) changed from 113 to 150

As far as I can tell we do regenerate metadata when you remove a package from a repo. It gets spawned as a background task and you can track it under Monitor > tasks.

I'll go ahead and close this, as the duplicate NVREA issue is resolved in pulp in 3.0 and as far as I can tell the metadata is regenerated properly. If you are able to see for sure that it is not regenerated, please reopen. Thanks!

Also available in: Atom PDF