CentOS rpmbuild overwrites my modded fault.c
 

Using CentOS 7.0 on x86/64 arch under VMWare vSphere. I have added code to fault.c for a new syscall. (It needs access to data in fault.c, so the function may as well be there). I have added the syscall number to syscall_64.tbl.
I added my buildid to kernel.specs.
I did a "cd" to /rpmbuild/SPECS.
I did rpmbuild -bb kernel-* (with my kernel #s for *).
When it was done, all my mods were gone. Looking in the build-err.log, I see that there are a couple of rm -rf commands, followed by copying the source back over my code.

As an experiment, a friend did this on MY system:
inside SOURCES: mkdir mydir and cd to it
cp linux-3.10.0-514.10.2.el7.tar.xz
tar xvf linux-3.10.0-514.10.2.el7.tar.xz
// make changes to kernel:
// add a file 'kernel/foo.c' which has a dummy syscall'; also add this to 'kernel/Makefile'
// add the syscall in 'arch/x86/syscalls/syscall_64.tbl'

tar cvf cp linux-3.10.0-514.10.2.el7.tar.xz cp linux-3.10.0-514.10.2.el7/
cp linux-3.10.0-514.10.2.el7.tar.xz ..
// I have backed up the original source tree as cp linux-3.10.0-514.10.2.el7.tar.xz.backup
and then run rpmbuild
*** THIS WORKED *** but why?

I can't figure out why my code in rpmbuild/BUILD/kernel-*/Linux-*/x86_64/arch/x86/mm/fault.c is being overwritten before the rpm is built, but not when it is inside a a separate directory inside SOURCES. Any suggestions would be very welcome.

Rpm probably cleans the source tree before it compiles. But if you put your changes outside of the clean routine, and list it in Makefile, the compiler can still find it.

According to all the CentOS documents I have used as references for building a new kernel, unless I am misunderstanding the flow, rpmbuild is supposed to work, without having to update the makefile.
As I understand it, I run rpmbuild -bb for the 1st time to create my base pkg. Then I should make my kernel changes, run rpmbuild -bb (again), then do an rpm -ivh.
Or should I not re-run the rpmbuild after the 1st time (by "1st time", I mean "before I make my changes")?

Reading the rpmbuild manpage would be helpful. Building the binary package ("-bb") always does a complete rebuild from the supplied SOURCES files and the SPEC file.

"-bb Build binary package (after doing the %prep, %build, and %install stages)."

If you want your patch included, you have to create a patch file in the SOURCES directory and adjust the SPEC file to include your patch. It's done that way to ensure that any binary or source package built is consistent with the supplied SOURCES.

Your first step would usually be "rpmbuild -bp ..." to unpack the source tree and apply the existing patches without going through the (perhaps lengthy) %build and %install stages. Of course it doesn't hurt to do the whole "-bb" procedure, but the resulting package will be discarded when you build your patched version.

Thanks for the clarification. So you're basically saying, it's either bad form or not possible to modify the ORIGINAL kernel code, but I have to create a "patch" file for things I want to mod, like fault.c and syscall_64.tbl, if I plan to continue to use rpm's. (FYI: my syscall is INSIDE fault.c because it needs access to data in that file and to run as part of the fault handling mechanism, when fault.c runs .)

And if I understand correctly, to CREATE a patch file, I need to

1. copy the original file (fault.c) to someplace safe,
2. modify the copy
3. create a (patch) file with only the differences using diff, etc.
4. put the resulting file where rpmbuild "knows" where to find it (Sources ?? or a subdirectory ??)

Modify kernel.spec by adding the following line after last SourceN: line
===> PatchN: nameOfPatch (where name would be fault.c.patch)

Then goto the %prep section, add the following line after setup/unpack sources
===> patchN -p1

That should do it. The patches typically go directly in the SOURCES directory, but I suppose they could be put in a subdirectory as long as you referenced them that way in the "PatchN: ..." line in the SPEC file.

If you just want to build a kernel for testing without actually building the new binary RPM, you can do it by manually running "rpmbuild -bc --short-circuit ..." and then "rpmbuild -bi --short-circuit ...". The "--short-circuit" bypasses the earlier build stages. You'll get files including your changes in the BUILD directory that you can copy to /boot and test. But when building the new binary RPM, rpmbuild insists on going through all the steps, thus ensuring that the result agrees with the SOURCES. ("--short-circuit" works only with "-bc" and "-bi".)

And hopefully, 3 more questions before I try it all. To set it all up:
1. as user, create the tree folders (rpmbuild/{RPMS, SPECS, SOURCES, SRPMS, BUILD, BUILDROOT)
2. as root, use yum install for all the pre-req pkgs for build, such as rpm-build, python-devel, etc (I think steps 1 & 2 can be switched)
3. as user, "install" (i.e.; download) the source pkg via "rpm -i http://vault.....")
4. as user, modify SPECS/kernel.spec to add buildid
5. as root, unpack and prepare the source pkg via cd ~/rpmbuild and rpmbuild -bp ... (pointing to eh downloaded rpm

BUT: in step 1, the rpmbuild folder was created in USER's $HOME/ but in step 5, we are running rpmbuild from root. The syntax of the command instep 5 appears as if the rpmbuild folder is in root's home directory. I guess I'm not clear on how root is getting at USER's home directory without something special.

in step 3, how does "rpm -i" know where to put the downloaded rpm? There is nothing in the command to specify the location or even the file name.

And shouldn't my step 4 come AFTER step 5?

You should not work with the source tree as root. Always place it in your home directory. The rpm file specifies where it is to be installed. There are scripts inside of it. Here's a good link: https://fedoraproject.org/wiki/Building_a_custom_kernel

In https://wiki.centos.org/HowTos/Custo...81ad79077ba79b Step 6, it says to install the rpm as root.

I guess that's why I'm confused.

Install, yes. Root privileges are required. Build, no. That's running a lot of scripts and tools for which root privileges are not needed.

They're talking about the rpm after all the changes are made (installing the kernel rpm). The source rpm is just the source code for the kernel. You can install the source code rpm as a regular user.

See: https://wiki.centos.org/HowTos/I_need_the_Kernel_Source

will make the build structure for the installation of the source rpm.

Sorry for all the questions. Hopefully, I have it right now.

So my step 5 above (unpack & prep the rpm) should be done as USER and only step 2 (yum install pre-reqs) is done as root. Then I can do the rpm -ivh as root to "install" {is the term again "install"?} the actual bootable rpm? I guess "install pre-reqs" means download and make them runable, whereas "install source rpm" means "put it in a folder", and "install the kernel rpm" means put the "bootable" code in /boot.

My plan is to:
A. for practice, create a non-modified version of the system as my buildid v0, (rpmbuild -bb followed by rpm -ivh)
B. create my patches with buildid v1 and rpmbuild -bb followed by rpm -ivh for this new version.

Do I have that all correct?

You must configure the kernel before you build it, with at least: make oldconfig. The main reason for building your own kernel is to make your own kernel config.

Since I only plan to add a syscall function to the INSIDE of fault.c (to count page faults), I don't see any reason to reconfigure the kernel. No new modules. No new interfaces. And this version of the system will NOT be used by "general users". (It will be used to demo the differences in how user code can affect system performance.) What am I not seeing?