RPM fails to install in Centos 7 / rpm ver. 4.11.1

[alexouzounis]

I have been trying to install the produced RPMs in various systems and it appears that for rpm version <=4.8 all is good but in Centos 7 we have rpm version 4.11.1 which complains as follows:

rpm -ivh test.rpm error: test.rpm: headerRead failed: hdr load: BAD error: test.rpm cannot be installed

rpm --version RPM version 4.11.1

[alexouzounis]

some more information. The hdr load: BAD comes from tag type 1035 which is the file md5s. Interestingly this happens only when the rpm is just a bunch of depends with no files. Add a file in the rpm and the error goes away.

Looking at the code it appears as if rpm 4.11.1 expects always a /0 at the end of a string in a string array. When the rpm has no files the redline lib is not adding such /0 but rpm 4.11.1 is looking for it.

[joker1]

#42 is probably a duplicate of this bug.

@alexouzounis any idea how fix this? I'm not too familiar with the internal structure of rpm package.

[craigwblake]

Thanks for the updated info alexouzounis. We can try adding in the /0 when there are no files and see if it takes care of the issue for you.

[alexouzounis]

Hi!

Thanks for looking into it. I tried playing with it but I did not manage to make it work, rather broke it.

Alex

[devminded]

I investigated a little and compared a meta-rpm built with Redline with another one I found online (that works).

Seems like Redline adds a bunch of empty headers when there are no files and therefore the rpm is viewed as corrupt by rpm >4.8.

Two outputs using the Redline Scanner

Working meta package

rpmversion[tag=1064,type=6,count=1,size=6,offset=793] 4.8.1 payloadformat[tag=1124,type=6,count=1,size=5,offset=6324] cpio payloadcompressor[tag=1125,type=6,count=1,size=3,offset=6329] xz payloadflags[tag=1126,type=6,count=1,size=2,offset=6332] 2

Non-working meta package (Redline)

rpmversion[tag=1064,type=6,count=1,size=6,offset=293] 4.4.2 filesizes[tag=1028,type=4,count=0,size=0,offset=140]

filemodes[tag=1030,type=3,count=0,size=0,offset=140]

filerdevs[tag=1033,type=3,count=0,size=0,offset=140]

filemtimes[tag=1034,type=4,count=0,size=0,offset=140]

filemd5s[tag=1035,type=8,count=0,size=0,offset=140] filelinktos[tag=1036,type=8,count=0,size=0,offset=140] fileflags[tag=1037,type=4,count=0,size=0,offset=140]

fileusername[tag=1039,type=8,count=0,size=0,offset=140] filegroupname[tag=1040,type=8,count=0,size=0,offset=140] fileverifyflags[tag=1045,type=4,count=0,size=0,offset=140]

filedevices[tag=1095,type=4,count=0,size=0,offset=300]

fileinodes[tag=1096,type=4,count=0,size=0,offset=300]

filelangs[tag=1097,type=8,count=0,size=0,offset=300] dirindexes[tag=1116,type=4,count=0,size=0,offset=324]

basenames[tag=1117,type=8,count=0,size=0,offset=324] dirnames[tag=1118,type=8,count=0,size=0,offset=324] filecontexts[tag=1147,type=8,count=0,size=0,offset=356] payloadformat[tag=1124,type=6,count=1,size=5,offset=324] cpio payloadcompressor[tag=1125,type=6,count=1,size=5,offset=329] gzip payloadflags[tag=1126,type=6,count=1,size=2,offset=334] 9

[craigwblake]

Thanks for the new info. The suggested quick fix (null at the end of empty string arrays) did not fix the issue by itself, so it seems we should be suppressing the file headers for a metapackage as well.