createrepo falha com a mensagem de falha headerRead

1

eu executo

createrepo -v --update epel-dir/

e no número do pacote 14173, o processo falha com um rastreio de pilha do Python reclamando que:

headerRead failed: Header sanity check: OK

Então, achei ok, baixei um arquivo RPM incorreto:

mv epel/borked-1.2.3.x86_64.rpm Bad

depois de movê-lo para um diretório temporário e executar novamente createrepo :

createrepo -v --update epel-dir

o mesmo erro é exibido no próximo arquivo. E o próximo e o próximo ...

Então, eu pensei que talvez estivesse tendo um problema com muitos arquivos no repositório (aproximadamente 23k - não me parece muito, mas eu nunca construí um repositório local). Eu movi aproximadamente metade dos arquivos para outro diretório:

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

Em seguida, executei createrepo no epel2 e não tive problemas. Então, achei que talvez o cache de repodata seja ruim?

rm -rf epel-dir/repodata epel2/repodata

e o re-ran createrepo em epel-dir e epel2 - sucesso em epel2 com arquivos ~ 10k e falha em torno do arquivo 7745 no diretório epel-dir que tem cerca de 12k arquivos.

Então, desde que eu queria garantir que os arquivos em si não são o problema:

createrepo -v --update Bad/

O que é bem sucedido sem erros na meia dúzia de arquivos. Eu não tenho certeza qual é o problema, nem onde procurar - eu não sei do RHEL / rpm, então qualquer ajuda / sugestão seria ótima.

ATUALIZAÇÃO:

Eu tentei resumir o rastreamento de pilha do Python aqui:

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

  file dumpMetaData.py line 97 in returnHdr
   hdr = hdrFromFdno(fdno)
SystemError: error return without exception set
    
por Daniel 17.03.2015 / 19:09

1 resposta

1

Então, reduzi os arquivos de 22k para um em particular, que despeja pilha.

Eu provavelmente poderia ter encontrado isso mais cedo, exceto que eu não percebi até que eu só tinha um arquivo singleton - createrepo não produzia nenhuma informação de processamento até depois de completar as informações de verificação do cabeçalho. Desde que falhou, o arquivo rpm listado acima o erro não foi o arquivo que falhou, mas o arquivo antes, o nome do arquivo com falha nunca foi saída. Eu só notei isso até que eu tinha (tediosamente) reduzido a um único arquivo, e depois não vi nenhuma saída de informação de arquivo precedendo o rastreamento de pilha. Vou marcar isso como um bug! bem como o tratamento de erros na minha pergunta.

Então, o arquivo com problema acabou sendo o libmicrohttp-doc-0.4.6-1.el5.x86_64.rpm.

Eu não tenho certeza de qual espelho veio - é antigo, alguém estava comprando o repo então; no entanto, a versão que falha em comparação com uma versão baixada do Fedora tem valores MD5 diferentes ... então algo Parece errado com a versão que tenho. Estou marcando o resultado respondido porque sem consertar o Python não há mais nada que eu possa aprender.

Obrigado a @Bratchley (por meu comentário eu tentarei obter o rastreamento da pilha).

    
por 17.03.2015 / 23:20

Tags