The FreeBSD Startup Process
| When you first start FreeBSD, it prints a flurry of messages on your screen from the kernel and also from the various processes starting up. We won't go into detail about what all these messages mean right now (a complete discussion of the FreeBSD startup procedure and how to control it can be found in Chapter 14, "System Configuration and Startup Scripts"), but the following sections give a quick rundown of what you will be seeing while you wait for the command prompt. 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 Power-On Self Test (POST) and BIOSThe first thing your computer does when you turn it on is run the POST, which stands for Power-On Self Test. During this phase, your computer's BIOS, which stands for Basic Input/Output System, checks out all its hardware and makes sure everything is working. The BIOS is a small piece of software on a ROM or EPROM chip on your computer's system board. Among other things, the BIOS is responsible for testing hardware when the computer is first turned on. The BIOS also finds and tests the first part of the operating system off the hard drive. 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. The BootstrapAfter the POST is complete, the BIOS searches for a device on your system that it can boot from. The system normally boots from the first bootable device it finds. 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, as will be discussed more fully in Chapter 14. 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 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 procedurea multistage process, comprising several "boot blocks" (small programs that pull successively larger and larger pieces of the operating system into memory), as will be discussed in more detail in Chapter 14. Selecting the Bootable Slice (boot0)After the BIOS finds a bootable hard disk, it reads whatever is in sector 0 of the hard disk. Sector 0 is also known as the master boot record (MBR). 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 fromand thus which operating system you want to start. (A slice is what other operating systems refer to as a partition or a BIOS partition, as we will discuss in Chapter 14.) 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. The Loader Menu and the KernelThe 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, which is covered in more detail in Chapter 14 along with fuller details on the disk partitioning structure that underlies the startup process, 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. One possible appearance of this menu screen is shown in Figure 4.1. Figure 4.1. The FreeBSD loader menu, presenting a list of boot modes to choose from. 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 during the 10-second countdown that the loader gives you, or you can wait until it expires. The kernel will then load, completing the bootstrap process. The KernelThe 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, instead of the dimmer light-gray style of the normal screen text. These are status messages that the kernel emits for your information as it finds and initializes your hardware. Most of these messages will go by too fast for you to read, but after you log in to the system, you can use the command dmesg | more 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 The first three lines are simply copyright information. Line 4 gives the operating system version and the version of the kernel (the kernel version number will increase by one each time you rebuild the kernel). It also tells the date and time the kernel was built. The first part of line 5 gives the username and local email address of the person who built the kernel. 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, which you will learn how to do in Chapter 18, "Kernel Configuration," the line shown here will reflect your own email address and your machine's hostname. 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 fromas well as the makefile for the kernel.) In the next message, the kernel has detected the CPU type and identified its on-board features; it reports them along with the amount of memory in the system:
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. These 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, fxp0it's particularly important):
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: psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 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.) The next message shows that the kernel has found the SoundBlaster AWE 64 sound card, and it gives information about the resources the card is using: sbc0: <Creative SB AWE64> at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm1: <SB16 DSP 4.16> on sbc0 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. You may also see some of the following lines on your startup message: unknown: <PNP0303> can't assign resources (port) unknown: <PNP0c01> can't assign resources (memory) unknown: <PNP0a03> can't assign resources (port) unknown: <PNP0f13> can't assign resources (irq) unknown: <PNP0501> can't assign resources (port) unknown: <PNP0700> can't assign resources (port) 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.) 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: ad0: 19473MB <Maxtor 92049U6> [39566/16/63] at ata0-master UDMA33 ad1: 14664MB <IBM-DJNA-351520> [29795/16/63] at ata1-master UDMA33 acd0: CDROM <ATAPI 44X CDROM/VER-3.40> at ata1-slave UDMA33 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. (This will be covered in more detail in Chapter 20, "Adding Hard Disk Storage.") The final message shows that the kernel has mounted the root filesystem: Trying to mount root from ufs:/dev/ad0s1a The fact that the system is running indicates that it was successful. 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. initThe 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 CheckOne 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. If it isn't, init first runs the fsck 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. 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, if you are reading this book) can make the necessary repairs manually. 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 (see "Understanding the /etc/fstab File" in Chapter 12, "The FreeBSD Filesystem"). Tip If you need to, you can also run fsck manually. More information on fsck and its various options can be found in Chapter 12. System Configuration ScriptsAfter the filesystems are mounted, 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. 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." This book will 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.
getty and loginAfter reading the resource configuration 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 Window system immediately after system boot (similar to an NT login session). The program that is started is defined in the file /etc/ttys. For the purposes of this discussion, we'll assume it's getty. The getty program initializes the terminal (or console), and it controls various security options and terminal-type options. Once again, these options and their values are defined in /etc/ttys. When you have entered your login name and password, the getty program starts the login program to validate them. |
,MMX,FXSR> real memory = 402653184 (384 MB) avail memory = 384602112 (366 MB)