I execute

createrepo -v --update epel-dir/

and at package number 14173, the process fails with a Python stack trace complaining that:

headerRead failed: Header sanity check: OK

So, I thought okay, I downloaded a bad RPM file:

mv epel/borked-1.2.3.x86_64.rpm Bad

after moving it to a temp directory and re-runing createrepo:

createrepo -v --update epel-dir

the same error hits on the next file. And the next, and the next ...

So, I thought maybe it's having a problem with too many files in the repository (roughly 23k - it doesn't strike me as a lot, but I've never built a local repo). I moved roughly half the files to another directory:

mkdir epel2
mv epel-dir/[n-z]* epel2

I then ran createrepo on epel2, and had no problems. So, I thought maybe the repodata cache is bad?

rm -rf epel-dir/repodata epel2/repodata

and the re-ran createrepo on epel-dir and epel2 -- success on epel2 with ~10k files and failure at around file 7745 on epel-dir directory which has about 12k files.

Then, since I wanted to ensure the files themselves aren't the problem:

createrepo -v --update Bad/

Which succeeds without any errors on the half dozen or so files. I'm not sure what the problem is, nor where to look -- I don't know from RHEL/rpm, so any help/suggestions would be great.


I've tried to summarize the Python stack trace here:

error: rpmts_HdrFromFdno: headerRead failed: Header sanity check: OK

  file dumpMetaData.py line 97 in returnHdr
   hdr = hdrFromFdno(fdno)
SystemError: error return without exception set
  • Can you post the full python stack trace just in case there's something telling in it?
    – Bratchley
    Mar 17, 2015 at 18:26
  • @Bratchley I summarized the stack trace in the question.
    – Daniel
    Mar 17, 2015 at 20:39
  • Can we get the full thing? I know for me sometimes it's just one or two of the threads out of the whole thing that will make it obvious. If you don't want to type the whole thing and you can't copy-paste it then you might screenshot it and attach it to your post as an image. Either way it sounds like this is a bug with createrepo since exceptions ought to be expected and caught to produce meaningful errors.
    – Bratchley
    Mar 17, 2015 at 21:28
  • I agree - it most likely is a bug with createrepo. I'll try and upload an image screen shot tomorrow or tonight.
    – Daniel
    Mar 17, 2015 at 22:12

1 Answer 1


So, I narrowed down the 22k files to one in particular which stack dumps.

I probably could have found this sooner except I didn't realize until I only had a singleton file -- createrepo doesn't output any processing info until AFTER it completes the header check info. Since that failed, the rpm file listed above the error WAS NOT the file which failed, but the file before, the failed file name was never output. I only noticed it until I had (tediously) narrowed it down to a single file, and then saw no file info output preceding the stack trace. I'll mark this as a bug! as well as the error handling in my question.

So, the problem file turned out to be libmicrohttp-doc-0.4.6-1.el5.x86_64.rpm.

I'm not sure which mirror it came from - it's old, at someone else was pulling repo's then; however the version which fails compared with a version pulled down from Fedora have different MD5 values ... so something seems amiss with the version I have. I'm marking the result answered because without fixing the Python there isn't anything else I can learn.

Thanks to @Bratchley (per my comment I'll try and get the stack trace).

  • Well if you've already resolved your issue in this way then the question is done. Still the stacktrace may be useful if you plan on submitting a bug report about it not gracefully handling the error.
    – Bratchley
    Mar 18, 2015 at 0:12
  • yes. I have an image of a printout of the trace. I'll try and upload it with the bug report. Thanks again for the help.
    – Daniel
    Mar 18, 2015 at 15:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .