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

[Paul Robert Marino]

Thats good I'm glad to hear it. but there are more of these with the same
conflict the method i mentioned of completely clearing then resyncing your
local EPEL channel is the safest way.
On the bright side you only ever have to worry about it when a new minor
version of EL (eg. RHEL, Scientific Linux, CentOS, etc. ) is released.


On Mon, May 13, 2013 at 2:17 PM, Jon Miller <jonebird at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/942f57be/attachment.htm>