[Spacewalk-list] How to force a channel repodata rebuild?

[Jon Miller]

On Mon, May 6, 2013 at 5:16 AM, Tomas Lestach <tlestach at redhat.com> wrote:

> > So, enough of my story. How does one go about identifying a 'corrupt'
> > repodata?
>
> Would you sent a package link you have trouble with? I'd try to check it.
>
I would but the same package list now works, so I'm not too focused on the
particular combination of packages.


>
> > Or adequately how do I trigger a complete rebuild without
> > having to remove/add a package? (I tried the
> > channel.software.regenerateNeededCache() API call but didn't seem to
> > do what I was looking for)
>
> Actually you did it right -
> > removing  /var/cache/rhn/repodata/<channel> and triggered a rebuild via
> the
> > channel.software.regenerateYumCache() API call
> is one of good ways how to do it.
> If you do not remove channel repodata manually, you cannot really enforce
> the regeneration.
>
So, about the regeneration of the repodata.... when I manually removed the
data and triggered the rebuild, the datetime modification information on
the files were the same as before I removed the data. It was as if the
regeneration of the data was using cached valued to reproduce the same
data. It was only when we make package changes to the channel that we
actually got a "fresh" repodata.

This morning I took a closer look at the repodata, from a backup I took
prior to deleting it, and could not find any differences except with the
repomd.xml file that had updated timestamp and sha. Could this imply
something "else" was corrupted within Spacewalk? What sort of metadata does
SW store about the RPMs that reside in the channels? Does it include a
header length that the anaconda installer could read? I'm asking that
because Apache was returning a status code of 206 which suggests that
anaconda was providing a length in it's request header and I don't know how
it knows how much data to request.

I think if I run into this problem again, I'll either enable increased
logging in Apache to show me the http headers and/or run a tcpdump capture
to also see the same information.

Thanks,
Jon Miller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130506/4a9b7571/attachment.htm>