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

[Paul Robert Marino]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130513/05028899/attachment.htm>