UNIX System Administration Handbook - Evi Nemeth [147]
Install the new kernel
Before you boot a new kernel, make sure you can recover your system if the new kernel doesn’t work. Never replace the old kernel directly with a new one, because you will then have nothing to boot from in the event of a catastrophe. Traditionally, kernels have been called /vmunix, but every OS seems to call them something different these days. Under FreeBSD, the kernel is /kernel.
You should back up your old kernel by moving /kernel to /kernel.works. All systems provide some way to keep an old kernel bootable while you test a new one. Check the section on boot loaders in Chapter 2, Booting and Shutting Down, for more information, or consult your manuals.
/kernel can be a hard link to some other filename, so you can just make a link to your new kernel rather than copying it. If the kernel is not called /kernel and you don’t make this link, the boot loader will have difficulty finding it.
Test the new kernel
If the system boots successfully, you are probably in good shape. However, you should try a few checks just to make sure. Run ls on at least one directory in each filesystem. Success indicates that the filesystem is functioning correctly. ping another machine on your network to see if your network device is working properly.
Document the new kernel
Before washing your hands of this whole sordid kernel business, go back to your original SYS/i386/conf/KERNEL_NAME file and put in copious comments so that you will understand what you have done when you come back to read it six months or a year later.
If you have lots of free space, you can preserve the SYS/compile/KERNEL_NAME directory to speed up subsequent alterations. If you’re tight on space, just delete it; everything it contains can be regenerated with config.
12.7 CREATING A BSD CONFIGURATION FILE
Creating the configuration file (under SYS/i386/conf) is the hardest part of building a BSD kernel; the rest of the process is quite mechanical.
A configuration file is a list of control phrases, one per line. Any line beginning with a tab character is considered a continuation of the previous line. Anything between a pound sign (#) and the end of a line is considered a comment, and blank lines are ignored. Keywords must be separated by whitespace, but except for this and the special meaning of tabs as continuation characters, spaces and tabs are ignored.
Integers in the configuration file can be entered in hexadecimal, octal, or decimal form. Octal numbers are identified by a leading zero, and hexadecimal numbers by a leading 0x. Strings must be double quoted if they contain numbers used as text.
A control phrase begins with a single keyword that indicates how the remainder of the line is to be interpreted. The rest of the line provides the keyword’s arguments. Some keywords can accept a list of arguments separated by spaces or commas, but it’s wise to use only one argument per line. Most keywords that can accept multiple arguments can also have arbitrarily many control lines.
The order in which control phrases appear is usually not important; Table 12.6 shows the traditional order.
Table 12.6 Keywords used in BSD configuration files
The maxusers keyword
The maxusers keyword sets the sizes of several important system tables. As its name suggests, the argument to maxusers is roughly the maximum number of simultaneous users that the system is expected to support (though most versions of UNIX don’t actually enforce a limit on the number of users per se). If you want to tune this value yourself, you should boost it by 1 for each expected simultaneous user and, if you are configuring the kernel for an NFS server, by 1 for each client machine. Add 8 for each frame buffer on which a window system can be run.
The maxusers number affects the values of several other kernel parameters, such as the maximum number of processes,