diff options
Diffstat (limited to 'man7/boot.7')
| -rw-r--r-- | man7/boot.7 | 194 |
1 files changed, 194 insertions, 0 deletions
diff --git a/man7/boot.7 b/man7/boot.7 new file mode 100644 index 000000000..d1341ef7f --- /dev/null +++ b/man7/boot.7 @@ -0,0 +1,194 @@ +.\" Written by Oron Peled <oron@actcom.co.il>. +.\" May be distributed subject to the GPL. +.\" +.\" I tried to be as much generic in the description as possible: +.\" - General boot sequence is applicable to almost any +.\" OS/Machine (DOS/PC, Linux/PC, Solaris/SPARC, CMS/S390) +.\" - kernel and init(8) is applicable to almost any Unix/Linux +.\" - boot scripts are applicable to SYSV-R4 based Unix/Linux +.TH BOOT 7 2002-06-07 "" "Linux Programmer's Manual" +.SH "NAME" +.LP +boot\-scripts \- General description of boot sequence +.SH "DESCRIPTION" +.LP +The boot sequence varies in details among systems +but can be roughly divided to the following steps: +(i) hardware boot, (ii) OS loader, +(iii) kernel startup, (iv) init and inittab, +(v) boot scripts. +We will describe each of these in more detail below. + +.SS "Hardware\-boot" +After power\-on or hard reset, control is given +to a program stored on read only memory (normally +PROM). In PC we usually call this program the +\fBBIOS\fR. + +This program normally makes a basic self\-test of the +machine and accesses non\-volatile memory to read +further parameters. This memory in the PC is +battery\-backed CMOS memory, so most people +refer to it as the \fBCMOS\fR, although outside +of the PC world, it is usually called \fBnvram\fR +(non\-volatile ram). + +The parameters stored in the nvram vary between +systems, but as a minimum, the hardware boot program +should know what is the boot device, or which devices +to probe as possible boot devices. + +Then the hardware boot stage accesses the boot device, +loads the OS Loader, which is located on a fixed position +on the boot device, and transfers control to it. + +.TP +Note: +We do not cover here booting from network. Those who want +to investigate this subject may want to research: +DHCP, TFTP, PXE, Etherboot. + +.SS "OS Loader" +In PC, the OS Loader is located in the first sector +of the boot device \- this is the \fBMBR\fR +(Master Boot Record). + +In most systems, this primary loader is very +limited due to various constraints. Even on non\-PC systems +there are some limitations to the size and complexity +of this loader, but the size limitation of the PC MBR +(512 bytes including the partition table) makes it +almost impossible to squeeze a full OS Loader into it. + +Therefore, most operating systems make the primary loader +call a secondary OS loader which may be located on +a specified disk partition. + +In Linux the OS loader is normally +.BR lilo (8) +or +.BR grub (8). +Both of them may install either as secondary loaders +(where the DOS installed MBR points to them), or +as a two part loader where they provide special MBR +containing the bootstrap code to load the second part +of the loader from the root partition. + +The main job of the OS Loader is to locate the kernel +on the disk, load it and run it. Most OS loaders allow +interactive use, to enable specification of alternative +kernel (maybe a backup in case the last compiled one +isn't functioning) and to pass optional parameters +to the kernel. + +.SS "Kernel Startup" +When the kernel is loaded, it initializes the devices (via +their drivers), starts the swapper (it is a "kernel process", +called kswapd in modern Linux kernels), and mounts the root +file system (/). + +Some of the parameters that may be passed to the kernel +relate to these activities (e.g: You can override the +default root file system). For further information +on Linux kernel parameters read +.BR bootparam (7). + +Only then the kernel creates the first (user land) +process which is numbered 1. This process executes the +program +.IR /sbin/init , +passing any parameters that weren't handled by the kernel already. + +.SS "init and inittab" +When init starts it reads +.I /etc/inittab +for further instructions. +This file defines what should be run in different \fIrun-levels\fR. + +This gives the system administrator an easy management scheme, where +each run-level is associated with a set of services (e.g: +\fBS\fR is \fIsingle\-user\fR, on \fB2\fR most network +services start, etc.). The administrator may change the current +run-level via +.BR init (8) +and query the current run-level via +.BR runlevel (8). + +However, since it is not convenient to manage individual services +by editing this file, inittab only bootstraps a set of scripts +that actually start/stop the individual services. + +.SS "Boot Scripts" + +.TP +Note: +The following description applies to SYSV\-R4 based system, which +currently covers most commercial Unices (Solaris, HPUX, Irix, Tru64) +as well as the major Linux distributions (RedHat, Debian, Mandrake, +Suse, Caldera). Some systems (Slackware Linux, FreeBSD, OpenBSD) +have a somewhat different scheme of boot scripts. +.LP + +For each managed service (mail, nfs server, cron, etc.) there is +a single startup script located in a specific directory +.RI ( /etc/init.d +in most versions of Linux). +Each of these scripts accepts as a single argument +the word 'start' \-\- causing it to start the service, or the word +'stop' \-\- causing it to stop the service. The script may optionally +accept other "convenience" parameters (e.g: 'restart', to stop and then +start, 'status' do display the service status). Running the script +without parameters displays the possible arguments. + +.SS "Sequencing Directories" +To make specific scripts start/stop at specific run-levels and in +specific order, there are \fIsequencing directories\fR. These +are normally in \fB/etc/rc[0\-6S].d\fR. In each of these directories +there are links (usually symbolic) to the scripts in the \fIinit.d\fR +directory. + +A primary script (usually \fI/etc/rc\fR) is called from inittab(5) +and calls the services scripts via the links in the sequencing directories. +All links with names that begin with 'S' are being called with +the argument 'start' (thereby starting the service). All links with +names that begin with 'K' are being called with the argument 'stop' +(thereby stopping the service). + +To define the starting or stopping order within the same run-level, +the names of the links contain order-numbers. +Also, to make the names clearer, they usually +end with the name of the service they refer to. Example: +the link \fI/etc/rc2.d/S80sendmail\fR starts the sendmail service on +runlevel 2. This happens after \fI/etc/rc2.d/S12syslog\fR is run +but before \fI/etc/rc2.d/S90xfs\fR is run. + +To manage the boot order and run-levels, we have to manage these links. +However, on many versions of Linux, there are tools to help with this task +(e.g: +.BR chkconfig (8)). + +.SS "Boot Configuration" +Usually the daemons started may optionally receive command line options +and parameters. To allow system administrators to change these +parameters without editing the boot scripts themselves, +configuration files are used. These are located in a specific +directory (\fI/etc/sysconfig\fR on RedHat systems) and are +used by the boot scripts. + +In older Unices, these files contained the actual command line +options for the daemons, but in modern Linux systems (and also +in HPUX), these files just contain shell variables. The boot +scripts in \fI/etc/init.d\fR \fBsource\fR the configuration +files, and then use the variable values. +.SH "FILES" +.LP +.IR /etc/init.d/ , +.IR /etc/rc[S0\-6].d/ . +.I /etc/sysconfig/ + +.SH "SEE ALSO" +.BR inittab (5), +.BR bootparam (7), +.BR init (8), +.BR runlevel (8), +.BR shutdown (8) |