Transcript Booting UNIX: Loading the Kernel.

Booting and Shutting Down the
UNIX Operating System
Arcadio A. Sincero Jr.
6/6/2001
CMSC 691X, Section 6080
Booting UNIX:
Loading the Kernel.



Most systems, particularly PCs, implement a two-stage loading
process:
 The system BIOS loads a small boot program.
 This small boot program in turns loads the kernel.
On PCs, this small boot program exists within the first 512 bytes of the
boot device. This 512-byte segment is called the Master Boot Record.
The MBR is what loads the kernel from disk.
A popular boot loader used by most Linux distributions to boot Linux
is called LILO.
 LILO can also be used to boot other operating systems as well
such as MS-DOS, Windows 98 and Windows NT.
Booting UNIX:
Loading the Kernel (continued)

LILO can be installed to either the MBR or to the boot record of the
Linux root partition.
 Install to the boot record instead of the MBR to use another boot
loader for another OS which does not know how to boot Linux
itself.
 For example, say that you want to have both Windows NT and
Linux on the same box and you want to dual boot between them.
You can have NT’s boot loader installed to the MBR and add the
option to boot Linux to it’s boot menu. If the user elects to boot
Linux, NTLOADER will then pass control to LILO which will in
turn load the Linux kernel.
Booting UNIX:
Loading the Kernel (continued)


LILO’s configuration file is “/etc/lilo.conf”. More information on how
to configure LILO can be had from reading lilo.conf’s man page (man
lilo.conf).
Other boot loaders which can be used to load Linux exist:
 GRUB – a more robust boot loader which sports nifty features
such as being able to download a kernel off a network fileserver
and boot that instead of the kernel which lives on the local
harddisk.
 LOADLIN – a boot loader which can be used to boot a Linux
kernel from an MS-DOS command line.
Booting UNIX:
Loading the Kernel (continued)



FreeBSD has something similar to LILO for loading it’s kernel. It
consists of two parts: one which lives in the MBR (see man boot0cfg)
and another part which lives in the FreeBSD root partition (see man
disklabel).
UNIX and UNIX-like systems for non-PC hardware typically follow a
straightforward (but usually proprietary and system specific) scheme
for booting their kernels.
The kernel itself is a program that usually lives in the root partition of
the UNIX filesystem. Most Linux distributions call it “/vmlinuz” and
it often a symbolic link to the real kernel file which lives in “/boot”.
Other UNIX and UNIX-like systems may call it “/unix”, “/vmunix”, or
“/kernel”.
Booting UNIX:
Hardware Initialization



After the kernel is brought in from disk into main memory, it begins
execution and one of the first things it does is initialize the system’s
hardware.
All those cryptic messages you see fly by when the Linux kernel first
starts up are messages from the compiled-in kernel drivers initializing
and configuring your hardware.
 Other UNIX and UNIX-like systems do something similar.
Sometimes the kernel needs help in configuring your hardware.
Information such as IRQ, DMA, and I/O base addresses need to be
specified to the kernel. With Linux these can be specified via it’s
“command line”.
 The BootPrompt-HOWTO has more information about the Linux
command line. This can be had from http://www.linuxdoc.org.
Booting UNIX:
The init Process.




The first program the kernel attempts to execute after basic system
initialization is complete is called init.
The init process is the mother of all processes running on a UNIX
system. If this process dies, so does the system.
init’s job after basic system initialization is complete is to take over the
system start-up procedure and complete the system bootstrap process.
The actual program which the Linux kernel executes as the init
process can be specified via the “init” command line parameter. For
example, to start bash instead of init, you can specify “init=/bin/bash”
on the Linux command line. (see BootPrompt-HOWTO for details.)
Booting UNIX:
Startup Scripts


The system start-up scripts are executed by init when the system starts
up and it is these scripts which are responsible for completing the
bootstrap process of the UNIX system.
 For those familiar with MS-DOS, this is similar to the
AUTOEXEC.BAT facility of that operating system although it is
much more complex on UNIX.
In general there are two styles of system start-up scripts:
 The System V style: used by most UNIX and UNIX-like operating
systems today including Solaris, HP-UX and most distributions of
Linux.
 The BSD style: used by the various flavors of BSD (FreeBSD,
NetBSD, OpenBSD, BSDi) and Slackware Linux.
Booting UNIX:
Startup Scripts – System V Style


All start-up scripts are typically kept in a directory named init.d which
usually lives somewhere under “/etc”.
 Red Hat Linux places this directory under “/etc/rc.d”.
 HP-UX places this directory under “/sbin”.
Each start-up script can usually accept at least two command line
arguments: start and stop.
 start tells the script to start whatever it is that script is responsible
for.
 stop tells the script to stop whatever it is that script is responsible
for.
Booting UNIX:
Startup Scripts – System V Style (continued)


A run-level is a state that the UNIX system can be in that specifies
what the system should be doing and what services it should be
providing.
The SysV init program defines 7 standard run-levels:
 0: complete system shutdown
 1 or S: single-user mode
 2 through 5: multi-user modes
 6: shutdown and reboot
Booting UNIX:
Startup Scripts – System V Style (continued)



Each run-level gets its own directory and is usually under “/etc”, but
sometimes can be found under “/sbin” on some systems. This
directory follows the naming convention of rcn.d where n is the runlevel, i.e. scripts for run-level 2 would be found under a directory
named rc2.d.
This directory contains scripts which are executed when that run-level
is entered.
 While this directory can contain actual scripts, it usually consists of
symbolic links to real scripts which lives under the init.d directory.
Scripts in the run-level directory are executed in alphanumeric order
and if the script name begins with a “S” the script is passed the “start”
command line parameter and if it begins with a “K” it is passed the
“stop” command line parameter.
Booting UNIX:
Startup Scripts – System V Style (continued)

Example:
 Suppose we have the following symbolic links in the directory “/etc/rc2.d”
which is the run-level directory for run-level 2:
 /etc/rc2.d/K01service4 - > /etc/init.d/service4
 /etc/rc2.d/K10service3 -> /etc/init.d/service3
 /etc/rc2.d/S10service1 -> /etc/init.d/service1
 /etc/rc2.d/S25service2 -> /etc/init.d/service2
 The scripts in “/etc/init.d” will then be executed in the following order:
service4, service3, service1 and then service2. They are executed in this
order because the scripts in the run-level directory are executed in
alphanumeric order according to their name.
 Scripts that start with the letter “K” are passed the “stop” parameter while
scripts that start with the letter “S” are passed the “start” parameter.
Booting UNIX:
Startup Scripts – System V Style (continued)

SysV init’s configuration file is “/etc/inittab”. This file tells init what
script it should run for each run-level.
 A common way to implement the SysV style start-up procedure is
to have init execute some master control script passing to it as an
argument the run-level number. This script then executes all of the
scripts in that run-level’s script directory. For example, for runlevel 2, init may execute the script “/etc/init.d/rc” passing it the
argument “2”. This script in turn would execute every script in
run-level 2’s script directory “/etc/rc2.d”.
Booting UNIX:
Startup Scripts – BSD Style


The BSD style is much more simpler than the SysV style. Basically on
system start-up, BSD’s init executes the script “/etc/rc” and on system
shutdown it executes the script “/etc/rc.shutdown”.
To keep things modular, these scripts in turn usually execute other
scripts which are responsible for a single component of the start-up or
shutdown procedure. For example, “/etc/rc” might execute the script
“/etc/rc.network” which would be responsible for configuring the
networking environment on system start-up.
Booting UNIX:
Single User Mode




Single-user mode is a special administrative mode that usually starts
the system with a minimal configuration. For example, no system
daemons are started and extra filesystems may not be mounted.
Single-user mode is typically used to repair a broken system such as
fscking a sick filesystem which cannot be repaired by the automatic
fscking procedure.
Entering single-user mode varies from system to system, but it usually
involves specifying to init a special flag before the system starts up.
 This can be done in Linux by specifying the parameter “single” on
the LILO boot prompt.
On SysV-ish systems, single user mode can also be entered by telling
init to enter run-level 1 or S. This can be done via the telinit
command.
Shutting Down UNIX


UNIX systems have to be gracefully powered down. You cannot just
shut the system off. This can damage the system.
The typical way to shutdown the UNIX system is to use the shutdown
command. shutdown allows the system administrator to broadcast a
message to all currently logged in users that the system is about to be
shutdown. The exact syntax of the shutdown command tends to vary
from system to system. Check shutdown’s man page for details.
Shutting Down UNIX (continued)

Other commands which can be used to shut down the system are halt,
reboot, and init:
 halt and reboot perform the same procedures as shutdown except
it doesn’t broadcast a message to all currently logged in users.
reboot even goes a step further by causing the system to reboot
after shutdown procedures are complete.
 You can also get the system to shutdown by sending the init
process a TERM signal using the kill command. On SysV-ish
systems this usually causes the system to switch to either run-level
0 (halt) or run-level 6 (reboot). On BSD systems this causes the
“/etc/rc.shutdown” script to be executed which handles the
shutdown procedures for the system.