Originally Posted by jhyland87
[...] Though I have been using linux for a year, I don't know if I know enough to patcha kernel. I would like to test it on a different server. Because I dont have a RHEL4 server with cPanel laying around, ill buy one from ThePlanet for a month, and test it on that, I dont want to test it on a production server... I want to patch the kernel, 1 reboot, bam.. its done.
Bad things may happen, if you change a running system. Bad things _will_ happen (and you'll have to pay for it), if you can't recover the system on your own (sort of Murphy's law). I'd only test on a system I could switch off and reboot, swap hard disk, boot with live (rescue) OS from CD or DVD. A root server for rent seems not ideally in this respect as long as you don't work or have relatives in the data center of the hosting company.
Originally Posted by jhyland87
Down to the question.... How in the world do I patch a kernel? I am willing to pay someone if they know what they are doing, and feel they can teach me...
Here is exactly what im trying to do: [snip]
You sound like you're expecting to learn magic here. :-)
However patch is a simple tool in the Unix tradition doing only one thing, but doing it well. This one thing is changing (text) files in a well defined way - defined by a patch file.
You may want to see a patch file as a kind of receipt. I tells patch
a) what file to take
b) where to start inside of that file
c) how many rows to delete
d) what to add there in exchange or somewhere else
A patch may hold information for just one little change in one file as well as a series of changes to multiple files across the several directories.
You know diff, yet another little tool? Well that one is able to create such patch files by reporting the differences between two files or directories.
Now, patching the Linux kernel means you're working on the source code (text) files modifying one/some of them before compiling a new kernel. From opening and reading a patch file in the editor of your choice you'll learn what is the base directory (i.e. / or /usr/src/linux-source_xxx/) you'll need to jump to before trying to apply a patch (file).
In general, please read man pages, to get familiar with a tools command line options. For patch I'd recommend to read some patch files and create some on your own with diff before using the patch tool. Always include the '--dry-run' option in patch calls to investigate, what patch is about to do to your systems data. Be suspicious. Try to not use it as root or nothing will save you from modifying important data within a second.
One more word about replacing the systems kernel: It's vital to have a fall-back strategy in case something is going nasty with the new kernel. The boot loader of your choice should be configured to boot the new or the old kernel, ideally at first the new one, in case of failure or simply the next time the old kernel again. I.e. while LILO is quite limited in this respect GRUB does all this and even let you change arguments on the fly in case you have a mistake in the configuration that you don't notice before the reboot. And build a kernel from clean, unpached sources before building from patched ones.