There are four categories of trouble that can occur when building a custom kernel.
They are:
config fails:
If the config(8) command
fails when you give it your kernel description, you have probably made a simple error
somewhere. Fortunately, config(8) will print
the line number that it had trouble with, so that you can quickly locate the line
containing the error. For example, if you see:
config: line 17: syntax error
Make sure the keyword is typed correctly by comparing it to the GENERIC kernel or another reference.
make fails:
If the make command fails, it usually signals an error in
your kernel description which is not severe enough for config(8) to catch.
Again, look over your configuration, and if you still cannot resolve the problem, send
mail to the FreeBSD general questions mailing list with your kernel configuration,
and it should be diagnosed quickly.
The kernel does not boot:
If your new kernel does not boot, or fails to recognize your devices, do not panic!
Fortunately, FreeBSD has an excellent mechanism for recovering from incompatible kernels.
Simply choose the kernel you want to boot from at the FreeBSD boot loader. You can access
this when the system boot menu appears. Select the “Escape to a loader
prompt” option, number six. At the prompt, type unload
kernel and then type boot /boot/kernel.old/kernel, or the filename of any other
kernel that will boot properly. When reconfiguring a kernel, it is always a good idea to
keep a kernel that is known to work on hand.
After booting with a good kernel you can check over your configuration file and try to
build it again. One helpful resource is the /var/log/messages
file which records, among other things, all of the kernel messages from every successful
boot. Also, the dmesg(8) command will
print the kernel messages from the current boot.
Note: If you are having trouble building a kernel, make sure to keep a GENERIC, or some other kernel that is known to work on hand as a
different name that will not get erased on the next build. You cannot rely on kernel.old because when installing a new kernel, kernel.old is overwritten with the last installed kernel which may
be non-functional. Also, as soon as possible, move the working kernel to the proper /boot/kernel location or commands such as ps(1) may not work
properly. To do this, simply rename the directory containing the good kernel:
The kernel works, but ps(1) does not work
any more:
If you have installed a different version of the kernel from the one that the system
utilities have been built with, for example, a -CURRENT kernel on a -RELEASE, many
system-status commands like ps(1) and vmstat(8) will not
work any more. You should recompile and install a world
built with the same version of the source tree as your kernel. This is one reason it is
not normally a good idea to use a different version of the kernel from the rest of the
operating system.