UNIX System Administration Handbook - Evi Nemeth [19]
Steps in the boot process
A typical bootstrapping process consists of six distinct phases:
• Loading and initialization of the kernel
• Device detection and configuration
• Creation of spontaneous system processes
• Operator intervention (manual boot only)
• Execution of system startup scripts
• Multiuser operation
Administrators have little control over most of these steps. We effect most bootstrap configuration by editing the system startup scripts.
Kernel initialization
The UNIX kernel is itself a program, and the first bootstrapping task is to get this program into memory so that it can be executed. The pathname of the kernel is vendor dependent, but it has traditionally been something like /unix or /vmunix. These days, every vendor calls its kernel something different.
See Chapter 12 for more information about the kernel..
Most systems implement a two-stage loading process. During the first stage, the system’s ROM loads a small boot program into memory from disk. This program then arranges for the kernel to be loaded. This procedure occurs outside the domain of UNIX and so is not standardized among systems.
The kernel performs memory tests to find out how much RAM is available. Many of the kernel’s internal data structures are statically sized, so the kernel sets aside a fixed amount of real memory for itself when it starts. This memory is reserved for the kernel and cannot be used by user-level processes. On most systems, the kernel prints a message on the console that reports the total amount of physical memory and the amount available to user processes.
Hardware configuration
One of the kernel’s first chores is to check out the machine’s environment to see what hardware is present. When you construct a kernel for your system, you tell it what hardware devices it should expect to find; when the kernel begins to execute, it tries to locate and initialize each device that you have told it about. Most kernels print out a line of cryptic information about each device they find.
The device information provided at kernel configuration time is often underspecified. In these cases, the kernel tries to determine the other information it needs by probing the bus for devices and asking the appropriate drivers for information. The drivers for devices that are missing or that do not respond to a probe will be disabled. Even if a device is later connected to the system, it will not be accessible to UNIX processes until the machine has been rebooted.1
System processes
Once basic initialization is complete, the kernel creates several “spontaneous” processes in user space. They’re called spontaneous processes because they are not created by the normal UNIX fork mechanism; see page 47 for more details.
The number and nature of the spontaneous processes vary from system to system. On BSD systems, there are three:
• swapper – process 0
• init – process 1
• pagedaemon – process 2
The exact number of spontaneous processes varies on System V-ish machines:
• sched – process 0
• init – process 1
• Various memory and kernel process handlers
Under Linux, there is no visible PID 0. There are several handler processes in addition to init; the exact complement varies depending on the version of the kernel:
• init – process 1
• Various memory and kernel handlers (kflushd, kupdate, kpiod, kswapd)
Of all of these processes, only init is really a full-fledged user process. The others are actually portions of the kernel that have been dressed up to look like processes for scheduling or architectural reasons.
Once the spontaneous processes have been created, the kernel’s role in bootstrapping is complete. However, none of the processes