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
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
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:
and modules are placed in
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
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.