FreeBSD --- Booting and Shutting Down process

The FreeBSD Startup Process

When you first start FreeBSD, it prints a flurry of messages on your screen from the kernel(bright white) and also from the various processes starting up(gray).
Note The following sections apply only to FreeBSD running on x86 (Intel) hardware. Although the startup process on Alpha, SPARC, or other platforms is similar, some of the details are slightly different.

The boot process itself can be divided into three main parts:

1. the loader
2. single-user startup, and 
3. multi-user startup

The POST and BIOS

The first thing your computer (i386 architecture) does when you turn it on is run the POST (Power-On Self Test). During this phase, your computer's BIOS (Basic Input/Output System), checks out all its hardware and makes sure everything is working.

Other hardware platforms have console firmware or bootroms that perform the same function. 

The BIOS is a small piece of software on a ROM or EPROM chip on your computer's system board.

1. Among other things, the BIOS is responsible for testing hardware when the computer is first turned on.
2. Then, it counts RAM and probes PnP (Plug and Play) devices to see what resources they can use. At that point, the POST is completed. 
3. The BIOS also finds and tests the first part of the operating system off the hard drive.

The Bootstrap

After the POST is complete, the BIOS searches for a device(like a disk) on your system that it can boot from. The system normally boots from the first bootable device it finds. If the BIOS doesn’t find a bootable device, it complains and gives up.

The specific devices the BIOS searches for and the order in which it searches for them are both determined by the configuration you have specified in your BIOS setup program; typically the BIOS boots from the first hard disk in the system, but other possible devices include the floppy drive, attached USB or FireWire drives, and the CD/DVD drive. The BIOS can even boot from the network card on (diskless) systems that have no hard disk and support loading the operating system over the network from a server.

After a bootable device is found (in this case, we'll assume it is the hard disk), the BIOS begins the bootstrap procedure: a multistage process, comprising several "boot blocks" (small programs that pull successively larger and larger pieces of the operating system into main memory).

Most BIOSes are rather dumb and can only recognize operating systems by very simple indicators. The "boot blocks" are sections of the disk that are specifically designed to be recognized as an operating system by the BIOS. On those "boot blocks", FreeBSD installs software that is only smart enough to load the main FreeBSD startup program, loader(8). The loader presents you with a FreeBSD logo on the right and a menu of six options on the left.

Selecting the Bootable Slice (boot0)

After the BIOS finds a bootable hard disk, it reads whatever is in sector 0(also known as the master boot record (MBR) ) of the hard disk.

Because of legacy PC BIOS limitations, the program located in the MBR can be only 512 bytes long. Therefore, it is a very simple program that knows just enough about the disk to be able to present a small but full-screen menu of the "slices" (partitions) that can be booted from. Here is an example of a menu that might be produced by boot0:

F1 DOS
F2 FreeBSD
F3 Drive 1

Default: F2

Here, you can use the function keys to select which slice you want to boot from and thus which operating system you want to start. (A slice is what other operating systems refer to as a partition or a BIOS partition) After you make a selection, boot0 finds and loads whatever is in the boot sector of the slice you selected. If FreeBSD is the only operating system on your hard disk, you will not see this menu, and the FreeBSD boot sector will be loaded immediately.

This begins the next stage of the bootstrap known as boot1.

boot1

boot1 is located on the first sector of the slice that is being booted. Like boot0, it can only be 512 bytes in size and therefore is very simple. It knows just enough to be able to find and load boot2.

boot2

boot2 knows enough to be able to load actual files off of the hard disk. Normally, boot2 loads a program called loader, although boot2 is capable of loading the kernel directly. The loader program is the next stage of the bootstrap.

The Loader Menu and the Kernel

The loader program is normally stored in /boot/loader. It is the program that allows you to control various options of the FreeBSD startup process, including which kernel should be booted, and so on. Ultimately, the loader finds and loads the kernel and passes control to it. After the kernel is booted, the bootstrap is complete.

The boot1 and boot2 "boot blocks" lead to the loader program, whose job is to give you an interface with which to control the kernel. As you will see, the kernel is literally the heart of the operating system, and it is loaded only after all the infrastructure of a bootable disk partition has been loaded into memory.

    The loader menu, is a text menu with a "daemon" mascot rendered in ASCII art (or a FreeBSD logo) and a set of options for booting FreeBSD into various modes, analogous to the "Safe Mode" and "MS-DOS Mode" of Windows.

1. Boot muliuser mode [default]
2. Boot in single-user mode(maintenance)
3. Escape to loader prompt
4. Reboot
5. kernel
6. Boot options

boot options

If you wait 10 seconds, the loader will automatically boot muliuser mode by default. Several other options(2,3,5,6) are only needed for debugging or troubleshooting.

The white messages that you see on screen when FreeBSD starts are messages from the kernel as it finds and initializes your hardware. Most of these messages will go by too fast for you to read, but after you log into the system, you can use the command:

dmesg | less

to view them one screen at a time, and use the spacebar to advance to the next screen.

the last boot message in dmesg is:

trying to mounting root from ufs:/dev/ada0p2 [rw]

meaning, the kernel mounted the root filesystem. After the root filesystem is mounted, the kernel passes control to a process called init.

Messages in light grey are triggered by things happening during the init stage. This is how you can differentiate kernel messages from non-kernel messages. Kernel messages are in white; non-kernel messages are in light grey.

init

When a FreeBSD system is properly shut down, it runs a program called sync on each disk to ensure that all data is written out, dismounts the filesystems, and then sets the clean flag on the filesystems.
This is similar to the process that Windows goes through when it shuts down. If a FreeBSD system is not properly shut down, the clean flag will not be set.

Filesystem Consistency Check

One of the first things that init does is check whether or not the clean flag is set. If it is, init mounts the filesystem for use.
If it isn't, init first runs the fsck program on the filesystem to make sure it isn't damaged and to repair any damage it finds that it knows how to repair. fsck is similar to the Scandisk program in Windows, and this process is similar to the Your system was not properly shut down procedure you see on a Windows reboot if you didn't properly shut it down first. If fsck encounters an error it cannot fix at this point, it drops the system into single user mode so the system administrator (which is probably you) can make the necessary repairs manually.

Assuming that the clean flag was set, or that fsck was able to repair the damage if it was not set, init then proceeds to mount each filesystem listed in the /etc/fstab file that has the mount at boot flag set.

If you need to, you can also run fsck manually.

System Configuration Scripts

After the filesystems are mounted, init reads the system configuration scripts (known as rc scripts --run control scripts-- ) located in /etc and /etc/defaults.
In addition, init checks the /usr/local/etc/rc.d directory for any additional scripts it should run at boot (these might be scripts to start Web servers, database servers, or any other program you want to run automatically at startup). If you are familiar with Windows and/or DOS, this part of the boot process is similar to config.sys, autoexec.bat, system.ini, and the parts of the Windows Registry that control Windows startup options.

For the sake of completeness, it should be mentioned that init also checks for and reads a file called /etc/rc.local, which can be used to start programs such as Web servers. However, this file is deprecated and may not be supported in future versions of FreeBSD. Therefore, it is recommended that you put your startup scripts in the /usr/local/etc/rc.d directory instead of in the /etc/rc.local file.

BSD versus Sys V Run Control

If you come from a Sys V UNIX background, you may be a little bit confused after that last section. So, here is a clarification.
In BSD init, the concept of run levels doesn't really exist. You pretty much have single user mode and a multiuser mode with network support. There is no multiuser mode without network support, as there is in Sys V run levels. There is no inittab file in BSD, as there is in Sys V. Also, startup options are mostly controlled by a single file called rc.conf. There are not separate files to start most services with links in different run-level directories, as there is in Sys V.

getty and Login

After reading the run control scripts, init starts a program on the console (and several virtual terminals). This program is normally the getty program, but it doesn't have to be. Another common program used in place of getty is xdm, which starts a graphical login session for the X-Windows system immediately after system boot (similar to an NT login session). The program that is started is defined in the file /etc/ttys. We will assume that it is the getty program.The getty program initializes the terminal (or console), and controls various security options and terminal-type options. Once again, these options and their values are defined in /etc/ttys.
The getty program then starts the login program to validate your login name and password.

Logging In to FreeBSD

After all the startup processes are complete, you see a screen that looks something like this: 

If you didn't configure any network information during the installation, the default host name for your system is amnesiac.

Enter the login name of the normal user (not the root user) that you created for yourself during the installation. Press [Enter] and then enter the password you gave yourself(during the installation) when prompted. Note that the password will not be displayed onscreen. Actually, nothing will be displayed onscreen. Don't worry, though. Your password is being read.
After you enter the password, the login program checks the password database for a match. If it finds one, you see get a screen that looks something like this:

in figure miss but here is a line worth to pay attention

Last login: Tue Apr 10 15:19:17 on ttyv0

If you're sure youwasn't you then someone else logged into your account. If something like this ever happens, change your password IMMEDIATELY (use the passwd command and follow the instructions it gives), and also notify your system administrator of the security breach (assuming that you are not the system administrator).

The root user's login prompt is the pound sign (#). A normal user's login prompt will usually be either $ for Bourne-style shells, or % or > for C-style shells. Either way, the type of prompt you have serves as a constant reminder when you are logged in as root, and as a warning to be extra careful when issuing potentially dangerous commands.

If you mistype either the login name or password, FreeBSD will respond with the following:

Login incorrect
login:


If this happens, simply try again, starting with your login name.

If you mistype your login name or password three times in a row, it may appear that the system has hung because it looks as if nothing is happening. Don't worry. The system hasn't hung. This delay is a security feature that helps reduce the effectiveness of password-cracking programs that simply try random words as passwords to break into an account. The delay may get progressively longer on each mistype after three. Wait several seconds, though, and the login prompt will reappear.

Logging Out of FreeBSD

When you are done using FreeBSD (or you are going to lunch or something), you should log out of the system if you are in an area in which others have access to your computer or terminal. This prevents other users from being able to access your account. To log out of FreeBSD, simply type 

exit 

at the command prompt. This should return you to the login prompt, as you saw when FreeBSD first finished booting.

If you were working on something that you do not want others to be able to see if they happen to walk past your screen, you can clear the screen by typing 

clear 

at a command prompt.

Shutting Down the FreeBSD System

It is very important that you always shut down a unix system properly before turning off the power. Failure to do so can result in serious damage to the filesystem.
You need to be the root user to shut down the system—either by logging in directly as root or by using the su command to become root.

Using the shutdown Command

The normal way to shut down the system is with the shutdown command. The basic syntax of the shutdown command is as follows:


shutdown [action] [when] [broadcast message]

In other words, the first option tells shutdown what to do, the second option tells shutdown when to do it, and the third option tells shutdown the message it should send to all logged-in users.

The "broadcast message" part of shutdown is a message that will be broadcast at regular intervals to all logged-in users. These messages start coming 10 hours before the impending shutdown and get more frequent as the shutdown time gets closer.

 
The "when" part of shutdown can be specified in several ways.

• the keyword now tells shutdown to perform the action now. 
• the format +n where n is the number of minutes shutdown should wait before performing the action (this gives users time to save their files and close their programs). 
• The format yymmhhmm is also supported to specify an exact time the action should be performed. Here, yy is the year, mm is the month, hh is the hour (in a 24-hour format), and mm is the minute. If the year and month parts are eliminated, shutdown will assume that the shutdown should happen today. If you specify a time that has already past, shutdown will complain.

On a multiuser system, you would normally give time and a reason for the shutdown to your users

# shutdown -h +10 test


Five minutes before the impending shutdown, a file called /var/run/nologin will be created.

This file disables any further logins, and displays its contents when someone attempts to log in. The shutdown command places the time of the shutdown and the broadcast message in this file.

When the countdown clock runs out, the following actions are performed:

• A TERM signal is sent to init, which ceases creating any new processes.
• init reads the file /etc/rc.shutdown, and runs any program-specific shutdown scripts it contains.
• All processes are sent a TERM signal and given time to terminate themselves gracefully.
• Any processes that did not respond to the TERM signal in a reasonable amount of time are sent a KILL signal, which cannot be ignored, and will force the process to terminate ungracefully.
• Cache data is written out to the filesystems with the sync command, the filesystems are dismounted, and the clean flag is set.
• The kernel is halted.

In addition, shutdown writes an entry in the system log noting the time of the shutdown and who performed the shutdown.

Two other commands —halt and reboot— can be used to halt and reboot the system, respectively. However, I do not recommend that you get in the habit of using either one. Neither of these commands runs the rc.shutdown script, which can cause some programs to terminate improperly. Also, neither of these programs allows you to specify a delay, and neither of these programs gives users any warning about the impending shutdown.


----------------------------------------------------------------------------------------------------------
under editing

-----------------------------------------------------------------------------------------------------------

Boot FreeBSD with ACPI disabled

ACPI (Advanced Configuration and Power Interface) is  an Intel/Toshiba/Microsoft standard for configuring hardware. It replaces the legacy standards APM (Advanced Power Management), PnPBIOS, the MP table, the $PIR table, and a whole bunch of other standards even more obscure.

    ACPI provides many benefits to modern hardware, but some hardware has troublesome ACPI implementations. On the other hand, much new SMP hardware absolutely requires ACPI .

If your newly installed system will not boot normally, try booting it with ACPI disabled. 

If your system has worked well for some time, but suddenly has trouble booting, disabling ACPI probably won’t help.

Boot FreeBSD in safe mode

FreeBSD’s safe mode turns on just about every conservative option in the operating system.

1. ATA hard disks run without DMA or write caching, limiting their speed but increasing their reliability by working around cabling issues and other physical problems
2. EISA slots are not probed
3. ACPI is disabled
4. On i386 systems, SMP is disabled
5. USB keyboards will no longer work in single-user mode

This option is useful for disaster recovery and debugging older or otherwise troublesome hardware.

Boot FreeBSD in single-user mode

Single-user mode is another one minimal startup mode (FreeBSD can perform a minimal boot that

1. loads the kernel
2. finds devices but 
3. doesn’t automatically set up your filesystems
4. doesn’t automatically start the network
5. doesn’t automatically enable security
6. doesn’t automatically run any standard Unix services

You can perform any or all of those non-automated activities yourself. That is very useful on damaged systems(even when the damage was self-inflicted).

It’s the earliest point where FreeBSD can provide a command prompt.

When you choose a single-user mode boot, you’ll see the regular system startup messages flow past. Before any programs start, however, the kernel offers you a chance to choose a shell. You can enter any shell on the root partition; I usually just take the default of /bin/sh, but use /bin/tcsh or bash(you must install it) if you prefer.

Disks in Single-User Mode

In single-user mode, the root partition is mounted read-only and no other

disks are mounted. Many of the programs that you’ll want to use are on partitions other than the root, so you’ll want them all mounted read-write and available. To make sure that your filesystems are in a usable state, run the following commands:

# fsck -p
# mount -a

The fsck(8) program “cleans” the filesystems, confirms that they are internally consistent and that all the files that a disk thinks it has are actually present and accounted for.

    Make the filesystems accessible with mount(8). The -a flag mounts every filesystem listed in /etc/fstab, but if one of these filesystems is causing your problems, you can mount the desired filesystems individually by specifying them on the command line (for example, mount /usr).

If you’re an advanced user with NFS filesystems configured, you’ll see error messages for those filesystems at this point because the network isn’t up yet.

If you have trouble mounting partitions by name, try using the device name instead. The device name for the root partition is probably either /dev/ad0s1a (for IDE disks) or /dev/da0s1a (for SCSI disks). You’ll also need to specify a mount point for this partition. For example, to mount your first IDE disk partition as root, enter the command:

# mount /dev/ad0s1a /

If you have network filesystems on your server but your network is not yet up, you can mount all your local partitions by specifying the filesystem type. Here, we mount all of the local filesystems of type UFS, FreeBSD’s default filesystem type:

# mount -a -t ufs

Programs Available in Single-User Mode

The commands available for your use depend on which partitions are mounted. Some basic commands are available in /bin and /sbin, on the root partition, and are available even if root is mounted read-only. Others live in /usr and are inaccessible until you mount that partition. (Take a look at /bin and /sbin on your system to get an idea of what you’ll have to work with when things go bad.)

If you’ve scrambled your shared library system, none of these programs will work. If you’re that unlucky, FreeBSD provides statically-linked versions of many core utilities in the /rescue directory.

The Network in Single-User Mode

If you want to have network connectivity in single-user mode, use the shell script /etc/netstart. This script

1. calls the appropriate scripts to start the network, 
2. gives IP addresses to interfaces, and 
3. enables packet filtering and routing.

If you want some, but not all, of these services, you’ll need to read that shell script and execute the appropriate commands manually.

Uses for Single-User Mode

In single-user mode, your access to the system is only limited by your knowledge of FreeBSD and Unix. For example, if you’ve forgotten your root password you can reset it from single-user mode:

# passwd
Changing local password for root
New Password:
Retype New Password:
#

Note that you weren’t asked for the old root password. In single-user mode, you’re automatically root, and passwd(8) doesn’t ask root for any password.

Or, if you find that there’s a typo in /etc/fstab that confuses the system and makes it unbootable, you can mount the root partition with the device name, then edit /etc/fstab to resolve the issue.

     Or, if you have a program that panics the system on boot and you need to stop that program from starting again, you can either edit /etc/rc.conf to disable the program, or just set the permissions on the startup script so that it cannot execute.

# chmod 444 /usr/local/etc/rc.d/program.sh

There’s a reason all of these examples involve recovering from human errors. Hardware failures are not common, and FreeBSD failures even less so. If it wasn’t for human error, our computers would almost never let us down. As you learn more about FreeBSD, you’ll be more and more capable in single-user mode.

Boot FreeBSD with verbose logging

FreeBSD learns a lot about a computer as it boots. Much of this information is  irrelevant to day-to-day use, but very helpful when debugging. When you boot in verbose mode, FreeBSD prints all the details it can about every system setting and attached device. (This information will be available afterwards in /var/run/dmesg.boot, as discussed later) You might try verbose mode once on each of your machines, just to glimpse the complexity within your computers.

Escape to loader prompt

The loader prompt is a small computing environment (includes a command-line interpreter where you can issue commands) that allows you to make basic changes to your computer’s boot environment and the variables that must be configured early in the boot process. When you escape to a loader prompt (option 6 in the boot menu), you’ll see the following:

OK

This is the loader prompt. While the word OK might be friendly and reassuring, it’s one of the few friendly things about the loader environment.

This is not a full-featured operating system; it’s a tool for configuring a system boot which is not intended for the ignorant nor the faint of heart. Any changes you make at the loader prompt only affect the current boot. To undo changes, reboot again. (We’ll see how to make loader changes permanent in the next
section.) 

To see all the commands available to the loader, enter a question mark.

OK ? Available commands:
heap    show heap usage
reboot  reboot the system
bcachestat  get disk block cache stats
...

The first three commands in the loader, listed above, are pretty much useless to anyone except a developer. Instead, we’ll focus on the commands useful to a system administrator.

    To view the disks that the loader knows about, use lsdev.

OK lsdev
cd devices:
  disk devices:
     disk0:  BIOS drive C:
        disk0s1a: FFS
        disk0s1b: swap
        disk0s1d: FFS
        disk0s1e: FFS
        disk0s1f: FFS
   disk1:  BIOS drive D:
       disk1s1a: FFS
       disk1s1b: swap
   pxe devices:

1. The loader checks for CD drives and doesn’t find any. (The loader will only find CD drives if you boot from a CD, so don’t be alarmed at this.)
2. It finds two hard drives, known to the BIOS as drives C and D . It then describes the partitions it finds on these hard drives.
3. The root partition generally ends in a; this means that the only root partition here is shown as disk0s1a . On an unfamiliar system that’s having trouble booting, you might find this knowledge useful.

The loader has variables set within the kernel and by a configuration file. View these variables and their settings with the show command.

OK show
LINES=24
acpi_load=YES
autoboot_delay=NO
...

The spacebar advances to the next page. These values include:

1. IRQ and memory addresses for old ISA cards, 
2. low-level kernel tunables, and 
3. information gleaned from the BIOS.

You can change these values for a single boot with the set command. For example, to change the value console to comconsole, you would enter:

OK set console=comconsole

By the time the loader gives you a command prompt, it has already loaded the system kernel into memory. If you’ve never worked with a kernel before, just file these tidbits away until you get knowledge about .

    Use the lsmod command to view the kernel and kernel modules currently in memory.

OK lsmod
0x400000: /boot/kernel/kernel (elf kernel, 0x6a978c)
  modules: elink.1 io.1 splash.1 agp.1 nfsserver.1 nfslock.1 nfs.1 nfs4.1
wlan.1 if_gif.1 if_faith.1 ether.1 sysvshm.1 sysvsem.1 sysvmsg.1 
cd9660.1
isa.1 pseudofs.1 procfs.1 msdosfs.1 usb.1 cdce.0 random.1 ppbus.1 pci.1
pccard.1 null.1 mpt_raid.1 mpt.1 mpt_cam.1 mpt_core.1 miibus.1 mem.1 
isp.1
sbp.1 fwe.1 firewire.1 exca.1 cardbus.1 ast.1 afd.1 acd.1 ataraid.1 
atapci.1
ad.1 ata.1 ahc.1 ahd.1 ahd_pci.1 ahc_pci.1 ahc_isa.1 ahc_eisa.1 
scsi_low.1
  cam.1
0xaaa000: /boot/kernel/snd_via8233.ko (elf module, 0x6228)
  modules: snd_via8233.1
0xab1000: /boot/kernel/sound.ko (elf module, 0x23898)
  modules: sound.1
0xad5000: /boot/kernel/atapicam.ko (elf module, 0x4bac)
  modules: atapicam.1

While some of this information is of value only to developers, a system administrator can still learn a lot.

• Perhaps the most obviously useful information is the path to the loaded kernel . This should always be /boot/kernel/kernel unless you configured the loader to look elsewhere.
• You’ll also get a list of the modules included in each loaded kernel file. The example lists modules from the main kernel itself, ranging from elink to cam . The loader has also pulled in the files snd_via8233 , sound , and atapicam , with their respective modules.

To completely erase the loaded kernel and all modules from memory, use the unload command.

OK unload

You won’t get any confirmation, but a subsequent lsmod will show that the loader no longer remembers any kernel files.

    To load a different kernel, use load.

OK load boot/kernel.good/kernel
boot/kernel.good/kernel text=0x4a6324 data=0x84020+0x9908c
syms=[0x4+0x67220+0x4+0x7e178]

The loader will respond with the name of the file and some low-level information about it.

While I touch on loading alternate kernels here, before doing this you really need to understand why you would want to and how to do it safely.

Once your system boots just the way you need it to, you’ll probably want to make those settings permanent. FreeBSD lets you do this through the loader configuration file, /boot/loader.conf. Before you can make changes, however, you must understand FreeBSD’s default configuration filesystem.

Default Files

FreeBSD separates configuration files into:

1. default files and 
2. customization files. 

The default files contain variable assignments and are not intended to be edited; instead, they’re designed to be overridden by another file of the same name.

    Default configurations are kept in a directory called /default. For example, the boot loader configuration file is /boot/loader.conf, and the default configuration file is /boot/defaults/loader.conf.

If you want to see a comprehensive list of loader variables, check the default configuration file.

During upgrades, the installer replaces the default configuration files but does not touch your local configuration files. This separation ensures that your local changes remain intact while still allowing new values to be added to the system.   

FreeBSD adds features with every release, and its developers go to great lengths to ensure that changes to these files are backward compatible.This means that you won’t have to go through the upgraded configuration and manually merge in your changes; at most you’ll have to check out the new defaults file for nifty configuration opportunities and new system features.

The loader configuration file is a good example of these files. The /boot/defaults/loader.conf  file contains dozens of entries much like this:

verbose_loading="NO"  # Set to YES for verbose loader output

The variable verbose_loading defaults to NO. To change this setting, do not edit /boot/defaults/loader.conf—instead, add the line to /boot/loader.conf and change it there. Your /boot/loader.conf entries override the default setting, and your local configuration contains only your local changes. A sysadmin can easily see what changes have been made and how this system differs from the out-of-the-box configuration.

D O N ’ T   C O P Y   T H E   D E F AU L T    C O N F I G !

One common mistake is to copy the default configuration to the override file and then make changes there directly.  

    Such copying will cause major problems in certain parts of the system. You might get away with it in one or two places, but eventually it will bite you. Copying /etc/defaults/rc.conf to /etc/rc.conf, for example, will prevent your system from booting. You have been warned.

The default configuration mechanism appears throughout FreeBSD, especially in the core system configuration.

Loader Configuration

As i say earlier to make loader setting changes permanent, use the configuration file /boot/loader.conf. Settings in this file are fed directly into the boot loader at system startup. (Of course, if you enjoy being at your console every time the system boots, then you don’t have to bother with this!)

    If you look at the default loader configuration, you’ll see many options that resemble variables listed in the loader. For example, here we can set the name of the console device:

console="vidconsole"

Throughout the FreeBSD documentation, you’ll see references to boot-time tunables and loader settings. All of these are set in loader.conf. This includes many sysctl values that are read-only once the system is up and kicking.

    Here, we set the kernel variable kern.maxusers to 32 .

kern.maxusers="32"

Some of these variables do not have a specific value set in loader.conf; instead, they appear as empty quotes. This means that the loader normally lets the kernel set this value, but if you want to override the kernel you can (The kernel has an idea of what the value of kern.nbuf should be, but you can have the loader dictate a different value if you must).

kern.nbuf=""

Here are some commonly used loader values that affect the appearance and operation of the loader itself and basic boot functionality. As FreeBSD matures, the developers introduce new loader values and alter the functionality of old ones, so be sure to check /boot/defaults/loader.conf on your installation for the current list.

    This toggles the verbose boot mode that you can reach through the boot menu. In a standard boot, the kernel prints out a few basic notes about each device as it identifies system hardware. When you boot in verbose mode, the kernel tells each device driver to print out any and all information it can about each device as well as display assorted kernel-related setup details. This is useful for debugging and development, but not generally for day-to-day use.

boot_verbose="NO"

This is the number of seconds between the display of the boot menu and the automatic boot. I frequently turn this down to 2 or 3 seconds, as I want my machines to come up as quickly as possible.

autoboot_delay="10"

This controls the appearance of the boot menu (originally, an ASCII art image of the BSD “Beastie” mascot decorated the boot menu). If set to YES, the boot menu will not appear.

beastie_disable="NO"

You can choose which logo appears to the right of the boot menu.The default “FreeBSD” in ASCII art is the fbsdbw option. Other options include beastiebw (the original logo), beastie (the logo in color), and none (to have the menu appear without any logo)

loader_logo="fbsdbw"

Serial Consoles

All this console stuff is nice, but it can be a problem when your FreeBSD system is in a co-location facility on the other side of the country or on another continent.

    A keyboard and monitor are nice, too, but in many data centers you won’t have room for them.

    And how do you reset the machine remotely when it won’t respond to the network?

A serial console solves all these problems and more.

A serial console simply redirects the computer’s keyboard input and
video to the serial port instead of the keyboard and monitor. 

Serial consoles appear on all sorts of network equipment, from Cisco routers and Ethernet switches to network-based KVM switches. Many physical security systems, such as keypad-based door locks, also have serial consoles. By hooking up a standard null modem cable to the serial port and attaching the other end to another computer’s serial port, you can access the first system’s boot messages from the second computer. This is especially useful if the machines are at a remote location.

Your system must have a serial port to have a serial console.

An increasing number of systems are arriving “legacy-free,” meaning that they

lack such basic features as serial ports or PS/2 keyboard and mouse ports. Serial consoles can occur in both hardware and software.

Hardware Serial Consoles

Real Unix hardware (such as Sparc64 systems) has hardware serial console capability. On these boxes, you can attach a serial cable to the serial console port and have unfettered access to the hardware configuration, boot messages, and startup messages.

    Most x86 hardware does not allow this; you must be at the keyboard looking at the monitor to control the BIOS, and you must press the spacebar to interrupt the loader.

    A few x86 and amd64 motherboards do have this functionality, and more and more vendors such as Dell and HP are offering serial port consoles as a feature on their higher-end machines—but this is a special feature you must search for. (The HP RILOE serial console support even lets you control power over the serial console, which is very nice.)

    If your machine doesn’t have a serial console, nothing any operating system can do will give you access to the PC-style BIOS messages across the serial port.

Boot messages all appear before the operating system starts and even before the hard drive is accessed.

Fortunately, hardware exists to work around this. The best I’ve seen is the PC Weasel. It’s a video card with a serial port instead of a video port. The PC Weasel lets you access the BIOS, interrupt the boot to come up in single-user mode, and in general do whatever you like with the system as if you were at the console.

Hardware serial consoles do not require any operating system support.

Software Serial Consoles

If you don’t need early access to the BIOS messages but only to the boot loader, FreeBSD’s software serial console will suffice. As FreeBSD boots, the loader decides where to print console messages and from where to accept input. While this defaults to the monitor and keyboard, with a few tweaks you can redirect the console to a serial port. You cannot access the BIOS, but this serial console gives you the ability to tweak your boot in almost any way.

FreeBSD lets you set the console in two different places.

    For production systems, it’s best to set the console in the file /boot/config. This gives you access to the first stage of the boot process. You have three choices:

1. Use the standard keyboard/video/mouse as a console
2. use a serial port as a console, or 
3. use a dual console

The standard console is the default, so choosing this setup requires no action.

To force FreeBSD to use a serial console, enter -h all by itself in /boot/config.

Dual consoles let you use either the standard or the serial console as needed. You must pick one console to be the primary console, however.

    There are certain low-level tasks, such as booting from an alternate loader or

breaking into the debugger, which you can only perform from the primary console, but otherwise the consoles are functionally identical.

• Enter -D in /boot/config to enable a dual console with the standard console as primary.
• Enter -Dh in /boot/config to enable a dual console with the serial console as primary. I recommend using a dual console.

You can also control consoles from /boot/loader.conf. These entries take effect slightly later in the boot process, during the final stage of the kernel  bootstrapping process. To use the serial console exclusively, add this entry to /boot/loader.conf:

console="comconsole"

To switch back to the default video console, remove this line or comment it out. You can also set the keyboard and video console in /boot/loader.conf explicitly with this line:

console="vidconsole"

You can specify a dual console configuration by listing both comconsole and vidconsole, with the preferred console first. Here, we prefer the serial console:

console="comconsole vidconsole"

If you’re in a server-room situation, you might want to switch back and forth between a standard console and a serial console. I generally manage large arrays of FreeBSD systems via the serial console.

KEYBOARD  AUTODETECTION

In some FreeBSD documentation found on the Web, you’ll see references to using keyboard autodetection to choose a console. The idea is that you want to use the serial console unless you have a keyboard plugged in. This worked just fine in the days of AT and PS/2 keyboards, but autodetection of USB keyboards is prone to failure. You’re better off choosing a dual-console configuration rather than relying on keyboard autodetection.

Serial Console Physical Setup

No matter what sort of serial console you have, you’ll need to plug into it correctly to make it work. You’ll need a null modem cable. While the gold-plated serial cables are not worth the money, don’t buy the cheapest model you can find either; if you have an emergency and need the serial console, you’re probably not in the mood to deal with line noise!

    Plug one end of the null modem cable into the serial console port on your FreeBSD server—by default the first serial port (COM1 or sio0, depending on what operating system you’re used to). You can change this with a kernel recompile, but it’s generally simplest to just use the default on a server.

    Plug the other end of your null modem cable into an open serial port on another system. I recommend either another FreeBSD (or other Unix) system or a terminal server, but you can use a Windows box if that’s all you have.

    If you have two FreeBSD machines at a remote location, make sure that they each have two serial ports. Get two null modem cables and plug the first serial port on each box into the second serial port of the other machine. That way, you can use each machine as the console client for the other.

    If you have three machines, daisy-chain them into a loop. By combining twos and threes, you can get serial consoles on any number of systems. I’ve worked data centers with 30 or 40 FreeBSD machines, where installing monitors was simply not practical, and we used serial consoles to great effect.

    Once you have a rack or two of servers, however, investing in a terminal server is a really good idea. You can find them cheaply on eBay.

    Another option is to use two DB9-to-RJ45 converters, one standard and one crossover. These allow you to run your console connections over a standard CAT5 cable. If you have a lights-out data center where human beings are not allowed, you can have your serial consoles come out near your desk, in your warm room, or anywhere else your standard Ethernet-style patch panels reach.

    Most modern data facilities are better equipped to handle Ethernet than serial cables.

 Serial Console Use

Now that you’re all set up, configure your client to access the serial console. The key to using a serial console is to remember the following settings:

• 9600 baud
• 8 bits
• no parity
• 1 stop bit

Enter these values into any terminal emulator on a client computer, and the serial console will “just work.” You can find terminal emulators for Microsoft platforms (HyperTerm being the most famous), Macintosh, and almost any other operating system.

    A few years ago, I frequently used a Palm handheld with a serial cable to access serial consoles.

FreeBSD accesses serial lines with tip(1), a program that allows you to connect to remote systems in a manner similar to telnet. 

To run tip, do this as root:

# tip portname

A port name is shorthand for specifying the serial port number and speed to be used on a serial port. The file /etc/remote contains a list of port names. Most of the entries in this file are relics of the eon when UUCP was the major data- transfer protocol and serial lines were the norm instead of the exception(before spam era!).  At the end of this file, you’ll see a few entries like:

# Finger friendly shortcuts
sio0|com1:dv=/dev/cuad0:br#9600:pa=none:
sio1|com2:dv=/dev/cuad1:br#9600:pa=none:
sio2|com3:dv=/dev/cuad2:br#9600:pa=none:
sio3|com4:dv=/dev/cuad3:br#9600:pa=none:
sio4|com5:dv=/dev/cuad4:br#9600:pa=none:
sio5|com6:dv=/dev/cuad5:br#9600:pa=none:
sio6|com7:dv=/dev/cuad6:br#9600:pa=none:
sio7|com8:dv=/dev/cuad7:br#9600:pa=none:

The sio entries are the standard Unix-type device names, while the com names were added for the convenience of people who grew up on x 86 hardware. Assume that you have two FreeBSD boxes wired back-to-back, with each one’s serial port 1 null-modemed into serial port 2. Both machines are configured to use a serial console. You’ll want to connect to your local serial port 2 to talk to the other system’s serial console:

# tip sio1
connected

You won’t see anything else, no matter what you type. If you log into the other system and reboot it, you’ll abruptly see action in your tip window:

Shutting down daemon processes:.
Stopping cron.
Shutting  down local daemons:.
Writing entropy file:.
Terminated
.
Waiting  (max 60 seconds) for system process 'vnlru' to stop...done
Waiting  (max 60 seconds) for system process 'bufdaemon' to stop...done
Waiting  (max 60 seconds) for system process 'syncer' to stop...
Syncing disks, vnodes remaining...1 0 0 done
All buffers synced.
Uptime: 1m1s
Shutting down ACPI
Rebooting...

There will be a long pause while the system runs its BIOS routines and hands control over to the serial console. Eventually you’ll see something like this:

/boot/kernel/kernel text=0x4a6324 data=0x84020+0x9908c
syms=[0x4+0x67220+0x4+0x7e178]
/boot/kernel/snd_via8233.ko text=0x3a14 data=0x328 
syms=[0x4+0xa10+0x4+0xac5]
loading required module 'sound'
/boot/kernel/sound.ko text=0x17974 data=0x37a8+0x10d8
syms=[0x4+0x3290+0x4+0x3d7d]
/boot/kernel/atapicam.ko text=0x2a30 data=0x1d8+0x4 
syms=[0x4+0x7b0+0x4+0x7d6]

This indicates that the loader initially found and read the kernel files before showing the loader menu. Congratulations! You’re using a serial console. Press the spacebar to interrupt the boot just as if you were at the keyboard. It doesn’t matter how far away the system is; you can change your booting kernel, get a verbose boot, bring it up in single-user mode, or manually fsck the hard drive—whatever. A software serial console might not show you the BIOS, but chances are that’s set up correctly already. Once you’ve used a serial console for a while, it won’t matter if the machine is on the other side of the world or the other side of the room; getting out of your chair just to access the console will feel like too  much work.

    If you allow the boot to continue, however, you’ll get to a point where the boot messages stop and the serial console freezes. This is because it’s a console; it’s not a logon device. (Being able to log onto a machine via the serial console is quite useful on occasion)

    If a system in a remote location entirely locks up, you can connect to your

serial console and have the “remote hands” at the colocation facility power-cycle the system. It might not be good for your computer, but it’s also not good for it to be locked up. With the serial console, you can boot into single-user mode and fix the problem by digging through the logs and whatever other troubleshooting you feel capable of.

Serial Console Disconnection

The tip(1) program uses the tilde (~) as a control character. To disconnect the serial console, press ENTER and then type the disconnect sequence “tilde-dot” at any time:

~.

You’ll be gracefully disconnected.

Reboot

Once more, this time with feeling! Of these options, the most important are single-user mode and the loader prompt.

1. In FreeBSD, you can boot the system into a single-user mode for performing intrusive administrative duties, or you can manually load kernel modules (such as the IPFW firewall, the Linux compatibility module, or various external filesystem types) to enhance its capabilities. In the simplest and most common case, you will simply press Enter(multiuser mode) during the 10-second countdown that the loader gives you, or you can wait until it expires.
2. The kernel will then load, completing the bootstrap process.

The Kernel(Startup Messages)

The standard kernel is normally located at /boot/kernel and is started by the loader. As mentioned before, the kernel is the core of the operating system. It controls all access to hardware resources from both programs and users. Most of the lines that you see on the screen at this point are shown in bold white text (These are status messages that the kernel emits for your information as it finds and initializes your hardware), instead of the dimmer light-gray style of the normal screen text(init messages).

    Most of these messages(These messages are important when you first install

your system or when you do troubleshooting. The boot messages always start

off the same way, with a statement listing the copyrights for the FreeBSD

Project and the Regents of the University of California) will go by too fast for you to read, but after you log in to the system, you can use the command dmesg | more(or better less) to view them one screen at a time, using the spacebar to advance to the next screen. You may be interested in the kernel startup messages for a variety of reasons (for instance, to troubleshoot misbehaving hardware or to determine what device name FreeBSD has assigned to a particular component).

    Let's look at some sample messages from the kernel. This first example gives you an idea of the kind of messages you will see and what they mean (note that your messages might be different, depending on the type of hardware in your system):

Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.

FreeBSD 6.1-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005
root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC

1. The first three lines are simply copyright information.
   
2. Line 4 gives the operating system version and the version of the kernel (the kernel version number ---#0 here--- will increase by one each time you rebuild the kernel). It also tells the date and time the kernel was built.
3. The first part of line 5 gives the username and local email address of the person who built the kernel. If you build a lot of kernels, this information can be invaluable when trying to identify exactly what system features are available. In this case, the GENERIC kernel was built by root@x64.samsco.home (an internal FreeBSD development address), and that kernel was then copied to the system during installation. If you compile your own kernel, the line shown here will reflect your own email address and your machine's hostname.
   
4. The second part of line 5 tells where the directory is that this kernel was built in. (For you C-programming gurus, this is where you will find some of the C source files, the header files, and the object files that this kernel was built from as well as the makefile for the kernel)
   

The message shown below means that I have debugging and fault-identifying code enabled in this particular kernel, and my performance will suffer as a result. In this case I don’t care about the performance impact, for reasons which will become clear momentarily.

WARNING: WITNESS option enabled, expect reduced performance.

In the next message,in the first line the system identifies a particular piece of hardware. The timecounter, or hardware clock, is a special piece of hardware, and while your computer needs one, it’s such a low-level device that the end user really can’t do much with it directly. Now and then, you’ll see messages like this for hardware that isn’t directly visible to the user but is vital to the system. FreeBSD errs on the side of printing too much information, rather than obscuring details that might be critical. For example, it’ll also show all the information it can about the CPU in the system. You probably didn’t know that a simple CPU could have so many details and features, did you? Here’s why I’m not worried about the performance hit caused by the WITNESS option shown earlier: This box has a dual-core processor , each core is pretty darn fast and supports a whole bunch of features important to modern CPUs as well as a few AMD-specific features. I have CPU power to spare and a fair amount of memory as well in the system(The real memory is the amount of RAM physically installed in the computer, while the avail memory is the amount of memory for real work, left over after the kernel is loaded):

Timecounter "i8254" frequency 1193182 Hz quality 0 
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ ( 2200.10-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x20fb1 Stepping = 1
Features=0x178bfbff
Features2=0x1
AMD Features=0xe2500800
AMD Features2=0x3
Cores per package: 2
real memory  = 402653184000 (3840 MB)
avail memory = 384602112000 (3660 MB)

Tip The kernel information echoed to the screen during bootup, beginning with the FreeBSD copyright messages and the kernel's compilation environment, is available at any time by typing:

$ cat /var/run/dmesg.boot

This is very convenient if you have to diagnose hardware problems or determine the device names assigned to hardware FreeBSD has detected. The dmesg command, mentioned earlier, shows the current contents of the kernel message buffer, which can get overwritten by more recent messages if the system has been running for a long time.

Following this output is a long series of devices that FreeBSD has identified and how it’s going to handle that hardware. For example, in the snippet below, the kernel announces that it’s found both cores of the CPU and is ready to manage them:

FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs 

Here’s a fairly typical device driver entry. This device is known as ioapic, and the kernel has found that this hardware is version 0.3 and has extra information associated with it(irqs 0-23 on motherboard). What’s more, we’ve found two devices of that type, numbered 0 and 1 . (All device drivers are numbered starting with zero.) You can find out more about the device handled by a given driver by reading the manual page for the driver. Almost all—but not all—device drivers have manual pages.

ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard

These messages will vary according to the hardware in your system. One typical system begins its device configuration by listing

• the motherboard, 
• PCI and AGP bus controllers, 
• ATA controllers, 
• USB hubs, and 
• Ethernet cards (pay attention to the driver name FreeBSD assigns to the Ethernet card, fxp0 or le0  it's particularly important):

npx0: [FAST]  
npx0:  on motherboard
npx0: INT 16 interface
cpu0 on motherboard
pcib0:  pcibus 0 on motherboard
pir0:  on motherboard
pci0:  on pcib0
agp0:  mem 0xe0000000-0xe3ffffff at device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
$PIR: ROUTE_INTERRUPT failed.
pci1:  at device 0.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 ,0xf000-0xf00f at device 7.1 on pci0
ata0:  on atapci0
ata1:  on atapci0
uhci0:  port 0xe000-0xe01f irq 10 at device 7.2 on pci0
uhci0: [GIANT-LOCKED]
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
pci0:  at device 7.3 (no driver attached)
fxp0:  port 0xe400-0xe41f mem 0xe9200000-0xe9200fff,
0xe9100000-0xe91fffff irq 9 at device 11.0 on pci0
miibus0:  on fxp0
inphy0:  on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:a0:c9:66:7b:32

Not all device drivers print all their information on a single line. 

Here we have a single device, npx0, that takes up three lines with just a single instance of the device. The only way to know that this is a single math processor rather than three separate ones is to check the number of the device. All of these are for device number zero, so it’s a single device.

One interesting thing about the boot messages is that they display how your computer’s components are attached to one another. Here, we have an ACPI system directly on the motherboard and a PCI bridge attached to acpi0 . We also find a PCI bus attached to the PCI bridge , and as you read on, you’ll find individual devices attached to that bus. You might not be equipped to do much with this information now, but you’ll find that having it available will be valuable when you have to troubleshoot a problem. 

acpi0: on motherboard
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0

 This system has FireWire , and FreeBSD can identify and use it! Now that’s useful, at least if you have FireWire equipment. And FreeBSD can do Ethernet over FireWire ? That’s kind of cool. Even if you don’t have FireWire, chances are you have a network connection of some sort (FreeBSD’s default Ethernet-over-FireWire driver uses a method only supported by FreeBSD, mainly because we were here first. To use the Ethernet over FireWire compatible with Mac OS X and Windows XP, look at fwip(4)).

firewire0:  on fwohci0
fwe0:  on firewire0

This entry shows that a network card is assigned to the interface re0 , and that the card speaks gigabit Ethernet . We also see all sorts of information about its memory address, IRQ, and its PCI bus attachment.

re0: realtek 8169sb="" ethernet="" gigabit="" single-chip="" port 0x1000-0x10ff mem 0xd2206800-0xd22068ff irq 19 at device 8.0 on pci0 realtek

Here, the kernel has found the mouse and has detected that it is a PS/2-type mouse. It has assigned the device psm0 to refer to this mouse for future reference. The kernel has also found the floppy controller and the floppy drive. fdc0 is the device name of the floppy controller, and fd0 is the device name of the floppy drive itself. (fd0 is analogous to A: in Windows/DOS. It is the device name you use when you want to access this device):

psm0:  <PS/2 mouse> irq 12 on atkbdc0  psm0: [GIANT-LOCKED] 
psm0: [ITHREAD]
psm0: model Intellimouse Explorer, device ID 4
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: [FAST]
fd0: <1440-kb> on fdc0 drive 0

The next message shows that the kernel has found the SoundBlaster AWE 64 sound card(Note that in this case, sbc0 is actually the name for a group of devices related to the sound card. The sound card uses several devices, depending on what features you want to access, including dsp, which is where output such as WAV and MP3 files go, and mixer, which controls the levels of various audio devices) and it gives information about the resources the card is using:

sbc0:  at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
pcm1: on sbc0

You may also see some of the following lines on your startup message. These lines indicate that the kernel has found some "Plug and Play" (often abbreviated to PnP) devices in the system, but it doesn't know anything about them, and it can't assign resources for them. These messages are harmless. If you don't like seeing them, then note that, as the FreeBSD FAQ says, "the FreeBSD project will happily accept driver contributions via send-pr." (This is a not-so-subtle exhortation for you C gurus who are good at writing device drivers to contribute to the FreeBSD project in the spirit of the Open Source movement):

unknown:  can't assign resources (port)
unknown:  can't assign resources (memory)
unknown:  can't assign resources (port)
unknown:  can't assign resources (irq)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)

The next message shows that the kernel has found the hard drives and CD-ROM drive; it provides various information about each drive, including the device name, size, manufacturer and model, geometry, and what controller the drive is located on. It also tells what access mode the drive is using. In this case, both of the hard drives and the CD-ROM are using Ultra DMA 33. :

ad0: 19473MB  [39566/16/63] at ata0-master UDMA33
ad1: 14664MB  [29795/16/63] at ata1-master UDMA33
acd0: CDROM  at ata1-slave UDMA33

Every device on your computer has one or more entries like the above. Taken as a whole, they describe your computer’s hardware in reasonable detail. If you boot in verbose mode, you’ll see even more detail—probably far more than you want.

The final message shows that the kernel has mounted the root filesystem. The fact that the system is running indicates that it was successful.:

Trying to mount root from ufs:/dev/ad0s1a

 One key thing that the kernel displays in the boot messages is the device name for each piece of hardware. This is critical information for managing your system. Every piece of hardware has a device node name, and to configure it, you’ll need to know that name. For example, earlier we saw an entry for an Ethernet card called re0. The card uses the re(4) driver, and the first instance of this driver has number zero. Your second card of this type would be re1, then re2, and so on.
    Most devices that can be configured or managed have a device node entry somewhere under /dev. For example, our network card is represented by the file /dev/net/re0. These files are called device nodes, and are a convenient way to address a particular piece of hardware. Most device nodes cannot be directly accessed as a regular file; you can’t cat(1) a device node or copy another file to it. However, device nodes are used as arguments to specialized programs. For example, the hard drive that showed up at boot as ad4 is the same as the device node /dev/ad4. When you want to mount that hard drive, you can use the device node name and be sure you’re getting that exact piece of hardware.

Multi-User Startup --Boot FreeBSD [default]--

Beyond single-user mode you’ll find multi-user mode. This is the standard operating mode for a Unix-like OS. If you’re doing real work, your system is in multi-user mode.

    When FreeBSD finishes inspecting the hardware and attaching all the device drivers appropriately, it runs the shell script /etc/rc. This script mounts all filesystems, brings up the network interfaces, configures device nodes, identifies available shared libraries, and does all the other work necessary to make a system ready for normal work. Most systems have different startup requirements; while almost every server needs to mount a hard drive, a web server’s operating requirements are very different from those of a database server even if it’s running on absolutely identical hardware.

    This means that /etc/rc must be extremely flexible. It achieves this flexibility by delegating everything to other shell scripts responsible for specific aspects of the system.

    The /etc/rc script is controlled by the files /etc/defaults/rc.conf and /etc/rc.conf.

/etc/rc.conf and /etc/defaults/rc.conf

Much like the loader configuration file, the configuration of /etc/rc is split between two files: the default setting file /etc/defaults/rc.conf and the local settings file /etc/rc.conf. Settings in /etc/rc.conf override any values given in /etc/defaults/rc.conf, exactly as with the loader.

    The /etc/defaults/rc.conf file is huge and contains quite a few variables, frequently called knobs or tunables. We aren’t going to discuss all of them, not only because knobs are added continually and such a list would be immediately obsolete, but because quite a few knobs aren’t commonly used on servers. Almost everything in a standard FreeBSD system has one or more rc.conf knobs, from your keyboard map to TCP/IP behavior. For a complete, up-to-date list, read the rc.conf(5) manual page on your system. In the next few sections, we’ll examine some common entries from /etc/rc.conf. Each of these appears in /etc/defaults/rc.conf and can be edited by placing an override in /etc/rc.conf. Each variable appears with its default setting.

Startup Options

The following rc.conf options control how FreeBSD configures itself and starts other programs. These far-reaching settings affect how all other system programs and services run.

    If you’re having a problem with the startup scripts themselves, you might enable debugging on /etc/rc and its subordinate scripts. This can provide additional information about why a script is or isn’t starting.

rc_debug="NO"

If you don’t need the full debugging output, but would like some additional information about the /etc/rc process, enable informational messages with rc_info:

rc_info="NO"

One common problem with systems that have little memory is a shortage of swap space. You can configure a file for use as additional swap immediately at system boot:

swapfile="NO"

Filesystem Options

FreeBSD can use memory as a filesystem. One common use for this feature is to make /tmp really fast by using memory rather than a hard drive as its back end. rc.conf has variables to let you enable a memory-backed /tmp and set its size transparently and painlessly. You can also choose the options FreeBSD will use to complete the filesystem. (The impatient among you are probably wondering what the flag -S means. It means disable soft updates). If you want to use a memory filesystem /tmp, set tmpmfs to YES and set tmpsize to the desired size of your /tmp:

tmpmfs="AUTO"
tmpsize="20m"
tmpmfs_flags="-S"

Another popular FreeBSD filesystem feature is its integrated encrypted partitions. FreeBSD supports two different filesystem encryption systems out of the box: GBDE and GELI.

    Geom Based Disk Encryption (GBDE) was FreeBSD’s  first encrypted filesystem designed for military-grade use. GELI is a little more friendly and complies with different standards than GBDE.

gbde_autoattach_all="NO"
gbde_devices="NO"
gbde_attach_attempts="3"
gbde_lockdir="/etc"
geli_devices=""
geli_tries=""
geli_default_flags=""
geli_autodetach="YES"
geli_swap_flags="-a aes -l 256 -s 4096 -d"

By default, FreeBSD mounts the root partition read/write upon achieving multi-user mode. If you want to run in read-only mode instead, you can set the following variable to NO. Many people consider this more secure, but it might interfere with operation of certain software, and it will certainly prevent you from editing any files on the root partition!

root_rw_mount="YES"

When a booting FreeBSD attempts to mount its filesystems, it checks them for internal consistency. If the kernel finds major filesystem problems, it can try to fix them automatically with fsck -y. While this is necessary in certain situations, it’s not entirely safe.

fsck_y_enable="NO"

The kernel might also find minor filesystem problems which it resolves on-the-fly using a background fsck while the system is running in multi-user mode. There are legitimate concerns about the safety of using this feature in certain circumstances. You can control the use of background fsck and set how long the system will wait before beginning the background fsck.

background_fsck="YES"
background_fsck_delay="60"

Miscellaneous Network Daemons

FreeBSD includes many smaller programs (or daemons) that run in the background to provide specific services. We’ll cover quite a few of these integrated services throughout the book, but here are a few specific ones that will be of interest to experienced system administrators. One popular daemon is syslogd(8). Logs are a Good Thing.

syslogd_enable="YES"

Once you have decided to run the logging daemon, you can choose exactly how it will run by setting command-line flags for it. FreeBSD will use these flags when starting the daemon. For all the programs included in rc.conf that can take command-line flags, these flags are given in this format.

syslogd_flags="-s"

Another popular daemon is inetd(8), the server for small network services.

inetd_enable="NO"

One job commonly run with FreeBSD is Domain Name System, or DNS,

with the industry-standard daemon named(8). DNS is the road map of the Internet and makes it possible for mere humans to use the network.

Because DNS must be configured in order to be useful, FreeBSD ships with it disabled by default: named_enable="NO"

Most facilities use the Secure Shell (SSH) daemon for remote logins. If you want to connect to your system remotely over the network, you’ll almost certainly need SSH services.

sshd_enable="NO"

While the SSH daemon can be configured via the command line, you’re generally be better off using the configuration files in /etc/ssh/.

sshd_flags=""

FreeBSD also incorporates extensive time-keeping software and functions to ensure that the system clock remains synchronized with the rest of the world. You’ll need to configure this for it to be useful;

ntpd_enable="NO"
ntpd_flags="-p /var/run/ntpd.pid -f /var/db/ntpd.drift"

FreeBSD also includes a small SNMP daemon for use in facilities with SNMP-based management tools.

bsnmpd_enable="NO"

Network Options

These knobs control how FreeBSD configures its network facilities during boot.

Every machine on the Internet needs a hostname. The hostname is the fully qualified domain name of the system, such as www.absolutefreebsd.org. Many programs will not run properly without this.

hostname=""

FreeBSD includes a few different integrated firewall packages. PF, the Packet Filter, can enabled and disabled in rc.conf.

pf_enable="NO"

TCP/IP is an old networking protocol and has been extended and modified several times. Some of these modifications have been lumped together as TCP extensions. Most operating systems can take advantage of TCP extensions, but many older ones can’t. If you have trouble communicating with much older hosts, disable TCP extensions.

tcp_extensions="YES"

You might be interested in failed attempts to connect to your system over the network. This will help detect port scans and network intrusion attempts, but will also collect a lot of garbage. It’s interesting to set this for a short period of time just to see what really happens on your network. (Then again, knowing what’s really going on tends to cause heartburn.) Set this to 1 to log failed connection attempts.

log_in_vain="0"

Routers use ICMP redirects to inform client machines of the proper network gateways for particular routes. While this is completely legitimate, on some networks intruders can use this to capture data. If you don’t need ICMP redirects on your network, you can set this option for an extremely tiny measure of added security. If you’re not sure if you’re using them, ask your network administrator.

icmp_drop_redirect="NO"

If you are the network administrator and you’re not sure if your network uses ICMP redirects, there’s an easy way to find out—just log all redirects received by your system to /var/log/messages.(get a copy of The TCP/IP Guide by Charles M. Kozierok (No Starch Press, 2005))

    Note that if your server is under attack, this can fill your hard drive with redirect logs fairly quickly.

icmp_log_redirect="NO"

To get on the network, you’ll need to assign each interface an IP address.  You can get a list of your network interfaces with the ifconfig(8) command. List each network interface on its own line, with its network configuration information in quotes. For example, to give your em0 network card an IP address of 172.18.11.3 and a netmask of255.255.254.0, you would use:

ifconfig_em0="inet 172.18.11.3 netmask 255.255.254.0"

If your network uses DHCP, use the value dhcp as an IP address.

ifconfig_em0="dhcp"

Similarly, you can assign aliases to a network card. An alias is not the card’s actual IP address, but the card answers for that IP address. FreeBSD supports hundreds of aliases on a single card, with rc.conf entries in the following form:

ifconfig_em0_aliasnumber="address netmask 255.255.255.255"

The alias numbers must be continuous, starting with 0. If there’s a break in numbering, aliases above the break will not be installed at boot time. (This is a common problem, and when you see it, check your list of aliases.) For example, an alias of 192.168.3.4 would be listed as:

ifconfig_em0_alias0="192.168.3.4 netmask 255.255.255.255"

Network Routing Options

FreeBSD’s network stack includes many features for routing Internet traffic. These start with the very basic, such as configuring an IP for your default gateway. While an IP address will get you on the network, a default router will give you access to everything beyond your LAN.

defaultrouter=""

Network control devices such as firewalls must pass traffic between different interfaces. While FreeBSD won’t do this by default, it’s simple to enable. Just tell the system that it’s a gateway and it will connect multiple networks for you.

gateway_enable="NO"

If your system needs to speak Routing Information Protocol(RIP), use the router_enable knob to start it at boot. I would argue that this knob is misnamed—many routers use routing protocols other than RIP, but the knob has had this name for decades now. If you don’t specifically need the RIP protocol, then leave this knob alone!

router_enable="NO"

Console Options

The console options control how the monitor and keyboard behave. You can change the language of your keyboard, the monitor’s font size, or just about anything else you like. For example, the keyboard map defaults to the standard US keyboard, frequently called QWERTY. You’ll find all sorts of keymaps in the directory /usr/share/syscons/keymaps. I prefer the Dvorak keyboard layout, which has an entry there as us.dvorak. By changing the keymap knob to us.dvorak, my system will use a Dvorak keyboard once it boots to multi-user mode.

keymap="NO"

FreeBSD turns the monitor dark when the keyboard has been idle for a time specified in the blanktime knob. If you set this to NO, FreeBSD will not dim the screen. Mind you, new hardware will dim the monitor after some time as well, to conserve power. If your screen goes blank even if you’ve set the blanktime knob to NO, check your BIOS and your monitor manual.

blanktime="300"

FreeBSD can also use a variety of fonts on the console. While the default font is fine for servers, you might want a different font on your desktop or laptop. My laptop has one of those 17-inch screens proportioned for watching movies, and the default fonts look kind of silly at that size. You can choose a new font from the directory /usr/share/syscons/fonts. Try a few to see how they look on your systems. The font’s name includes the size, so you can set the appropriate variable. For example, the font swiss-8x8.fnt is the Swiss font, 8 pixels by 8 pixels. To use it, you would set the font8x8 knob.

font8x16="NO"
font8x14="NO"
font8x8="NO"

You can use a mouse on the console, even without a GUI. By default, FreeBSD will try to autodetect your mouse type. If you have a PS/2 or USB mouse, chances are that it will just work when you enable the mouse daemon, without any special configuration. Some older and more unusual types of mice require manual configuration, as documented in moused(8).

moused_enable="NO"
moused_type="AUTO"

You can also change the display on your monitor to fit your needs. If you have an odd-sized monitor, you can change the number of lines of text and their length to fit, change text colors, change your cursor and cursor behavior, and do all sorts of other little tweaks. You can get a full list of different options in man vidcontrol(8).

allscreens_flags=""

Similarly, you can adjust your keyboard behavior almost arbitrarily. Everything from key repeat speed to the effect of function keys can be configured, as documented in kbdcontrol(8).

allscreens_kbdflags=""

Other Options

This final potpourri of knobs might or might not be useful in any given environment, but they are needed frequently enough to deserve mention. For example, not all systems have access to a printer, but those that do will want to run the printing daemon lpd(8).

ldp_enable="NO"

The sendmail(8) daemon manages transmission and receipt of email between systems. While almost all systems need to transmit email, most FreeBSD machines don’t need to receive email. The sendmail_enable knob specifically handles incoming mail, while sendmail_outbound_enable allows the machine to transmit mail.

sendmail_enable="NO"
sendmail_outbound_enable="YES"

One of FreeBSD’s more interesting features is its ability to run software built for other operating systems. The most common compatibility mode is for Linux software, but FreeBSD also supports SCO Unix binaries and SVR4 software.  Don’t enable any of these compatibility modes without know what you're doing

linux_enable="NO"

A vital part of any Unix-like operating system is shared libraries. You can control where FreeBSD looks for shared libraries. Although the default setting is usually adequate, if you find yourself regularly setting the LD_LIBRARY_PATH environment variable for your users, you should consider adjusting the library path instead.

ldconfig_paths="/usr/lib /usr/X11R6/lib /usr/local/lib"

FreeBSD has a security profile system that allows the administrator to control basic system features. You can globally disallow mounting hard disks, accessing particular TCP/IP ports, and even changing files.

kern_securelevel_enable="NO"
kern_securelevel="-1"

Now that you know a smattering of the configuration knobs FreeBSD supports out of the box, let’s see how they’re used.

The rc.d Startup System

FreeBSD bridges the gap between single-user mode and multi-user mode via the shell script /etc/rc. This script reads in the configuration files /etc/defaults/rc.conf and /etc/rc.conf and runs a collection of other scripts based on what it finds there. For example, if you have enabled the USB daemon, /etc/rc runs a script written specifically for starting that daemon.

    FreeBSD includes scripts for starting services, mounting disks, configuring

the network, and setting security parameters. You can use these scripts to stop and restart services exactly as the system does at boot, ensuring system integrity and making your life generally easier. These scripts live in /etc/rc.d.

WHAT IS rcNG?

Once upon a time, FreeBSD included a handful of monolithic /etc/rc scripts that configured the entire system. Each specific daemon or service was started by a few lines buried inside one of these scripts. While this worked well for the majority of systems, it wasn’t very flexible and couldn’t accommodate all users. NetBSD developed the current system of small shell scripts for specific services, and FreeBSD quickly adopted it. The current startup method is the next generation RC scripts, or rcNG. This system is currently the only one used in any production version of FreeBSD, and any references you may see to rcNG are leftovers from the transition era.

Once you have a feature enabled in rc.conf, you can control it via an rc.d

script. For example, suppose you realized you had to run the SSH daemon on a system that previously hadn’t run it. Set sshd_enable to YES, and go to the directory /etc/rc.d. There you’ll find a script called sshd.

#./sshd start
Starting sshd

• No rc.d script runs unless enabled in rc.conf, however. This ensures that everything that was running before will still be running after a reboot. 
• You can also stop a service with the stop command, 
• check its state with the status command, and 
• reload it with restart. 
• If you really do want to start a program just once with its rc.d script, and you don’t want it to run after the next reboot, you can use the forcestart command.

Shutdown

FreeBSD makes the rc.d startup system do double duty; not only must it handle system startup, it must shut all those programs down when it’s time to power down.

    Something has to unmount all those hard drives, shut down the daemons, and clean up after doing all the work. Some programs don’t care if they’re  unceremoniously killed when the system closes up for the night —after all, after the system goes down any clients connected over SSH will be knocked off and  any web pages that are being requested aren’t going to be delivered. Database software, however, cares very much about how it’s turned off, and just killing the process will damage your data. Many other programs that manage actual data are just as particular, and if you don’t let them clean up after themselves you will regret it.

    When you shut down FreeBSD with either the shutdown(8) or reboot(8) commands, the system calls the shell script /etc/rc.shutdown. This script calls each rc.d script in turn with the stop option, reversing the order they were called during startup, thereby allowing server programs to terminate gracefully and disks to tidy themselves up before the power dies.

After the root filesystem is mounted, the kernel passes control to a process called init. The messages in light gray are triggered by events that occur during the init stage. You can differentiate kernel messages from non-kernel messages by color. Kernel messages appear in white; non-kernel messages appear in light gray. 

 init The init program is the first actual process that runs under the operating system, and as such its process ID is 1. init is responsible for starting up all the rest of the processes that constitute a completely functional operating system; to do that, though, it must first determine whether the disks are in suitable shape. When a FreeBSD system is properly shut down, it runs a program called sync on each disk to ensure that all data is written out, dismounts the filesystems, and then sets the "clean" flag on the filesystems. This is similar to the process that Windows goes through when it shuts down. If a FreeBSD system is not properly shut down, the clean flag will not be set.

Filesystem Consistency Check

1. One of the first things that init does is to check whether the clean flag is set. If it is, init mounts the filesystem for use.
   
2. If it isn't, init first runs the fsck (If you need to, you can also run fsck manually) program on the filesystem to make sure it isn't damaged. This program repairs any damage it finds that it knows how to repair. fsck is similar to the Scandisk program in Windows, and this process is similar to the "Your system was not properly shut down" procedure you see on a Windows reboot following an improper shutdown.
   
3. If fsck encounters an error it cannot fix at this point, it drops the system into single-user mode so the system administrator (which is probably you) can make the necessary repairs manually.
   
4. Assuming that the clean flag was set, or that fsck was able to repair the damage if the flag was not set, init then proceeds to mount each filesystem listed in the /etc/fstab file that has the mount at boot flag set.

System Configuration Scripts

1. After the filesystems are mounted,
   
2. init reads the system-configuration scripts (known alternately as Run Control or Resource Configuration scripts, abbreviated to rc scripts) located in /etc and /etc/defaults.
   
3. In addition, init checks the /usr/local/etc/rc.d directory for any additional scripts it should run at boot (these might be scripts to start web servers, database servers, or any other program you want to run automatically at startup). If you are familiar with Windows or DOS, this part of the boot process is similar to config.sys, autoexec.bat, system.ini, and the parts of the Windows Registry that control Windows startup options. 

Note The term rc scripts actually originates from RunCom, or "run commands," a facility from the CTSS system at MIT, circa 1965. While the acronym rc has been reassigned to numerous different meanings since then, its general application remains the same: a set of commands stored in a file and run in a batch. In typical UNIX parlance, the meaning of rc by itself is clear enough that it is unnecessary to know what it stands for, and most people don't. It simply means "a script associated with a certain daemon or subsystem, which executes when the daemon or subsystem is launched and sets up its runtime configuration." Here we'll refer to Run Control for Sun-style run levels and Resource Configuration when it comes to FreeBSD's own startup scripts.

Note For the sake of completeness, it should be mentioned that init also checks for and reads a file called /etc/rc.local, which can be used to start programs such as web servers. However, this file is deprecated and may not be supported in future versions of FreeBSD. Therefore, it is recommended that you put your startup scripts in the /usr/local/etc/rc.d directory, according to the best practices encouraged by FreeBSD's package management system, instead of in the /etc/rc.local file.