The instructions for building new kernels and placing them into /boot, building modules and placing them and so forth should match present RedHat distribution naming and build conventions. By this I mean the instructions in the book should acknowledge the fact that the kernel isn't in /boot/vmlinuz (now in a file named for the release, /boot/vmlinuz is an unused link). Building a custom kernel and installing it by the book's instructions can cause problems. I suggest replacing this text with the text of the web page for upgrading kernels, with some modifications so that custom kernels are installed with names like: vmlinuz-2.0.36-custom and modules are placed in /lib/modules/2.0.36-custom and so forth. If the makefiles had installation capabilities which did this, so much the better. It appears this particular text in the printed manual has not changed in many releases, but the software has.
The instructions (installation guide p 197) document how to build a working Linux kernel. The instructions do not document how Red Hat packages kernels. The kernel packaging is designed to permit installation of custom kernels from sources other than Red Hat without interference from the Red Hat kernel package. The makefiles in the kernel are deliberately *not* modified in order to provide a consistent way of building custom kernels. See the kernel spec file if you are interested in how Red Hat packages kernels.
While I don't want to belabor the point, the issue is things like telling you to move the old kernel out of the way, and building new initrd images and such result in the files in the /boot directory somewhat altered in structure from the original. If that's how you prefer it, I'll drop it there. It will potentially result in systems which get mangled worse during a subsequent upgrade to a new version of RHL using the CDROM installer. It seemed to me that updating these instructions some would be a real service to your paying customers. Had I not had a production system mangled last night as a result of the instructions NOT working so well, I would not have bothered opening this bug. I've built lots of kernels in the past, and will continue to do so, but the only thing I use custom kernels for is to rebuild the kernel that matches the stock one for the current release to add a driver or two. Your book seemed to be attempting to describe the process for doing just this, making a slightly custom version of the installed kernel. If the instructions don't match the naming users are going to find, you might as well save a few fractions of a tree and remove those sections of the manual. I've said my piece. You can go close this bug again.