RPM1004: Error retrieving metadata: Not found

Support
1

Hola,

Some mistakes were made yesterday including running a pip update against
some packages that broke pulp amongst other things.

I have managed to fix most of those issues to the point that the various
pulp services now restart successfully.

When I go to run the syncs that didn't happen last night, only some of them
work - about half fail - all with the error RPM1004: Error retrieving
metadata: Not found

There are a number of posts online that don't offer a solution apart from
the one I found that suggested "install the errata" which is hard, because
the katello product in our katello service is one of the non syncing repos.

How do I restore the metadata to a particular repo within a product?

cheers
L

··· ------ The most dangerous phrase in the language is, "We've always done it this way."
  • Grace Hopper
2

I’m still seeing this error occasionally, most recently today. There still seems to be no solution on how to solve?

3

I have found these two Redhat subscriber supposed solutions, but I have no access to them:
https://access.redhat.com/solutions/3124091
https://access.redhat.com/solutions/2838751

so cannot speak to either.

4

I am not sure of why is it failing in your case - I would try to sync again see if it changes anything. In any case, regarding the access.redhat.com, if you get a $0 Developer subscription you can check it out - https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/

1 Like
5

Thanks Daniel, that was helpful - I got access.

One of those links above basically says “yep, there were regressions, the solution is you should update”. The other gives a three step process:

  • mongo pulp_database --eval ‘db.repo_distributors.update({“last_publish”: {$ne: null}}, {$set: {“last_publish”: null}}, {“multi”:true})’
  • foreman-rake console
  • User.current = User.first
  • Katello::Repository.where(“name ilike ‘%fastrack%’”).each { |repo| ForemanTasks.async_task(Actions::Pulp::Repository::DistributorPublish, :pulp_id => repo.pulp_id, :distributor_type_id => Runcible::Models::YumDistributor.type_id) }

This didn’t work.

The issue remains, with no obvious solution.

6

The repo stopped syncing originally because the repo I was pointing to disappeared. I now have

https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64

in the product->repo->url. Is that the problem? Does that metalink stuff the sync up?

7

No. Replacing it with

http://mirror.aarnet.edu.au/pub/epel/7/x86_64/

didn’t make the sync work.

8

Oh! I see now. Despite the link having changed on the product page, /var/log/messages still shows it trying to get the old address

http://fedora.uberglobalmirror.com/pub/epel/7/x86_64/

Gah. How to solve this issue - that the product isn’t updating the underlying URL?

9

Ok. I got a work around that worked for me. Via this answer, I used the command line hammer repository synchronize --id 5 --source-url https://mirror.aarnet.edu.au/pub/epel/7/x86_64.
Initially that threw an error about preferring https instead of http, that looked like this:

Could not synchronize the repository:
Redirection of API call detected.
It seems hammer is configured to use HTTP and the server prefers HTTPS.
Update your server url configuration
you can set ‘follow_redirects’ to one of :default or :always to enable redirects following

so I then made a hand wavy guess and added https:// to the start of the :host: 'myserver' making :host: 'https://myserver' in /root/.hammer/cli.module.d/foreman.yml, then ran the hammer command successfully.

Ah, the life of a sysadmin. Stab in the dark until it works/dies. Thanks.

2 Likes
10

Glad to hear you found a workaround! Sometimes Pulp/Candlepin errors like these are difficult to figure out. I wonder if you think there’s any area of the manual Foreman :: Plugin documentation index where you think your workaround solution would fit? Foreman :: Plugin Manuals perhaps?

Our manual lives in https://github.com/theforeman/theforeman.org/ so if you feel like adding this info, let me know and I’ll merge it - unfortunately I don’t think I have a reproducer for your bug so we ultimately trust your answer :smile:

11

FWIW, while this solution worked on Friday, normal syncing wasn’t resumed over the weekend. Manual synchronization TTW on Monday morning also failed with the same error, despite the new URL. Have tried again via the cli with a new URL (http://fedora.melbourneitmirror.net/epel/7/x86_64/) and it seems to be working. Will check the logs.

Is there any chance that updating the URL on the product page doesn’t actually push the data into the correct field in the db? It remains correct (ie, changed) in the GUI, but it looks like the sync attempt is against the old URL.

OK, I can confirm that when I use the “sync” button or various choices TTW, it keeps using the old and now defunct URL http://fedora.uberglobalmirror.com/pub/epel/7/x86_64/

Why is that? How do I fix that problem?