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

Mon May 13 18:17:48 UTC 2013

Thank you very much. I deleted the libart_lgpl packages from my local EPEL
channel and the install is off an happily running.

Thanks again,
Jon Miller

On Mon, May 13, 2013 at 10:22 AM, Paul Robert Marino <prmarino1 at gmail.com>wrote:

> Ive hit this too and there are a few more
>
> Essentially when RHEL 6.4 was released some packages which were previously
> in EPEL became officially part of RHEL then back ported to 6.{1,2,3}. the
> trick to fix this is to delete all the EPEL packages then resync them.
>
>
>
> Note: it doesn't matter if EPEL is in a sub channel or not the error will
> still occur
>
> the trick to prevent this is to delete all the packages in your EPEL
> channel every time a new version of RHEL is released. I know its not pretty
> but until a dedup tool is written by some one we will have to live with it.
> I theoretically know how to write the tool via the APIs I just haven had
> time.
>
>
>
> On Mon, May 13, 2013 at 12:57 PM, Jon Miller <jonebird at gmail.com> wrote:
>
>> My problem with seemingly corrupt RPM header data has returned. This
>> time, however, our workout trick of "deleting the libart_lgpl package &
>> re-syncing the channel" is also not working. I did grab some tcpdump
>> captures this time, but I'm not sure how useful yet they will be. Perhaps I
>> was too focused on the repodata last time, so allow me to rephrase the
>> problem:
>>
>> 1. Client kickstarting a CentOS 6.2 image from our Spacewalk 1.9 server
>> running on RHEL6.
>> 2. During installation prep, complains about the libart_lgpl header data.
>> Excerpt from the anaconda.log:
>>
>> http://crad-spacewalk.example.com/ks/dist/centos-6.2-x86_64-neo/Packages/libart_lgpl-2.3.20-5.1.el6.x86_64.rpmfailed: [Errno -1] Header is not complete.
>> 09:44:15,291 WARNING : Failed to get
>> http://crad-spacewalk.example.com/ks/dist/centos-6.2-x86_64-neo/Packages/libart_lgpl-2.3.20-5.1.el6.x86_64.rpmfrom mirror 1/1, or downloaded file is corrupt
>>
>> I have tried the following two trick unsuccessfully this morning:
>> 1. Delete the RPMs and resync the channel.
>> 2. Delete the local repodata and trigger a fresh rebuild.
>>
>> I'm out of ideas at the moment. I'd appreciate any suggestions.
>>
>> Thanks,
>> Jon Miller
>>
>>
>> On Thu, May 9, 2013 at 4:58 AM, Tomas Lestach <tlestach at redhat.com>wrote:
>>
>>> > When I mentioned the contents of the repodata, after our initial
>>> > removal and triggering Spacewalk to rebuild it, looked identical
>>> > along with modification times, I am referring to the modification
>>> > time as seen on the filesystem via an "ls" command as well as what
>>> > the Channel information showed. Our incident was on May 2nd whereas
>>> > the repodata for our centos6.2-x86-64 channel was showing a modtime
>>> > of April 22nd both before and after the rebuild of the repodata. It
>>> > was only after we removed a package and then re-sync'ed the contents
>>> > of the channel did we see an updated modtime on the repodata and our
>>> > issue disappeared.
>>>
>>> As Michael correctly stated, we set the last modified date of the
>>> repodata
>>> files to the 'channel last modified' right after the files are generated.
>>> (We use the same date for timestamp values in the xml files.)
>>>
>>> If you have removed and pushed the same package back (/re-synced), you
>>> shall
>>> get the same repodata generated as before just with different
>>> modification
>>> dates + different timestamp values (similar to [2]).
>>> If you just remove the repodata files and let them newly regenerate, you
>>> shall get the same content + timestamps as before.
>>>
>>> I hope, that's what you observe.
>>>
>>> --
>>> Tomas Lestach
>>> RHN Satellite Engineering, Red Hat
>>>
>>>
>>> >
>>> >
>>> > Thanks,
>>> > Jon Miller
>>> >
>>> >
>>> > [1]: Commands used to compare old repodata vs. current:
>>> >
>>> > mkdir tmp && cd tmp
>>> > tar -xzvf /tmp/repodata_20130502.tgz
>>> > var/cache/rhn/repodata/centos6.2-x86_64
>>> > mv var/cache/rhn/repodata/centos6.2-x86_64 centos6.2-x86_64.bad
>>> > rm -rf var
>>> > cp -pr /var/cache/rhn/repodata/centos6.2-x86_64 centos6.2-x86_64.good
>>> > gunzip */*gz
>>> > sed -i -e 's/><package/>\n<package/g' -e 's/><file/>\n <file/g'
>>> > */*.xml
>>> > git diff --no-index --color-words *.bad/primary.xml
>>> > *.good/primary.xml
>>> > git diff --no-index --color-words *.bad/other.xml *.good/other.xml
>>> > git diff --no-index --color-words *.bad/filelists.xml
>>> > *.good/filelists.xml
>>> > git diff --no-index --color-words *.bad/repomd.xml *.good/repomd.xml
>>> > # only diff that produced output
>>> >
>>> >
>>> > [2]: Actual diff from the repomd.xml file
>>> >
>>> >
>>> > $ diff -u *.bad/repomd.xml *.good/repomd.xml
>>> > --- centos6.2-x86_64.bad/repomd.xml 2013-05-07 08:07:13.000000000
>>> > -0700
>>> > +++ centos6.2-x86_64.good/repomd.xml 2013-05-07 08:07:16.000000000
>>> > -0700
>>> > @@ -1,2 +1,2 @@
>>> > <?xml version="1.0" encoding="UTF-8"?>
>>> > -<repomd xmlns=" http://linux.duke.edu/metadata/repo "><data
>>> > type="primary"><location href="repodata/primary.xml.gz"/><checksum
>>> >
>>> type="sha">63cc0cb94e9c0fbc958cafd73952ba02e612f239</checksum><open-checksum
>>> >
>>> type="sha">bba7811915fee90f9c6ae257ed10954731d70ac7</open-checksum><timestamp>1366682902</timestamp></data><data
>>> > type="filelists"><location
>>> > href="repodata/filelists.xml.gz"/><checksum
>>> >
>>> type="sha">9fdb004ad90e60e5e34722e553faadac68fa28bd</checksum><open-checksum
>>> >
>>> type="sha">eef5c815e9978738055d25d5cb9bc272e0b3e146</open-checksum><timestamp>1366682902</timestamp></data><data
>>> > type="other"><location href="repodata/other.xml.gz"/><checksum
>>> >
>>> type="sha">6b928d9937c117b8d0d90171cdb7087b0a841556</checksum><open-checksum
>>> >
>>> type="sha">67d55b493f3d89bb62645aff637d98e6df3ac704</open-checksum><timestamp>1366682902</timestamp></data><data
>>> > type="group"><location href="repodata/comps.xml"/><checksum
>>> >
>>> type="sha">01beeafb865b9e6bcefc9b3272ebcb1a93e16da0</checksum><timestamp>1366682902</timestamp></data></repomd>
>>> > \ No newline at end of file
>>> > +<repomd xmlns=" http://linux.duke.edu/metadata/repo "><data
>>> > type="primary"><location href="repodata/primary.xml.gz"/><checksum
>>> >
>>> type="sha">63cc0cb94e9c0fbc958cafd73952ba02e612f239</checksum><open-checksum
>>> >
>>> type="sha">bba7811915fee90f9c6ae257ed10954731d70ac7</open-checksum><timestamp>1367522246</timestamp></data><data
>>> > type="filelists"><location
>>> > href="repodata/filelists.xml.gz"/><checksum
>>> >
>>> type="sha">9fdb004ad90e60e5e34722e553faadac68fa28bd</checksum><open-checksum
>>> >
>>> type="sha">eef5c815e9978738055d25d5cb9bc272e0b3e146</open-checksum><timestamp>1367522246</timestamp></data><data
>>> > type="other"><location href="repodata/other.xml.gz"/><checksum
>>> >
>>> type="sha">6b928d9937c117b8d0d90171cdb7087b0a841556</checksum><open-checksum
>>> >
>>> type="sha">67d55b493f3d89bb62645aff637d98e6df3ac704</open-checksum><timestamp>1367522246</timestamp></data><data
>>> > type="group"><location href="repodata/comps.xml"/><checksum
>>> >
>>> type="sha">01beeafb865b9e6bcefc9b3272ebcb1a93e16da0</checksum><timestamp>1367522246</timestamp></data></repomd>
>>> > \ No newline at end of file
>>> >
>>> >
>>> > _______________________________________________
>>> > Spacewalk-list mailing list
>>> > Spacewalk-list at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>
>>> _______________________________________________
>>> Spacewalk-list mailing list
>>> Spacewalk-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>
>>
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130513/65c9a7c1/attachment.htm>