doc/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml
Glen Barber e05926f374 MF ISBN:
Merged /projects/print2013/en_US.ISO8859-1:r40693-40726
   Merged /projects/ISBN_1-57176-407-0/en_US.ISO8859-1:r40727-41455,
	41457-41469,41472-41477,41479-41513,41515-41521,41523-41577,
	41579-41581,41583-42013

Notes:  This merge entirely excludes the en_US/books/handbook/ppp-and-slip/
changes.  They will need to be looked at a bit more closely.

Note to translators:  I am very, very sorry.  There was no *clean* way
to merge this as separate commits.  Trust me, I tried.
The revision logs for the ISBN branch should provide some insight to what
content has changed.  I am more than happy to help out here.  Sorry :(

Approved by:	doceng (implicit)
2013-06-23 22:37:08 +00:00

1476 lines
61 KiB
XML

<?xml version="1.0" encoding="iso-8859-1"?>
<!--
The FreeBSD Documentation Project
$FreeBSD$
-->
<chapter id="kernelconfig">
<chapterinfo>
<authorgroup>
<author>
<firstname>Jim</firstname>
<surname>Mock</surname>
<contrib>Updated and restructured by </contrib>
<!-- Mar 2000 -->
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Jake</firstname>
<surname>Hamby</surname>
<contrib>Originally contributed by </contrib>
<!-- 6 Oct 1995 -->
</author>
</authorgroup>
</chapterinfo>
<title>Configuring the FreeBSD Kernel</title>
<sect1 id="kernelconfig-synopsis">
<title>Synopsis</title>
<indexterm>
<primary>kernel</primary>
<secondary>building a custom kernel</secondary>
</indexterm>
<para>The kernel is the core of the &os; operating system. It
is responsible for managing memory, enforcing security controls,
networking, disk access, and much more. While much of &os; is
dynamically configurable, it is still occasionally necessary to
configure and compile a custom kernel.</para>
<para>After reading this chapter, you will know:</para>
<itemizedlist>
<listitem>
<para>When to build a custom kernel.</para>
</listitem>
<listitem>
<para>How to customize a kernel configuration file.</para>
</listitem>
<listitem>
<para>How to use the kernel configuration file to create and
build a new kernel.</para>
</listitem>
<listitem>
<para>How to install the new kernel.</para>
</listitem>
<listitem>
<para>How to troubleshoot if things go wrong.</para>
</listitem>
</itemizedlist>
<para>All of the commands listed in the examples in this chapter
should be executed as <username>root</username>.</para>
</sect1>
<sect1 id="kernelconfig-custom-kernel">
<title>Why Build a Custom Kernel?</title>
<para>Traditionally, &os; used a <quote>monolithic</quote> kernel.
The kernel was one large program, supported a fixed list of
devices, and in order to change the kernel's behavior, one had
to compile a new kernel, and then reboot into the new
kernel.</para>
<para>Today, most of the functionality in the &os; kernel is
contained in modules which can be dynamically loaded and
unloaded from the kernel as necessary. This allows the
running kernel to adapt immediately to new hardware or for new
functionality to be brought into the kernel. This is known as
a modular kernel.</para>
<para>Occasionally, it is still necessary to perform static kernel
configuration. This may be because the functionality is so tied
to the kernel that it can not be made dynamically loadable.
Some security environments prevent the loading and unloading of
kernel modules, and require that only needed functionality is
statically compiled into the kernel.</para>
<para>Building a custom kernel is often a rite of passage for
advanced BSD users. This process, while time consuming, can
provide benefits to the &os; system. Unlike the
<filename>GENERIC</filename> kernel, which must support a wide
range of hardware, a custom kernel can be stripped down to only
provide support for that computer's hardware. This has a number
of benefits, such as:</para>
<itemizedlist>
<listitem>
<para>Faster boot time. Since the kernel will only probe the
hardware on the system, the time it takes the system to boot
can decrease.</para>
</listitem>
<listitem>
<para>Lower memory usage. A custom kernel often uses less
memory than the <filename>GENERIC</filename> kernel by
omitting unused features and device drivers. This is
important because the kernel code remains resident in
physical memory at all times, preventing that memory from
being used by applications. For this reason, a custom
kernel is useful on a system with a small amount of
RAM.</para>
</listitem>
<listitem>
<para>Additional hardware support. A custom kernel can add in
support for devices which are not present in the
<filename>GENERIC</filename> kernel.</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="kernelconfig-devices">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Written by </contrib>
</author>
</authorgroup>
</sect1info>
<title>Finding the System Hardware</title>
<para>Before venturing into kernel configuration, it would be
wise to get an inventory of the machine's hardware. In cases
where &os; is not the primary operating system, the inventory
list can be created by viewing the current operating system
configuration. For example, &microsoft;'s
<application>Device Manager</application> contains information
about installed devices.</para>
<note>
<para>Some versions of &microsoft.windows; have a
<application>System</application> icon which will display a
screen where <application>Device Manager</application> may
be accessed.</para>
</note>
<para>If another operating system does not exist on the machine,
the administrator must find this information out manually. One
method is using &man.dmesg.8; and &man.man.1;. Most device
drivers on &os; have a manual page, listing supported hardware.
During the boot probe, found hardware will be listed. For
example, the following lines indicate that the &man.psm.4;
driver found a mouse:</para>
<programlisting>psm0: &lt;PS/2 Mouse&gt; irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0</programlisting>
<para>This driver will need to be included in the custom kernel
configuration file or loaded using &man.loader.conf.5;.</para>
<para>On occasion, the data from <command>dmesg</command> will
only show system messages instead of the boot probe output. In
these situations, the output may be obtained by reading
<filename>/var/run/dmesg.boot</filename>.</para>
<para>Another method for finding hardware is to use
&man.pciconf.8; which provides more verbose output. For
example:</para>
<programlisting>ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR5212 Atheros AR5212 802.11abg wireless'
class = network
subclass = ethernet</programlisting>
<para>This output, obtained by using
<command>pciconf <option>-lv</option></command>, shows that the
<devicename>ath</devicename> driver located a wireless Ethernet
device. Type <command>man
<replaceable>ath</replaceable></command> to read
&man.ath.4;.</para>
<para>The <option>-k</option> flag, when passed to &man.man.1;
can be used to provide useful information. For example, to
display a list of manual pages which contain the specified
word:</para>
<screen>&prompt.root; man -k <replaceable>Atheros</replaceable></screen>
<programlisting>ath(4) - Atheros IEEE 802.11 wireless network driver
ath_hal(4) - Atheros Hardware Access Layer (HAL)</programlisting>
<para>Armed with a hardware inventory list, the process of
building a custom kernel should appear less daunting.</para>
</sect1>
<sect1 id="kernelconfig-modules">
<title>Kernel Drivers, Subsystems, and Modules</title>
<indexterm>
<primary>kernel</primary>
<secondary>drivers / modules / subsystems</secondary>
</indexterm>
<para>Before building a custom kernel, consider the reason for
doing so. If there is a need for specific hardware support,
it may already exist as a module.</para>
<para>Kernel modules exist in <filename
class="directory">/boot/kernel</filename> and may be
dynamically loaded into the running kernel using
&man.kldload.8;. Most, if not all kernel drivers have a
loadable module and manual page. For example, the &man.ath.4;
wireless Ethernet driver has the following information in its
manual page:</para>
<programlisting>Alternatively, to load the driver as a module at boot time, place the
following line in &man.loader.conf.5;:
if_ath_load="YES"</programlisting>
<para>Adding <literal>if_ath_load="YES"</literal> to
<filename>/boot/loader.conf</filename> will enable loading this
module dynamically at boot time.</para>
<para>In some cases, there is no associated module. This is
mostly true for certain subsystems. One way to tell if a driver
is available is to check for the module itself.</para>
<warning>
<para>It is easy to remove support for a device or option and
end up with a broken kernel. For example, if the &man.ata.4;
driver is removed from the kernel configuration file, a system
using <acronym>ATA</acronym> disk drivers may not boot. When
in doubt, just leave support in the kernel.</para>
</warning>
</sect1>
<sect1 id="kernelconfig-building">
<title>Building and Installing a Custom Kernel</title>
<indexterm>
<primary>kernel</primary>
<secondary>building / installing</secondary>
</indexterm>
<note>
<para>It is required to have the full &os; source tree installed
to build the kernel.</para>
</note>
<para>The kernel build is located at <filename
class="directory">/usr/src/sys</filename>. It contains a
number of subdirectories representing different parts of the
kernel. These include <filename
class="directory"><replaceable>arch</replaceable>/conf</filename>,
which contains the kernel configuration file, and
<filename class="directory">compile</filename>, which is the
staging area where the kernel will be built.
<replaceable>arch</replaceable> contains subdirectories for each
supported architecture: <filename
class="directory">i386</filename>, <filename
class="directory">amd64</filename>, <filename
class="directory">ia64</filename>, <filename
class="directory">powerpc</filename>, <filename
class="directory">sparc64</filename>, and <filename
class="directory">pc98</filename>. Everything inside a
particular architecture's directory deals with that architecture
only and the rest of the code is machine independent code common
to all platforms. Notice the logical organization of the
directory structure, with each supported device, file system,
and option in its own subdirectory.</para>
<para>The examples in this chapter assume the i386 architecture.
If the system has a different architecture, change the path
names accordingly.</para>
<note>
<para>If <filename class="directory">/usr/src/</filename> does
not exist or it is empty, source has not been installed. The
easiest way to install source is to use
<application>svn</application> as described in <xref
linkend="svn"/>. One should also create a symlink to
<filename class="directory">/usr/src/sys/</filename>:</para>
<screen>&prompt.root; <userinput>ln -s /usr/src/sys /sys</userinput></screen>
</note>
<para>Next, <application>cd</application> to <filename
class="directory"><replaceable>arch</replaceable>/conf</filename>
and copy the <filename>GENERIC</filename> configuration file to
the name of the custom kernel. For example:</para>
<screen>&prompt.root; <userinput>cd /usr/src/sys/<replaceable>i386</replaceable>/conf</userinput>
&prompt.root; <userinput>cp GENERIC <replaceable>MYKERNEL</replaceable></userinput></screen>
<para>Traditionally, this name is in all capital letters. When
maintaining multiple &os; machines with different hardware, it
is a good idea to name it after the machine's hostname. This
example uses
<filename><replaceable>MYKERNEL</replaceable></filename>.</para>
<tip>
<para>When finished customizing the kernel configuration file,
save a backup copy to a location outside of <filename
class="directory">/usr/src</filename>. Do not edit
<filename>GENERIC</filename> directly.</para>
<para>Alternately, keep the kernel configuration file elsewhere
and create a symbolic link to the file in <filename
class="directory"><replaceable>i386</replaceable></filename>.</para>
<para>For example:</para>
<screen>&prompt.root; <userinput>cd /usr/src/sys/<replaceable>i386</replaceable>/conf</userinput>
&prompt.root; <userinput>mkdir /root/kernels</userinput>
&prompt.root; <userinput>cp GENERIC /root/kernels/<replaceable>MYKERNEL</replaceable></userinput>
&prompt.root; <userinput>ln -s /root/kernels/<replaceable>MYKERNEL</replaceable></userinput></screen>
</tip>
<para>Edit
<filename><replaceable>MYKERNEL</replaceable></filename>
with a text editor. The default editor is
<application>vi</application>, whose usage is covered well in
many books in the <link
linkend="bibliography">bibliography</link>. An easier editor
for beginners, called <application>ee</application>, is also
available. Feel free to change the comment lines at the top to
reflect the configuration or the changes made to differentiate
it from <filename>GENERIC</filename>.</para>
<para>If the <filename>GENERIC</filename> configuration file seems
overwhelming, follow the descriptions in the <link
linkend="kernelconfig-config">Configuration File</link>
section slowly and carefully.</para>
<note>
<para>After <link linkend="svn">syncing the source tree</link>
with the latest sources, <emphasis>always</emphasis> read
<filename class="directory">/usr/src/UPDATING</filename>
before performing any update steps. This file describes any
important issues or areas requiring special attention within
the updated source code.
<filename>/usr/src/UPDATING</filename> always matches
the version of the &os; source and contains more up-to-date
information than this Handbook.</para>
</note>
<para>After saving the edits, compile the source code for the
kernel.</para>
<procedure>
<title>Building a Kernel</title>
<note>
<para>It is required to have the full &os; source tree
installed to build the kernel.</para>
</note>
<step>
<para><command>cd</command> to <filename
class="directory">/usr/src</filename>:</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput></screen>
</step>
<step>
<para>Compile the new kernel by specifying the name of the
custom kernel configuration file:</para>
<screen>&prompt.root; <userinput>make buildkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput></screen>
</step>
<step>
<para>Install the new kernel:</para>
<screen>&prompt.root; <userinput>make installkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput></screen>
</step>
</procedure>
<tip>
<para>By default, when a custom kernel is compiled,
<emphasis>all</emphasis> kernel modules are rebuilt as well.
To update a kernel faster or to build only custom modules,
edit <filename>/etc/make.conf</filename> before starting to
build the kernel:</para>
<programlisting>MODULES_OVERRIDE = linux acpi sound/sound sound/driver/ds1 ntfs</programlisting>
<para>This variable specifies the list of modules to build
instead the default of building of all of them.</para>
<programlisting>WITHOUT_MODULES = linux acpi sound ntfs</programlisting>
<para>This variable sets up a list of top level modules to
exclude from the build process. For other available
variables, refer to &man.make.conf.5;.</para>
</tip>
<indexterm>
<primary><filename
class="directory">/boot/kernel.old</filename></primary>
</indexterm>
<para>The new kernel will be copied to <filename
class="directory">/boot/kernel</filename> as
<filename>/boot/kernel/kernel</filename> and the old kernel
will be moved to <filename>/boot/kernel.old/kernel</filename>.
Now, shutdown the system and reboot into the new kernel.
If something goes wrong, refer to the <link
linkend="kernelconfig-trouble">troubleshooting</link>
instructions and the section which explains how to
recover when the new kernel <link
linkend="kernelconfig-noboot">does not boot</link>.</para>
<note>
<para>Other files relating to the boot process, such as the boot
&man.loader.8; and configuration, are stored in <filename
class="directory">/boot</filename>. Third party or
custom modules can be placed in <filename
class="directory">/boot/kernel</filename>, although users
should be aware that keeping modules in sync with the compiled
kernel is very important. Modules not intended to run with
the compiled kernel may result in instability.</para>
</note>
</sect1>
<sect1 id="kernelconfig-config">
<sect1info>
<authorgroup>
<author>
<firstname>Joel</firstname>
<surname>Dahl</surname>
<contrib>Updated by </contrib>
</author>
</authorgroup>
</sect1info>
<title>The Configuration File</title>
<indexterm>
<primary>kernel</primary>
<secondary>NOTES</secondary>
</indexterm>
<indexterm><primary>NOTES</primary></indexterm>
<indexterm>
<primary>kernel</primary>
<secondary>configuration file</secondary>
</indexterm>
<para>The general format of a configuration file is quite simple.
Each line contains a keyword and one or more arguments. For
simplicity, most lines only contain one argument. Anything
following a <literal>#</literal> is considered a comment and
ignored. The following sections describe each keyword, in
the order they are listed in <filename>GENERIC</filename>.
For an exhaustive list of architecture dependent options and
devices, refer to <filename>NOTES</filename> in the same
directory as <filename>GENERIC</filename> for that architecture.
For architecture independent options, refer to
<filename>/usr/src/sys/conf/NOTES</filename>.</para>
<para>An <literal>include</literal> directive is available for use
in configuration files. This allows another configuration file
to be included in the current one, making it easy to maintain
small changes relative to an existing file. For example, if
only a small number of additional options or drivers are
required, this allows a delta to be maintained with respect
to GENERIC:</para>
<programlisting>include GENERIC
ident MYKERNEL
options IPFIREWALL
options DUMMYNET
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT</programlisting>
<para>Using this method, the local configuration file expresses
local differences from a <filename>GENERIC</filename>
kernel. As upgrades are performed, new features added to
<filename>GENERIC</filename> will be also be added to the local
kernel unless they are specifically prevented using
<literal>nooptions</literal> or <literal>nodevice</literal>.
A comprehensive list of configuration directives and their
descriptions may be found in &man.config.5;.</para>
<para>The remainder of this chapter addresses the contents of a
typical configuration file and the role various options and
devices play.</para>
<note>
<para>To build a file which contains all available options,
run the following command as <username>root</username>:</para>
<screen>&prompt.root; <userinput>cd /usr/src/sys/<replaceable>i386</replaceable>/conf &amp;&amp; make LINT</userinput></screen>
</note>
<indexterm>
<primary>kernel</primary>
<secondary>configuration file</secondary>
</indexterm>
<para>The following is an example of the
<filename>GENERIC</filename> kernel configuration file with
various additional comments where needed for clarity. This
example should match the copy in
<filename>/usr/src/sys/<replaceable>i386</replaceable>/conf/GENERIC</filename>
fairly closely.</para>
<indexterm>
<primary>kernel options</primary>
<secondary>machine</secondary>
</indexterm>
<programlisting>machine i386</programlisting>
<para>This is the machine architecture. It must be either
<literal>amd64</literal>, <literal>i386</literal>,
<literal>ia64</literal>, <literal>pc98</literal>,
<literal>powerpc</literal>, or
<literal>sparc64</literal>.</para>
<indexterm>
<primary>kernel options</primary>
<secondary>cpu</secondary>
</indexterm>
<programlisting>cpu I486_CPU
cpu I586_CPU
cpu I686_CPU</programlisting>
<para>This option specifies the type of CPU. It is fine to have
multiple instances of the CPU entries, but for a custom kernel
it is best to specify the CPU. To determine the CPU type,
review the boot messages in
<filename>/var/run/dmesg.boot</filename>.</para>
<indexterm>
<primary>kernel options</primary>
<secondary>ident</secondary>
</indexterm>
<programlisting>ident GENERIC</programlisting>
<para>This is the identification of the kernel. Change
this to the new kernel name, such as
<literal><replaceable>MYKERNEL</replaceable></literal>.
The value in the <literal>ident</literal> string will
print when the kernel boots.</para>
<programlisting>#To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" # Default places to look for devices.</programlisting>
<para>&man.device.hints.5; is used to configure options for device
drivers. The default location is
<filename>/boot/device.hints</filename>. The
<literal>hints</literal> option compiles these hints statically
into the kernel so that there is no need to create
<filename>/boot/device.hints</filename>.</para>
<!-- XXX: Add a comment here that explains when compiling hints into
the kernel is a good idea and why. -->
<programlisting>makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols</programlisting>
<para>This option enables debugging information when passed to
&man.gcc.1;.</para>
<programlisting>options SCHED_ULE # ULE scheduler</programlisting>
<para>The default system scheduler for &os;. Keep this.</para>
<programlisting>options PREEMPTION # Enable kernel thread preemption</programlisting>
<para>Allows kernel threads to be preempted by higher priority
threads. This helps with interactivity and allows interrupt
threads to run sooner rather than waiting.</para>
<programlisting>options INET # InterNETworking</programlisting>
<para>Networking support. This is mandatory as most programs
require at least loopback networking.</para>
<programlisting>options INET6 # IPv6 communications protocols</programlisting>
<para>This enables the IPv6 communication protocols.</para>
<programlisting>options FFS # Berkeley Fast Filesystem</programlisting>
<para>This is the basic hard drive file system. Leave it in if
the system boots from the hard disk.</para>
<programlisting>options SOFTUPDATES # Enable FFS Soft Updates support</programlisting>
<para>This option enables Soft Updates in the kernel which helps
to speed up write access on the disks. Even when this
functionality is provided by the kernel, it must be turned on
for specific disks. Review the output of &man.mount.8; to
determine if Soft Updates is enabled. If the
<literal>soft-updates</literal> option is not in the output, it
can be activated using &man.tunefs.8; for existing file systems
or &man.newfs.8; for new file systems.</para>
<programlisting>options UFS_ACL # Support for access control lists</programlisting>
<para>This option enables kernel support for access control lists
(<acronym>ACL</acronym>s). This relies on the use of extended
attributes and <acronym>UFS2</acronym>, and the feature is
described in detail in <xref linkend="fs-acl"/>.
<acronym>ACL</acronym>s are enabled by default and should not be
disabled in the kernel if they have been used previously on a
file system, as this will remove the ACLs, changing the way
files are protected in unpredictable ways.</para>
<programlisting>options UFS_DIRHASH # Improve performance on big directories</programlisting>
<para>This option includes functionality to speed up disk
operations on large directories, at the expense of using
additional memory. Keep this for a large server or interactive
workstation, and remove it from smaller systems where memory is
at a premium and disk access speed is less important, such as a
firewall.</para>
<programlisting>options MD_ROOT # MD is a potential root device</programlisting>
<para>This option enables support for a memory backed virtual disk
used as a root device.</para>
<indexterm>
<primary>kernel options</primary>
<secondary>NFS</secondary>
</indexterm>
<indexterm>
<primary>kernel options</primary>
<secondary>NFS_ROOT</secondary>
</indexterm>
<programlisting>options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options NFS_ROOT # NFS usable as /, requires NFSCLIENT</programlisting>
<para>The network file system (<acronym>NFS</acronym>). These
lines can be commented unless the system needs to mount
partitions from a <acronym>NFS</acronym> file server over
TCP/IP.</para>
<indexterm>
<primary>kernel options</primary>
<secondary>MSDOSFS</secondary>
</indexterm>
<programlisting>options MSDOSFS # MSDOS Filesystem</programlisting>
<para>The &ms-dos; file system. Unless the system needs to mount
a DOS formatted hard drive partition at boot time, comment this
out. It will be automatically loaded the first time a DOS
partition is mounted. The <filename
role="package">emulators/mtools</filename> package allows
access to DOS floppies without having to mount and unmount
them and does not require <literal>MSDOSFS</literal>.</para>
<programlisting>options CD9660 # ISO 9660 Filesystem</programlisting>
<para>The ISO 9660 file system for CDROMs. Comment it out if the
system does not have a CDROM drive or only mounts data CDs
occasionally since it will be dynamically loaded the first
time a data CD is mounted. Audio CDs do not need this file
system.</para>
<programlisting>options PROCFS # Process filesystem (requires PSEUDOFS)</programlisting>
<para>The process file system. This is a <quote>pretend</quote>
file system mounted on <filename
class="directory">/proc</filename> which allows some programs
to provide more information on what processes are running. Use
of <literal>PROCFS</literal> is not required under most
circumstances, as most debugging and monitoring tools have been
adapted to run without <literal>PROCFS</literal>. The default
installation will not mount this file system by default.</para>
<programlisting>options PSEUDOFS # Pseudo-filesystem framework</programlisting>
<para>Kernels making use of <literal>PROCFS</literal> must
also include support for <literal>PSEUDOFS</literal>.</para>
<programlisting>options GEOM_PART_GPT # GUID Partition Tables.</programlisting>
<para>Adds support for <ulink
url="http://en.wikipedia.org/wiki/GUID_Partition_Table">GUID
Partition Tables</ulink> (<acronym>GPT</acronym>). GPT
provides the ability to have a large number of partitions per
disk, 128 in the standard configuration.</para>
<programlisting>options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]</programlisting>
<para>Compatibility with 4.3BSD. Leave this in as some programs
will act strangely if this is commented out.</para>
<programlisting>options COMPAT_FREEBSD4 # Compatible with &os;4</programlisting>
<para>This option is required to support applications compiled on
older versions of &os; that use older system call interfaces.
It is recommended that this option be used on all &i386; systems
that may run older applications. Platforms that gained support
after &os;&nbsp;4.X, such as ia64 and &sparc64;, do not require
this option.</para>
<programlisting>options COMPAT_FREEBSD5 # Compatible with &os;5</programlisting>
<para>This option is required to support applications compiled on
&os;&nbsp;5.X versions that use &os;&nbsp;5.X system call
interfaces.</para>
<programlisting>options COMPAT_FREEBSD6 # Compatible with &os;6</programlisting>
<para>This option is required to support applications compiled on
&os;&nbsp;6.X versions that use &os;&nbsp;6.X system call
interfaces.</para>
<programlisting>options COMPAT_FREEBSD7 # Compatible with &os;7</programlisting>
<para>This option is required on &os;&nbsp;8 and above to support
applications compiled on &os;&nbsp;7.X versions that use
&os;&nbsp;7.X system call interfaces.</para>
<programlisting>options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI</programlisting>
<para>This causes the kernel to pause for 5 seconds before probing
each SCSI device in the system. If the system only has IDE hard
drives, ignore this or lower the number to speed up booting.
However, if &os; has trouble recognizing the SCSI devices, the
number will have to be raised again.</para>
<programlisting>options KTRACE # ktrace(1) support</programlisting>
<para>This enables kernel process tracing, which is useful in
debugging.</para>
<programlisting>options SYSVSHM # SYSV-style shared memory</programlisting>
<para>This option provides for System&nbsp;V shared memory. The
most common use of this is the XSHM extension in X, which many
graphics-intensive programs will automatically take advantage of
for extra speed. If <application>Xorg</application> is
installed, include this.</para>
<programlisting>options SYSVMSG # SYSV-style message queues</programlisting>
<para>Support for System&nbsp;V messages. This option only adds
a few hundred bytes to the kernel.</para>
<programlisting>options SYSVSEM # SYSV-style semaphores</programlisting>
<para>Support for System&nbsp;V semaphores. Less commonly used,
but only adds a few hundred bytes to the kernel.</para>
<note>
<para>Using <option>-p</option> with &man.ipcs.1; will list any
processes using each of these System&nbsp;V facilities.</para>
</note>
<programlisting>options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions</programlisting>
<para>Real-time extensions added in the 1993 &posix;. Certain
applications in the Ports Collection use these.</para>
<programlisting>options KBD_INSTALL_CDEV # install a CDEV entry in /dev</programlisting>
<para>This option is required to allow the creation of keyboard
device nodes in <filename
class="directory">/dev</filename>.</para>
<indexterm>
<primary>kernel options</primary>
<secondary>SMP</secondary>
</indexterm>
<programlisting>device apic # I/O APIC</programlisting>
<para>This device enables the use of the I/O APIC for interrupt
delivery. It can be used in both uni-processor and SMP kernels,
but is required for SMP kernels. Add <literal>options
SMP</literal> to include support for multiple
processors.</para>
<note>
<para>This device exists only on the i386 architecture and this
configuration line should not be used on other
architectures.</para>
</note>
<programlisting>device eisa</programlisting>
<para>Include this for systems with an EISA motherboard. This
enables auto-detection and configuration support for all devices
on the EISA bus.</para>
<programlisting>device pci</programlisting>
<para>Include this for systems with a PCI motherboard. This
enables auto-detection of PCI cards and gatewaying from the PCI
to ISA bus.</para>
<programlisting># Floppy drives
device fdc</programlisting>
<para>This is the floppy drive controller.</para>
<programlisting># ATA and ATAPI devices
device ata</programlisting>
<para>This driver supports all ATA and ATAPI devices. Only
one <literal>device ata</literal> line is needed for the kernel
to detect all PCI ATA/ATAPI devices on modern machines.</para>
<programlisting>device atadisk # ATA disk drives</programlisting>
<para>This is needed along with <literal>device ata</literal> for
ATA disk drives.</para>
<programlisting>device ataraid # ATA RAID drives</programlisting>
<para>This is needed along with <literal>device ata</literal>
for ATA RAID drives.</para>
<programlisting><anchor id="kernelconfig-atapi"/>
device atapicd # ATAPI CDROM drives</programlisting>
<para>This is needed along with <literal>device ata</literal>
for ATAPI CDROM drives.</para>
<programlisting>device atapifd # ATAPI floppy drives</programlisting>
<para>This is needed along with <literal>device ata</literal> for
ATAPI floppy drives.</para>
<programlisting>device atapist # ATAPI tape drives</programlisting>
<para>This is needed along with <literal>device ata</literal> for
ATAPI tape drives.</para>
<programlisting>options ATA_STATIC_ID # Static device numbering</programlisting>
<para>This makes the controller number static. Without this, the
device numbers are dynamically allocated.</para>
<programlisting># SCSI Controllers
device ahb # EISA AHA1742 family
device ahc # AHA2940 and onboard AIC7xxx devices
options AHC_REG_PRETTY_PRINT # Print register bitfields in debug
# output. Adds ~128k to driver.
device ahd # AHA39320/29320 and onboard AIC79xx devices
options AHD_REG_PRETTY_PRINT # Print register bitfields in debug
# output. Adds ~215k to driver.
device amd # AMD 53C974 (Teckram DC-390(T))
device isp # Qlogic family
#device ispfw # Firmware for QLogic HBAs- normally a module
device mpt # LSI-Logic MPT-Fusion
#device ncr # NCR/Symbios Logic
device sym # NCR/Symbios Logic (newer chipsets + those of `ncr')
device trm # Tekram DC395U/UW/F DC315U adapters
device adv # Advansys SCSI adapters
device adw # Advansys wide SCSI adapters
device aha # Adaptec 154x SCSI adapters
device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60.
device bt # Buslogic/Mylex MultiMaster SCSI adapters
device ncv # NCR 53C500
device nsp # Workbit Ninja SCSI-3
device stg # TMC 18C30/18C50</programlisting>
<para>In this section, comment out any SCSI controllers not on
the system. For an IDE only system, these lines can be removed.
The <literal>*_REG_PRETTY_PRINT</literal> lines are
debugging options for their respective drivers.</para>
<programlisting># SCSI peripherals
device scbus # SCSI bus (required for SCSI)
device ch # SCSI media changers
device da # Direct Access (disks)
device sa # Sequential Access (tape etc)
device cd # CD
device pass # Passthrough device (direct SCSI access)
device ses # SCSI Environmental Services (and SAF-TE)</programlisting>
<para>Comment out any SCSI peripherals not on the system. If
the system only has IDE hardware, these lines can be removed
completely.</para>
<note>
<para>The USB &man.umass.4; driver and a few other drivers use
the SCSI subsystem even though they are not real SCSI devices.
Do not remove SCSI support if any such drivers are included in
the kernel configuration.</para>
</note>
<programlisting># RAID controllers interfaced to the SCSI subsystem
device amr # AMI MegaRAID
device arcmsr # Areca SATA II RAID
device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID
device ciss # Compaq Smart RAID 5*
device dpt # DPT Smartcache III, IV - See NOTES for options
device hptmv # Highpoint RocketRAID 182x
device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx
device iir # Intel Integrated RAID
device ips # IBM (Adaptec) ServeRAID
device mly # Mylex AcceleRAID/eXtremeRAID
device twa # 3ware 9000 series PATA/SATA RAID
# RAID controllers
device aac # Adaptec FSA RAID
device aacp # SCSI passthrough for aac (requires CAM)
device ida # Compaq Smart RAID
device mfi # LSI MegaRAID SAS
device mlx # Mylex DAC960 family
device pst # Promise Supertrak SX6000
device twe # 3ware ATA RAID</programlisting>
<para>Supported RAID controllers. If the system does not have any
of these, comment them out or remove them.</para>
<programlisting># atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc # AT keyboard controller</programlisting>
<para>The <literal>atkbdc</literal> keyboard controller provides
I/O services for the AT keyboard and PS/2 style pointing
devices. This controller is required by &man.atkbd.4; and
&man.psm.4;.</para>
<programlisting>device atkbd # AT keyboard</programlisting>
<para>The &man.atkbd.4; driver, together with the &man.atkbdc.4;
controller, provides access to the AT 84 keyboard or the AT
enhanced keyboard which is connected to the AT keyboard
controller.</para>
<programlisting>device psm # PS/2 mouse</programlisting>
<para>Use this device if the mouse plugs into the PS/2 mouse
port.</para>
<programlisting>device kbdmux # keyboard multiplexer</programlisting>
<para>Basic support for keyboard multiplexing. If the system
does not use more than one keyboard, this line can be safely
removed.</para>
<programlisting>device vga # VGA video card driver</programlisting>
<para>The &man.vga.4; video card driver.</para>
<programlisting>
device splash # Splash screen and screen saver support</programlisting>
<para>Required by the boot splash screen and screen savers.</para>
<programlisting># syscons is the default console driver, resembling an SCO console
device sc</programlisting>
<para>&man.sc.4; is the default console driver and resembles a SCO
console. Since most full-screen programs access the console
through a terminal database library like
<filename>termcap</filename>, it should not matter whether
this or <literal>vt</literal>, the
<literal>VT220</literal> compatible console driver, is used.
When a user logs in, the <envar>TERM</envar> variable can be set
to <literal>scoansi</literal> if full-screen programs have
trouble running under this console.</para>
<programlisting># Enable this for the pcvt (VT220 compatible) console driver
#device vt
#options XSERVER # support for X server on a vt console
#options FAT_CURSOR # start with block cursor</programlisting>
<para>This is a VT220-compatible console driver, backward
compatible to VT100/102. It works well on some laptops which
have hardware incompatibilities with <literal>sc</literal>.
Users may need to set <envar>TERM</envar> to
<literal>vt100</literal> or <literal>vt220</literal> after
login. This driver is useful when connecting to a large number
of different machines over the network, where
<filename>termcap</filename> or <filename>terminfo</filename>
entries for the <literal>sc</literal> device are not
available as <literal>vt100</literal> should be available
on virtually any platform.</para>
<programlisting>device agp</programlisting>
<para>Include this if the system has an AGP card. This will
enable support for AGP and AGP GART for boards which have these
features.</para>
<programlisting># Add suspend/resume support for the i8254.
device pmtimer</programlisting>
<para>Timer device driver for power management events, such as
APM and ACPI.</para>
<programlisting># PCCARD (PCMCIA) support
# PCMCIA and cardbus bridge support
device cbb # cardbus (yenta) bridge
device pccard # PC Card (16-bit) bus
device cardbus # CardBus (32-bit) bus</programlisting>
<para>PCMCIA support. Keep this on laptop systems.</para>
<programlisting># Serial (COM) ports
device sio # 8250, 16[45]50 based serial ports</programlisting>
<para>These are the serial ports referred to as
<devicename>COM</devicename> ports in &windows;.</para>
<note>
<para>If the system has an internal modem on
<devicename>COM4</devicename> and a serial port at
<devicename>COM2</devicename>, change the IRQ of the modem to
2. For a multiport serial card, refer to &man.sio.4; for more
information on the proper values to add to
<filename>/boot/device.hints</filename>. Some video cards,
notably those based on S3 chips, use I/O addresses in the
form of <literal>0x*2e8</literal>. Since many cheap serial
cards do not fully decode the 16-bit I/O address space, they
clash with these cards, making the
<devicename>COM4</devicename> port practically
unavailable.</para>
<para>Each serial port is required to have a unique IRQ and the
default IRQs for <devicename>COM3</devicename> and
<devicename>COM4</devicename> cannot be used. The exception
is multiport cards where shared interrupts are
supported.</para>
</note>
<programlisting># Parallel port
device ppc</programlisting>
<para>This is the ISA bus parallel port interface.</para>
<programlisting>device ppbus # Parallel port bus (required)</programlisting>
<para>Provides support for the parallel port bus.</para>
<programlisting>device lpt # Printer</programlisting>
<para>Adds support for parallel port printers.</para>
<note>
<para>All three of the above are required to enable parallel
printer support.</para>
</note>
<programlisting>device ppi # Parallel port interface device</programlisting>
<para>The general-purpose I/O (<quote>geek port</quote>) +
IEEE1284 I/O.</para>
<programlisting>#device vpo # Requires scbus and da</programlisting>
<indexterm><primary>zip drive</primary></indexterm>
<para>This is for an Iomega Zip drive. It requires
<literal>scbus</literal> and <literal>da</literal> support.
Best performance is achieved with ports in EPP 1.9 mode.</para>
<programlisting>#device puc</programlisting>
<para>Uncomment this device if the system has a
<quote>dumb</quote> serial or parallel PCI card that is
supported by the &man.puc.4; glue driver.</para>
<programlisting># PCI Ethernet NICs.
device de # DEC/Intel DC21x4x (<quote>Tulip</quote>)
device em # Intel PRO/1000 adapter Gigabit Ethernet Card
device ixgb # Intel PRO/10GbE Ethernet Card
device txp # 3Com 3cR990 (<quote>Typhoon</quote>)
device vx # 3Com 3c590, 3c595 (<quote>Vortex</quote>)</programlisting>
<para>Various PCI network card drivers. Comment out or remove
any of these which are not present in the system.</para>
<programlisting># PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device miibus # MII bus support</programlisting>
<para>MII bus support is required for some PCI 10/100 Ethernet
NICs, namely those which use MII-compliant transceivers or
implement transceiver control interfaces that operate like an
MII. Adding <literal>device miibus</literal> to the kernel
config pulls in support for the generic miibus API and all of
the PHY drivers, including a generic one for PHYs that are not
specifically handled by an individual driver.</para>
<programlisting>device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet
device bfe # Broadcom BCM440x 10/100 Ethernet
device bge # Broadcom BCM570xx Gigabit Ethernet
device dc # DEC/Intel 21143 and various workalikes
device fxp # Intel EtherExpress PRO/100B (82557, 82558)
device lge # Level 1 LXT1001 gigabit ethernet
device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet
device nge # NatSemi DP83820 gigabit ethernet
device nve # nVidia nForce MCP on-board Ethernet Networking
device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc')
device re # RealTek 8139C+/8169/8169S/8110S
device rl # RealTek 8129/8139
device sf # Adaptec AIC-6915 (<quote>Starfire</quote>)
device sis # Silicon Integrated Systems SiS 900/SiS 7016
device sk # SysKonnect SK-984x &amp; SK-982x gigabit Ethernet
device ste # Sundance ST201 (D-Link DFE-550TX)
device stge # Sundance/Tamarack TC9021 gigabit Ethernet
device ti # Alteon Networks Tigon I/II gigabit Ethernet
device tl # Texas Instruments ThunderLAN
device tx # SMC EtherPower II (83c170 <quote>EPIC</quote>)
device vge # VIA VT612x gigabit ethernet
device vr # VIA Rhine, Rhine II
device wb # Winbond W89C840F
device xl # 3Com 3c90x (<quote>Boomerang</quote>, <quote>Cyclone</quote>)</programlisting>
<para>Drivers that use the MII bus controller code.</para>
<programlisting># ISA Ethernet NICs. pccard NICs included.
device cs # Crystal Semiconductor CS89x0 NIC
# 'device ed' requires 'device miibus'
device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards
device ex # Intel EtherExpress Pro/10 and Pro/10+
device ep # Etherlink III based cards
device fe # Fujitsu MB8696x based cards
device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc.
device lnc # NE2100, NE32-VL Lance Ethernet cards
device sn # SMC's 9000 series of Ethernet chips
device xe # Xircom pccard Ethernet
# ISA devices that use the old ISA shims
#device le</programlisting>
<para>ISA Ethernet drivers. See
<filename>/usr/src/sys/<replaceable>i386</replaceable>/conf/NOTES</filename>
for details of which cards are supported by which driver.</para>
<programlisting># Wireless NIC cards
device wlan # 802.11 support</programlisting>
<para>Generic 802.11 support. This line is required for wireless
networking.</para>
<programlisting>device wlan_wep # 802.11 WEP support
device wlan_ccmp # 802.11 CCMP support
device wlan_tkip # 802.11 TKIP support</programlisting>
<para>Crypto support for 802.11 devices. These lines are needed
on systems which use encryption and 802.11i security
protocols.</para>
<programlisting>device an # Aironet 4500/4800 802.11 wireless NICs.
device ath # Atheros pci/cardbus NIC's
device ath_hal # Atheros HAL (Hardware Access Layer)
device ath_rate_sample # SampleRate tx rate control for ath
device awi # BayStack 660 and others
device ral # Ralink Technology RT2500 wireless NICs.
device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs.
#device wl # Older non 802.11 Wavelan wireless NIC.</programlisting>
<para>Support for various wireless cards.</para>
<programlisting># Pseudo devices
device loop # Network loopback</programlisting>
<para>This is the generic loopback device for TCP/IP. This is
<emphasis>mandatory</emphasis>.</para>
<programlisting>device random # Entropy device</programlisting>
<para>Cryptographically secure random number generator.</para>
<programlisting>device ether # Ethernet support</programlisting>
<para><literal>ether</literal> is only needed if the system has
an Ethernet card. It includes generic Ethernet protocol
code.</para>
<programlisting>device sl # Kernel SLIP</programlisting>
<para><literal>sl</literal> provides SLIP support. This has been
almost entirely supplanted by PPP, which is easier to set up,
better suited for modem-to-modem connection, and more
powerful.</para>
<programlisting>device ppp # Kernel PPP</programlisting>
<para>This is for kernel PPP support for dial-up connections.
There is also a version of PPP implemented as a userland
application that uses <literal>tun</literal> and offers more
flexibility and features such as demand dialing.</para>
<programlisting>device tun # Packet tunnel.</programlisting>
<para>This is used by the userland PPP software. See the <link
linkend="userppp">PPP</link> section of the Handbook for more
information.</para>
<programlisting><anchor id="kernelconfig-ptys"/>
device pty # Pseudo-ttys (telnet etc)</programlisting>
<para>This is a <quote>pseudo-terminal</quote> or simulated
login port. It is used by incoming <command>telnet</command>
and <command>rlogin</command> sessions,
<application>xterm</application>, and some other applications
such as <application>Emacs</application>.</para>
<programlisting>device md # Memory <quote>disks</quote></programlisting>
<para>Memory disk pseudo-devices.</para>
<programlisting>device gif # IPv6 and IPv4 tunneling</programlisting>
<para>This implements IPv6 over IPv4 tunneling, IPv4 over IPv6
tunneling, IPv4 over IPv4 tunneling, and IPv6 over IPv6
tunneling. The <literal>gif</literal> device is
<quote>auto-cloning</quote>, and will create device nodes as
needed.</para>
<programlisting>device faith # IPv6-to-IPv4 relaying (translation)</programlisting>
<para>This pseudo-device captures packets that are sent to it and
diverts them to the IPv4/IPv6 translation daemon.</para>
<programlisting># The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device bpf # Berkeley packet filter</programlisting>
<para>The Berkeley Packet Filter pseudo-device allows network
interfaces to be placed in promiscuous mode, capturing every
packet on a broadcast network such as an Ethernet network.
These packets can be captured to disk and or examined using
&man.tcpdump.1;.</para>
<note>
<para>The &man.bpf.4; device is also used by &man.dhclient.8;.
If DHCP is used, leave this uncommented.</para>
</note>
<programlisting># USB support
device uhci # UHCI PCI-&gt;USB interface
device ohci # OHCI PCI-&gt;USB interface
device ehci # EHCI PCI-&gt;USB interface (USB 2.0)
device usb # USB Bus (required)
#device udbp # USB Double Bulk Pipe devices
device ugen # Generic
device uhid # <quote>Human Interface Devices</quote>
device ukbd # Keyboard
device ulpt # Printer
device umass # Disks/Mass storage - Requires scbus and da
device ums # Mouse
device ural # Ralink Technology RT2500USB wireless NICs
device urio # Diamond Rio 500 MP3 player
device uscanner # Scanners
# USB Ethernet, requires mii
device aue # ADMtek USB Ethernet
device axe # ASIX Electronics USB Ethernet
device cdce # Generic USB over Ethernet
device cue # CATC USB Ethernet
device kue # Kawasaki LSI USB Ethernet
device rue # RealTek RTL8150 USB Ethernet</programlisting>
<para>Support for various USB devices.</para>
<programlisting># FireWire support
device firewire # FireWire bus code
device sbp # SCSI over FireWire (Requires scbus and da)
device fwe # Ethernet over FireWire (non-standard!)</programlisting>
<para>Support for various Firewire devices.</para>
<para>For more information and additional devices supported by
&os;, see
<filename>/usr/src/sys/<replaceable>i386</replaceable>/conf/NOTES</filename>.</para>
<sect2>
<title>Large Memory Configurations
(<acronym>PAE</acronym>)</title>
<indexterm>
<primary>Physical Address Extensions
(<acronym>PAE</acronym>)</primary>
<secondary>large memory</secondary>
</indexterm>
<para>Large memory configuration machines require access to
more than the 4 gigabyte limit on User+Kernel Virtual
Address (<acronym>KVA</acronym>) space. Due to this
limitation, Intel added support for 36-bit physical address
space access in the &pentium; Pro and later line of
CPUs.</para>
<para>The Physical Address Extension (<acronym>PAE</acronym>)
capability of the &intel; &pentium; Pro and later CPUs allows
memory configurations of up to 64 gigabytes. &os; provides
support for this capability via the <option>PAE</option>
kernel configuration option, available in all current release
versions of &os;. Due to the limitations of the Intel memory
architecture, no distinction is made for memory above or below
4 gigabytes. Memory allocated above 4 gigabytes is simply
added to the pool of available memory.</para>
<para>To enable <acronym>PAE</acronym> support in the kernel,
add the following line to the kernel configuration
file:</para>
<programlisting>options PAE</programlisting>
<note>
<para>The <acronym>PAE</acronym> support in &os; is only
available for &intel; IA-32 processors. It should also be
noted that the <acronym>PAE</acronym> support in &os; has
not received wide testing, and should be considered beta
quality compared to other stable features of &os;.</para>
</note>
<para><acronym>PAE</acronym> support in &os; has a few
limitations:</para>
<itemizedlist>
<listitem>
<para>A process is not able to access more than 4
gigabytes of virtual memory space.</para>
</listitem>
<listitem>
<para>Device drivers that do not use the &man.bus.dma.9;
interface will cause data corruption in a
<acronym>PAE</acronym> enabled kernel and are not
recommended for use. For this reason, a
<filename>PAE</filename> kernel configuration file is
provided in &os; which excludes all drivers not known to
work in a <acronym>PAE</acronym> enabled kernel.</para>
</listitem>
<listitem>
<para>Some system tunables determine memory resource usage
by the amount of available physical memory. Such
tunables can unnecessarily over-allocate due to the
large memory nature of a <acronym>PAE</acronym> system.
One such example is the
<varname>kern.maxvnodes</varname> sysctl, which controls
the maximum number of vnodes allowed in the kernel. It
is advised to adjust this and other such tunables to a
reasonable value.</para>
</listitem>
<listitem>
<para>It might be necessary to increase the kernel virtual
address (<acronym>KVA</acronym>) space or to reduce the
amount of specific kernel resource that is heavily used
in order to avoid <acronym>KVA</acronym> exhaustion.
The <option>KVA_PAGES</option> kernel option can be used
for increasing the <acronym>KVA</acronym> space.</para>
</listitem>
</itemizedlist>
<para>For performance and stability concerns, it is advised to
consult &man.tuning.7;. &man.pae.4; contains up-to-date
information on &os;'s <acronym>PAE</acronym> support.</para>
</sect2>
</sect1>
<sect1 id="kernelconfig-trouble">
<title>If Something Goes Wrong</title>
<para>There are four categories of trouble that can occur when
building a custom kernel. They are:</para>
<variablelist>
<varlistentry>
<term><command>config</command> fails:</term>
<listitem>
<para>If &man.config.8; fails, it is probably a simple
error. Fortunately, &man.config.8; will print the line
number that it had trouble with. For example, for
this message:</para>
<screen>config: line 17: syntax error</screen>
<para>Make sure the keyword on line 17 is typed correctly by
comparing it to the
<filename>GENERIC</filename> kernel or another
reference.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command>make</command> fails:</term>
<listitem>
<para>If <command>make</command> fails, it usually signals
an error in the kernel description which is not severe
enough for &man.config.8; to catch. Review the
configuration, and if you still cannot resolve the
problem, send an email to the &a.questions; with the
kernel configuration.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>The kernel does not boot:<anchor
id="kernelconfig-noboot"/></term>
<listitem>
<para>If the new kernel does not boot, or fails to recognize
devices, do not panic! Fortunately, &os; has an excellent
mechanism for recovering from incompatible kernels.
Simply choose the kernel to boot from at the &os; boot
loader. This can be accessed when the system boot menu
appears by selecting the <quote>Escape to a loader
prompt</quote> option. At the prompt, type
<command>boot
<replaceable>kernel.old</replaceable></command>, or
the name 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.</para>
<para>After booting with a good kernel, check over the
configuration file and try to build it again. One helpful
resource is <filename>/var/log/messages</filename> which
records the kernel messages from every successful boot.
Also, &man.dmesg.8; will print the kernel messages from
the current boot.</para>
<note>
<para>When troubleshooting a kernel, make sure to keep
<filename>GENERIC</filename>, or some other kernel that
is known to work, on hand as a different name that will
not get erased on the next build. Do not rely on
<filename>kernel.old</filename> because when installing
a new kernel, <filename>kernel.old</filename> is
overwritten with the last installed kernel which may
be non-functional. As soon as possible, move the
working kernel to the proper <filename
class="directory">/boot/kernel</filename>
location or commands such as &man.ps.1; may not work
properly. To do this, simply rename the directory
containing the good kernel:</para>
<screen>&prompt.root; <userinput>mv /boot/kernel <replaceable>/boot/kernel.bad</replaceable></userinput>
&prompt.root; <userinput>mv /boot/<replaceable>kernel.good</replaceable> /boot/kernel</userinput></screen>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>The kernel works, but &man.ps.1; does not work
any more:</term>
<listitem>
<para>If the kernel version differs from the one that the
system utilities have been built with, for example, a
-CURRENT kernel on a -RELEASE, many system status commands
like &man.ps.1; and &man.vmstat.8; will not work. To fix
this, <link linkend="makeworld">recompile and install a
world</link> built with the same version of the
source tree as the kernel. This is one reason why it is
not a good idea to use a different version of the kernel
than the rest of the operating system.</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
</chapter>