0

I have a hardware system that I am running CentOS 7 on. I would like to add some patches to the default CentOS kernel, since I have some custom hardware to support, but I also want to track the upstream kernel releases and apply my patches on top.

I have found the CentOS kernel Git repo, which seems to contain nearly all the files needed to build. These files are the RHEL kernel RPM files (.spec and friends), with the CentOS debranding applied.

My plan is to maintain a parallel branch on a clone of this repository with my hardware-specific patches, which can then be merged with the c7 branch whenever I wish to generate a new kernel RPM. This is essentially what the c7-i686 branch on the CentOS repository does.

However, I have so far been unable to use this Git repo directly to create the kernel RPMs because it appears to be missing some files.

For example, trying to just generate an SRPM gives this error:

$ rpmbuild -bs SPECS/kernel.spec

RPM build errors:                                                                                      
    Bad file: /home/user/rpmbuild/SOURCES/kernel-abi-whitelists-327.tar.bz2: No such file or directory
    Bad file: /home/user/rpmbuild/SOURCES/centos-kpatch.x509: No such file or directory               
    Bad file: /home/user/rpmbuild/SOURCES/centos-ldup.x509: No such file or directory                 
    Bad file: /home/user/rpmbuild/SOURCES/centos.cer: No such file or directory

These files are available in the CentOS distributed SRPM.

These files are listed in the .kernel.metadata file in the Git repo, along with numbers that look like some sort of hash (but I'm not sure if it's a checksum or an identifying hash like a Git commit):

39566b205b3d6870a6224a07b9757807bc2ff407 SOURCES/kernel-abi-whitelists-327.tar.bz2
55fb67d010de128c721b8b4ef224af02e49e7514 SOURCES/linux-3.10.0-327.18.2.el7.tar.xz
95b9b811c7b0a6c98b2eafc4e7d6d24f2cb63289 SOURCES/rheldup3.x509
d90885108d225a234a5a9d054fc80893a5bd54d0 SOURCES/rhelkpatch1.x509
5a7d05a8298cf38d43689470e8e43230d8add0f9 SOURCES/centos-kpatch.x509
c61172887746663d3bdd9acaa263cbfacf99e8b3 SOURCES/centos-ldup.x509
6e9105eb51e55a46761838f289a917611cad8091 SOURCES/centos.cer

However, these are not commits or objects in the CentOS kernel Git repo (and for the tarballs, I wouldn't expect them to be). Searching for these hashes also does not seem to reveal any particularly enlightening results: mostly mailing list posts with the patch that inserted them.

My questions are then:

  • where do these files come from, and how is .kernel.metadata used to find them?
  • at what point in the "normal" CentOS build process are these file injected to create the S/RPMs?
Inductiveload
  • 111
  • 2
  • Going through cloning/branching the CentOS git repo and, at the same time, rebuilding the RPMS from there looks, to me, slightly "overlapping". What about starting from the official SRPM (that, by design, will always contains all needed files) and going through "patching" it, updating the original SPEC file with reference to your own patch-files? With such an approach, you should be safe, always having all you need. Don't you? – Damiano Verzulli May 18 '16 at 16:11
  • Yes, that is certainly a workable way to get it working, but I was hoping to be able to maintain the patches and changes to the spec file alongside the upstream patches, without having to manually insert the patches and re-modify the spec file each time. – Inductiveload May 18 '16 at 16:37

0 Answers0