问题
I am beginner in rpm packaging and as I understand rpm-build has issue with file sizes>4GB due to cpio limitations. So I split the large file in my package with gnu split into files of 512MB [which is done as a part of rpmbuild since the large files are generated build time]. I still see the error:
"error: create archive failed on file /io1/dm/build/BUILDROOT/pkg/installdir/lib/clfsplitab: cpio: Bad magic" where clfsplitab is the 512MB split of the large file. Any suggestions on
how to trace the exact issue? Or is there a better way to handle/genrate large payload packages?
Update: As shown the error was on clfsplitab i.e. second file of the split (since gnu split usually splits files with suffix aa, ab, ac and so on. It looks like cpio was unable to recognize the type of file,first file was tar, second and rest were data..gzipped the split parts). It seems to solved only one error to raise same bad magic error, but this time on the last part.
Note: I can control the size of the output of the files that go in the rpm. Ideally the size of the full file dumped is about 4g [which is split in 512mb blocks]. But to test that it is indeed no issue with package size, I steady decreased the size of the object file generated, and if the package goes below 2G it seems to work correcty, and I get a good rpm.
If I recall correctly the size issue was fixed since rpm 4.4.x. Does this still seem like cpio issue, which is used by rpm for archiving?
回答1:
From the old RPM 4.6 documentation:
Large package support
Packages can now theoretically be up to 64bit sizes, and individual files within packages are limited to 4GB each due to cpio format limitation whereas they were previously limited to ~2GB. Large packages (over ~2GB in size) are incompatible and unreadable with previous versions of RPM due to requiring 64bit integer type support in headers, "normal" sized packages are fully compatible with older versions however.
Limitations on accepted header size can cause limit the practical package size when the number of files in a package is extremely high.
So yes this is most likely still a CPIO issue. What version of RPM are you using? I think you should re-evaluate your RPM, 4GB is extremely large for an RPM, even for an internal network we're still talking quite a while to transfer and install this. If this is critical to your systems have you considered rolling this into the kickstart when you build the server initially?
回答2:
While unconventional, I got around the issue by using 'tar' instead of cpio, by specifying 'cpiobin' in rpmrc.
来源：https://stackoverflow.com/questions/14992142/rpm-build-limitaitons