Understanding the FreeBSD Startup Process

FreeBSD's bootstrapping (startup) process is the means by which the system's kernel is first located within its BSD partition and slice on your hard disk, and then launched in the manner necessary to activate all your hardware devices and make the system available to users. Accomplishing all this is more difficult than it soundsit's far from a straightforward procedure. Because of the way that PC hardware works, with bootable hard drive partitions governed by the BIOS (Basic Input/Output System) software located on a chip on the motherboard, FreeBSD must launch itself in several stageseach stage having a very limited function and scope, and each executing one crucial step before passing off control to the next stage.

As you'll learn in Chapter 20, "Adding Hard Disk Storage," the hard disk is divided into partitions (which FreeBSD refers to as "slices"); the BIOS can only look for a Master Boot Record (MBR) in one of these partitions, rather than in the secondary partitioning scheme known as "BSD partitions" (where the FreeBSD kernel is located). The BIOS can't address the kernel directly and has no knowledge of how to launch it even if it couldthere are several levels of increasingly complex addressing schemes in between. This means that at each level of the architecture dictated by legacy PC hardware standards, there must exist a FreeBSD boot blocka small chunk of executable code that has the ability to look one level deeper into the boot process, understanding the architecture of the next stage and knowing how to launch the next boot block. This process continues stage by stage until the kernel is finally located and launched. Chances are that you won't ever need to know the details of how these boot stages work, but knowing them can't hurtespecially if you're trying to figure out why something went wrong!

When you first power on the machine, the first thing FreeBSD does is run the hardware checks and probes that are specified by the BIOS and the CMOS configuration. This part of the startup process depends entirely on your hardware configuration. In it, your RAM is checked, any SCSI controllers you might have installed are activated and tested, and you're given the opportunity to reconfigure your BIOS. This stage doesn't have anything to do with FreeBSDit occurs the same way whether you've got FreeBSD installed on your hard disk, Windows, or even no operating system at all.

Moving Through the Boot Process

After the BIOS prints a table showing the hardware data it has collected, it reads the Master Boot Record (MBR) of the primary disk for the first and most rudimentary boot block. It is the job of this and the next two boot blocks to find and run the loader, which configures and loads the kernel. Each boot block is sequentially a little more complex than the previous one. The first two are limited to 512 bytes in size (by the standardized sizes of the MBR and of the boot sector of a given slice), so they are both very simple. Here are each of the boot blocks and their functions:

• Boot block 0 (boot0)This preliminary boot block is what sits in the MBR, like LILO, and (if the FreeBSD boot manager is installed) lists the available slices (the F-key commands that follow) from which you can choose what you want to boot:

  F1 FreeBSD F2 Linux F3 ?? Default: F1

  You can press the appropriate F-key to select the slice you want or else just wait for several seconds, in which case boot block will choose the default selection and continue.

• Boot block 1 (boot1)This a very simple program that runs from the boot sector of the slice you selected in boot0, and its job is to use a stripped-down version of disklabel, the program that divides a slice up into BSD-style partitions (this functionality is covered thoroughly in Chapter 20) to find and run boot2 in the appropriate BSD partition. There is no user-interface portion to boot1.

• Boot block 2 (boot2)Finally, we reach a boot block that has enough elbow room to have the necessary complexity to read files on the bootable filesystem. In earlier versions of FreeBSD, this boot block used to provide a prompt so you could tell it where to load the kernel from, if not from the default location in the root partition. Now it automatically runs a program called the loader, which gives you control over the kernel's options through a full-screen textual menu.

• LoaderYou can find this program in the /boot directoryand that's where boot2 finds it, too. It reads the /boot/defaults/loader.conf and /boot/loader.conf configuration files and loads the kernel and modules specified there. (The /boot/loader.conf file contains the overrides to /boot/defaults/loader.conf, in a similar fashion to the way /etc/rc.conf works, which we cover later in this chapter.) Refer to Figure 4.1 in Chapter 4 to see the available menu options in the loader.

  The loader counts down 10 seconds while it waits for you to press a key and select a boot option; if you don't do anything, it boots the kernel in its default mode, with all drivers and functionality intact. Several other menu options are available, however, which allow you to control more precisely your kernel's boot behavior. You can boot in Safe Mode (with a limited kernel missing many potentially conflicting drivers) or single-user mode, using options in the menu itselfor, if you choose option 6, Escape to Loader Prompt, you can interact with the loader in a commandline environment that gives you still more flexibility. At the loader prompt you can boot a different version of the kernel, boot from CD-ROM or DVD, load and unload kernel modules manually, view the contents of files, or perform a number of other tasks (see man loader for details). Most of the time, you'll be booting your computer in its default configuration, so you don't even need to touch the computer at the loader stage; it will boot automatically without any user interaction. Suppose, however, that you want to load a certain kernel module (/boot/kernel/portal.ko) at boot time, rather than waiting until the system has completely booted. You also want to view the currently loaded kernel modules. You can perform these actions at the loader's ok command prompt, as follows:

  ok load portal.ko /modules/portal.ko text=0x1d18 data=0x1f4+0x4 syms=[0x4+0x8d0+0x4+0x6bf] ok lsmod  0x100000: kernel (elf kernel, 0x355be4)  0x455be4: /boot/kernel.conf (userconfig script, 0x4c)  0x456000: portal.ko (elf module, 0x3eb0)

  Typing ? at the ok prompt gives you a list of available commands. The two you just saw are load, which loads modules into the kernel, and lsmod, which lists the currently loaded modules. This command can be very useful during troubleshooting or if you use kernel modules that must be loaded in a specific order. For further details on the options available at the loader command line, consult man loader.

This concludes the boot block phase of the bootstrapping process. FreeBSD has successfully run each piece of code that leads along the path to the bootable kernel, and the final phase of the boot process is where the complete FreeBSD system starts to come into play. That's where the kernel loads itself into memory, probes its available devices, and runs the resource configuration scripts that construct a working environment and start up the various system services. The remaining steps are as follows:

1. After the loader transfers control to it, the kernel begins to probe all the devices it can find, and the results of each probe are echoed to the screen. This is the time when you will see many cryptic messages in bright white filling the screen. These lines are logged into the kernel message buffer, which you can read with the dmesg command if you need to see what the kernel had to say about a certain device.

2. After the kernel loads, it passes control to the init process, the final stage in the startup procedure. This is signaled by the Automatic reboot in progress message, which involves init running the global resource configuration script (/etc/rc). This script first uses the fsck program to check all the filesystem devices in /etc/fstab for consistency, as discussed in Chapter 12, "The FreeBSD Filesystem."

3. If fsck finds no problems it cannot correct on its own, it will mount all the filesystems (using mount -a -t nonfs) and continue running the rest of the startup processes. If fsck finds an unresolvable problem with the disks, it will exit to single-user mode for you to run fsck manually and repair the damage. (You will need to run /sbin/mount -a to mount your filesystems in read/write mode if you need to make changes to any files.) Exit the single-user shell to continue rebooting into multiuser mode.

Finally, if all goes according to plan, you get a login prompt, and the system is up and ready for use. This whole process usually takes no more than a minute.

Securing the Boot Process

Of concern to the security-conscious administrator is the fact that by default, if you choose to boot into single-user mode (option 4 in the loader menu, or boot -s at the loader command prompt), you are not prompted for a password, and the system comes up automatically with full root access. If you're sharing the machine with anyone else, such that this person can sit down in front of the machine and physically reboot it if he wants to, this constitutes a grave and gaping security hole.

Fortunately, it's easy to plug this hole. In /etc/ttys, which contains terminal settings for the various access methods (the console, virtual terminals, serial terminals, and network [pseudo] terminals), you can change the setting on the console line from secure to insecure:

console none                   unknown off insecure

This tells the system to treat the console as an insecure access point and to present a challenge (login prompt) to anyone who tries to boot into single-user mode. The root password is required in order to pass this challenge point.

Note

The console terminal method is only used in single-user mode. When you're booting into full multiuser mode, multiple virtual terminals are available at the physical terminal (you can switch between them with Alt+F1, Alt+F2, and so on). These terminals always present a login prompt. The secure and insecure settings in this case control whether you can log in as root or whether you're required to log in as a regular user and then use su to gain root access.

If others have access to the physical terminal (even if you've secured the single-user console), you have a second security hole to plug. This security weakness results from the fact that Ctrl+Alt+Delete causes the system to reboot, whether or not you're logged in as root, or even logged in at all. The three-finger-salute works even at the login prompt. Allowing this kind of access is appropriate in some situations (a rack-mounted server in a trusted machine room, for example), but not in others. To disable it, you'll need to add an option to your kernel configuration and rebuild the kernel:

options         SC_DISABLE_REBOOT

Other important considerations in securing your FreeBSD machine's operating environment are to make sure that it can't be booted from any device other than the primary hard drive (to protect against, for example, someone booting it from a CD-ROM or an external hard drive), and to protect the BIOS with a password. Of course, if unauthorized persons have physical access to the machine, you can't ever completely protect it; the best policy is to ensure that the operating environment is secured against all unauthorized access.

For a detailed discussion of kernel options and configuring your kernel, see Chapter 18, "Kernel Configuration."

What Can Slow Down the Boot Process?

You should allow about a minute after leaving the loader menu before you see the login prompt signaling the end of the boot process. There's usually no reason for it to take any longer than thisbut there's always the possibility that something is going wrong and needs to be corrected. Because of the scripted, serial nature of the boot process and the verbose console messages emitted during startup, it's fairly simple to see where it's hanging. Two common culprits are Sendmail and httpd (Apache); in both cases, the associated slowness results from a network connectivity problem or misconfiguration.

Both Sendmail and Apache have to figure out your machine's hostname. To do this, they need to perform a reverse lookup against the domain name server (DNS) configured in /etc/resolv.conf. (TCP/IP setup will be covered thoroughly in Chapter 23, "Configuring Basic Networking Services.") This lookup will have to time out for every configured name server before it fails and allows the startup process to proceed. Network timeouts are often fairly long, which is why networking is the most common cause of boot hang-ups. One solution to this problem is to make sure the name server listed first in /etc/resolv.conf is reachable from your FreeBSD machine. This ensures that Sendmail and Apache will be able to determine the machine's hostname and start up without delay. If this configuration is not possible, list 127.0.0.1 (localhost) as the first name server and disable the rest.

Incidentally, this potential slowdown is why init uses the nonfs mount type (mount -a -t nonfs) when doing its initial "preen" to see whether it can safely go into multiuser mode. NFS, the Network Filesystem, has an astonishingly long timeout period, and a process waiting for that timeout to elapse can be almost impossible to kill. The nonfs option on the mount command, which you learned about in Chapter 12, avoids mounting NFS resources until later, in the resource configuration phase, so that it can come up properly in multiuser mode without user intervention.

However, init does mount all filesystems later in /etc/rc, including NFS ones. Any NFS resources that you configured for automatic mounting in /etc/fstab (for example, without the noauto option) have the potential to freeze the system for a long time when the /etc/rc script reaches that point. Therefore, don't auto-mount NFS resources at boot unless you're sure they'll always be available to your machine on the network!