Title: Booting and Shutting Down the UNIX Operating System
1Booting and Shutting Down the UNIX Operating
System
- Arcadio A. Sincero Jr.
- 6/6/2001
- CMSC 691X, Section 6080
2Booting UNIXLoading 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.
3Booting UNIXLoading 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 NTs
boot loader installed to the MBR and add the
option to boot Linux to its boot menu. If the
user elects to boot Linux, NTLOADER will then
pass control to LILO which will in turn load the
Linux kernel.
4Booting UNIXLoading the Kernel (continued)
- LILOs configuration file is /etc/lilo.conf.
More information on how to configure LILO can be
had from reading lilo.confs 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.
5Booting UNIXLoading the Kernel (continued)
- FreeBSD has something similar to LILO for loading
its 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.
6Booting UNIXHardware 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 systems
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
its command line. - The BootPrompt-HOWTO has more information about
the Linux command line. This can be had from
http//www.linuxdoc.org.
7Booting UNIXThe 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. - inits 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.)
8Booting UNIXStartup 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.
9Booting UNIXStartup 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.
10Booting UNIXStartup 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
11Booting UNIXStartup 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 run-level, 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.
12Booting UNIXStartup 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 - gt /etc/init.d/service4
- /etc/rc2.d/K10service3 -gt /etc/init.d/service3
- /etc/rc2.d/S10service1 -gt /etc/init.d/service1
- /etc/rc2.d/S25service2 -gt /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.
13Booting UNIXStartup Scripts System V Style
(continued)
- SysV inits 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-levels script
directory. For example, for run-level 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 2s script
directory /etc/rc2.d.
14Booting UNIXStartup Scripts BSD Style
- The BSD style is much more simpler than the SysV
style. Basically on system start-up, BSDs 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.
15Booting UNIXSingle 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.
16Shutting 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 shutdowns man page for details.
17Shutting 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 doesnt 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.