PYCURL ERROR 22 - “The requested URL returned error: 404 Not Found”
Trying other mirror.
One of the configured repositories failed (CentOS latest - Percona),
and yum doesn’t have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work “fix” this:
Contact the upstream for the repository and get them to fix the problem.
Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
Disable the repository, so yum won’t use it by default. Yum will then
just ignore the repository until you permanently enable it again or use
–enablerepo for temporary usage:
yum-config-manager --disable percona
Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
One of the configured repositories failed (Percona-Release YUM repository - noarch),
and yum doesn’t have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work “fix” this:
Contact the upstream for the repository and get them to fix the problem.
Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
Disable the repository, so yum won’t use it by default. Yum will then
just ignore the repository until you permanently enable it again or use
–enablerepo for temporary usage:
Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
failure: repodata/repomd.xml from percona-release-noarch: [Errno 256] No more mirrors to try.
The only different message is in a case of when I get
Loaded plugins: priorities, update-motd, upgrade-helper
percona-release-0.1-1.noarch.rpm | 6.4 kB 00:00
Examining /var/tmp/yum-root-eLpgFc/percona-release-0.1-1.noarch.rpm: percona-release-0.1-1.noarch
Marking /var/tmp/yum-root-eLpgFc/percona-release-0.1-1.noarch.rpm to be installed
Resolving Dependencies
→ Running transaction check
—> Package percona-release.noarch 0:0.1-1 will be installed
→ Processing Dependency: /usr/bin/gpg for package: percona-release-0.1-1.noarch
→ Processing Dependency: /usr/bin/gpg for package: percona-release-0.1-1.noarch
→ Finished Dependency Resolution
Error: Package: percona-release-0.1-1.noarch (/percona-release-0.1-1.noarch)
Requires: /usr/bin/gpg
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
This is what I think: [LIST=1]
[]The error mesage (the first one) is about being unavailable (non existent) and it is true - when I put the address to a browser I get 404. Why does yum get to this link? Is it in your rpm?
[]Amazon linux instances have some preconfigured repositories including mysql packeges. Doesn’t it somehow conflict with the Percona package? Could be the 1 be a result of the conflict?
[/LIST] It is hard to believe that I am the first / the only one experiencing this.
Could you please have a look at it once more? I would really like to give the Percona server a try because it has a very good reputation but I somehow cannot get to it…
Thank you
Hi I tried to execute the command above but all my repos are now giving errors…I have Percona Server 5.5 on a Amazon Linux AMI, and sudo yum update is failing so I had to disable the repos. Some packages were marked for update in the old Percona repos.
One of the configured repositories failed (Percona-Release YUM repository - noarch),
and yum doesn’t have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work “fix” this:
Contact the upstream for the repository and get them to fix the problem.
Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
Disable the repository, so yum won’t use it by default. Yum will then
just ignore the repository until you permanently enable it again or use
–enablerepo for temporary usage:
Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
ok, I was wrong. just tested the same setup with AMI ami-892fe1fe, and the problem is confirmed.
the root cause is AMI image (and Amazon) itself. it doesn’t use redhat version numbering like 5,6,7. it uses dates for releases like 2014.09. it doesn’t use official Centos and RedHat repositories and uses internal amazon repositories with different structure and logic.
failure from above is caused by “latest” symlink in URL which points to latest Amazon release. we can’t set such symlink pointed exclusively to Percona Centos 6 repository.
I see 2 options there to fix that:
do not allow AMI to define $releasever as “latest” and set it manually in percona-release.repo. you need to replace $releasever with exact Centos version in percona-release.repo. example command to replace on Centos 6 based AMIs: sed -i ‘s/$releasever/6/g’ /etc/yum.repos.d/percona-release.repo.
do not use Amazon AMIs in such case, because they are not exactly the same OS, it’s some kind of OS fork made by Amazon and adjusted exclusively for Amazon services, software and infrastructure. use Centos AMIs.
regarding package exclusions that seems to be just a notification since you’re using yum-plugin-priorities and it means that you have the same package in some other repository which has higher priority so I wouldn’t worry about it.
Jemalloc in our repo is not some special modified version so it should work from other repositories as well.