% "@(#)sag:$Id$"        
%--------------------------------------------------------------------
\chapter{Boots And Shutdowns}
%--------------------------------------------------------------------

        \begin{raggedleft}
        \it
        This chapter needs a quote.  Suggestions, anyone?  \\
        \end{raggedleft}
        \vspace{2em}

        \noindent
	This section explains what goes on when a Linux system is
	turned on and off, and how it should be done properly.

\section{An overview of boots and shutdowns}

	The act of turning on a computer system and making its operating
	system to be loaded\footnote{On early computers, it wasn't enough
	to merely turn on the computer, you had to manually load the
	operating system as well.  These new-fangled thing-a-ma-gigs do
	it all by themselves.} is called \defin{booting}.  The name
	comes from an image of the computer pulling itself up from its
	bootstraps, but the act itself slightly more realistic.

	During bootstrapping the computer first loads
	a small piece of code called the \defin{bootstrap loader},
	which in turn loads and starts
	the operating system.  The bootstrap loader is usually
	stored in a fixed location on a hard disk or a floppy.  The
	reason for this two step process is that the operating system
	is big and complicated, but the first piece of code that the
	computer loads must be very small (a few hundred bytes), to avoid
	making the hardware unnecessarily complicated.

	Different computers do the bootstrapping differently.  For PC's,
	the computer (well, it's BIOS) reads in the first sector (called
	the boot sector) of a floppy or hard disk.  The bootstrap loader
	is contained withing this sector.  It loads the operating
	system from elsewhere on the disk (or from some other place).

	After Linux has been loaded, it initializes the hardware and
	device drivers, and then runs \cmd{init(8)}.  \cmd{init}
	starts other processes to allow users to log in, and do things.
	The details of this part will be discussed below.

	In order to shut down a Linux system, first all processes
	are told to terminate (this makes them close any files and
	do other necessary things to keep things tidy), then filesystems
	and swap areas are unmounted, and finally a message is printed
	to the console that the power can be turned off.  If the proper
	procedure is not followed, terrible things can and will happen;
	most importantly, the filesystem buffer cache might not be flushed,
	which means that all data in it is lost and the filesystem on
	disk is inconsistent, and therefore possibly unusable.

\section{The boot process in closer look}

	You can boot Linux either from a floppy or from the hard
	disk.  The installation section in the Getting Started guide
	tells you how to install Linux so you can boot it the way
	you want to.

	When the computer is booted, the BIOS will do various tests to
	check that everything looks all-right,\footnote{These is called
	the \defin{power on self test}, or \defin{POST} for short.} and
	will then start the actual booting.  It will choose a disk
	drive (typically the first floppy drive, if there is a floppy
	inserted, otherwise the first hard disk, if one is installed
	in the computer; the order might be configurable, however)
	and will then read its very first sector.  This is
	called the \defin{boot sector}; for a hard disk, it is also
	called the \defin{master boot record}, since a hard disk can
	contain several partitions, each with their own boot sectors.

	The boot sector contains a small program (small enough to fit into
	one sector) whose responsibility is to read the actual operating
	system from the disk and start it.  When booting Linux from
	a floppy disk, the boot sector contains code that just reads
	the first few hundred blocks (depending on the actual
	kernel size, of course) to a predetermined place in memory.
	On a Linux boot floppy, there is no filesystem, the kernel
	is just stored in consecutive sectors, since this simplifies
	the boot process.  It is possible, however, to boot from a
	floppy with a filesystem, by using LILO.

	When booting from the hard disk, the code in the master boot
	record will examine the partition table (also in the master boot
	record), identify the active
	partition (the partition that is marked to be bootable), read
	the boot sector from that partition, and then start the code
	in that boot sector.  The code in the partition's boot sector
	does what a floppy disk's boot sector does: it will read in
	the kernel from the partition and start it.  The details vary,
	however, since it is generally not useful to have a separate
	partition for just the kernel image, so the code in the
	partition's boot sector can't just read the disk in sequential
	order, it has to find the sectors whereever the filesystem has
	put them.  There are several ways around this problem, but the
	most common way is to use LILO.  (The details about how to do
	this are irrelevant for this discussion, however; see the LILO
	documentation for more information, it is most thorough.)

	When booting with LILO, it will normally go right ahead and
	read in and boot the default kernel.  It is also possible to
	configure LILO to be able to boot one of several kernels, or
	even other operating systems than Linux, and it is possible
	for the user to choose which kernel or operating system is to
	be booted at boot time.  LILO can be configured so that if one
	holds down the \key{alt}, \key{shift}, or \key{ctrl} key at
	boot time (i.e. when LILO is loaded), LILO will ask what is to
	be booted and not boot the default right away.  Alternatively,
	LILO can be configured so that it will always ask, with an
	optional timeout that will cause the default kernel to be
	booted.

	The are other boot loaders than LILO.  However, since LILO has
	been written especially for Linux, it has some features
	that are useful and that only it provides, for example the
	ability to pass arguments to the kernel at boot time, or
	overriding some configuration options built into the kernel.
	Hence, it is usually the best choice.  Among the alternatives
	are bootlin and bootactv.\footnote{I don't know much about any
	of the alternatives.  If and when I learn, I will add more
	descriptions.}

	Booting from floppy and from hard disk have both their
	advantages, but generally booting from the hard disk is
	nicer, since it avoids the hassle of playing around with
	floppies.  It is also faster.  However, it can be more
	troublesome to install the system so it can boot from the hard
	disk, so many people will first boot from floppy, then, when
	the system is otherwise installed and working well, will
	install LILO and start booting from the hard disk.

	After the Linux kernel has been read into the memory, by
	whatever means, and is started for real, roughly the following
	things happen:

    \begin{itemize}

    \item

	The Linux kernel is installed compressed, so it will first
	uncompress itself.  The beginning of the compressed kernel
	contains a small uncompressed program that does this.

    \item

	If you have a super-VGA card that Linux
	recognizes and that has some special text modes (such as 100
	columns by 40 rows), Linux asks you which mode
	you want to use.  During the kernel compilation, it is
	possible to preset a video mode, so that this is never asked.
	This can also be done with LILO or \cmd{rdev(8)}.

    \item

	After this the kernel checks what other hardware there is
	(hard disks, floppies, network adapters\ldots), and configures
	some of its device drivers appropriately; while it does this,
	it outputs messages about its findings.  For example, when I
	boot, I it looks like this:
%%%%%%%%
		\begin{screen}\begin{verbatim}
LILO boot:
Loading linux.
Console: colour EGA+ 80x25, 8 virtual consoles
Serial driver version 3.94 with no serial options enabled
tty00 at 0x03f8 (irq = 4) is a 16450
tty01 at 0x02f8 (irq = 3) is a 16450
lp_init: lp1 exists (0), using polling driver
Memory: 7332k/8192k available (300k kernel code, 384k reserved, 176k data)
Floppy drive(s): fd0 is 1.44M, fd1 is 1.2M
Loopback device init
Warning WD8013 board not found at i/o = 280.
Math coprocessor using irq13 error reporting.
Partition check:
  hda: hda1 hda2 hda3
VFS: Mounted root (ext filesystem).
Linux version 0.99.pl9-1 (root@haven) 05/01/93 14:12:20
		\end{verbatim}\end{screen}
%%%%%%%%
	The exact texts are different on different systems, depending
	on the hardware, the version of Linux being used, and how
	it has been configured.

   \item

	Then the kernel will try to mount the root filesystem.  The
	place is configurable at
	compilation time,  or any time with \cmd{rdev}
	or LILO.  The filesystem type is detected
	automatically.  If the mounting of the root filesystem fails,
	for example because you didn't remember to include the corresponding
	filesystem driver in the kernel,
	the kernel panics and halts the system (there isn't much it
	can do, anyway).

	The root filesystem is usually mounted read-only (this can
	be set in the same way as the place).  This makes it possible
	to check the filesystem while it is mounted; it is not a good
	idea to check a filesystem that is mounted read-write.

    \item

	After this, the kernel starts the program \cmd{init(8)}
	(located in \fn{/sbin/init}) in
	the background (this will always become process number 1).
	\cmd{init} does various startup chores.  The exact things it does
	depends on the version being used; see
	chapter~\ref{chap:daemons} for more information.

    \item

	\cmd{init} then starts a \cmd{getty(8)} for virtual consoles
	and serial lines.
	\cmd{getty} is the program which lets people log in via virtual
	consoles and serial terminals.  \cmd{init} may also start some
	other programs, depending on how it is configured.

    \item

	After this, the boot is complete, and the system is up and
	running normally.

    \end{itemize}

\section{More about shutdowns}

	\meta two different implemetnations of shutdown? one that uses
	reboot/halt as internal binaries that shouldn't be run by hand?

	It is important to follow the correct procedures when you shut
	down a Linux system.  If you fail do so, your filesystems probably
	will become trashed and the files probably will become scrambled.
	This is because Linux has a disk cache that won't write things
	to disk at once, but only at intervals.  This greatly improves
	performance but also means that if you just turn off the power
	at a whim the cache may hold a lot of data and that what is on
	the disk may not be a fully working filesystem (because only
	some things have been written to the disk).

	Another reason against just flipping the power switch is that
	in a multi-tasking system there can be lots of things going on
	in the background, and shutting the power can be quite
	disastrous.  This is especially true for machines that several
	people use at the same time.

	The commands for properly shutting down a Linux system are
	\cmd{shutdown(8)} and \cmd{halt(8)} (both are located in \fn{/sbin}).
	There are two usual ways of using them.

	If you are running a system where you are the only user, the
	usual way of using shutdown is to quit all running programs,
	log out on all virtual consoles, log in as {\tt root} on one
	of them (or stay logged in as {\tt root} if you already are,
	but you should change to the root directory, to avoid problems
	with unmounting), then give the command \cmd{halt} or
	\cmd{shutdown~-h~now}
	(substitute {\tt now} with a plus sign and a number in minutes
	if you want a delay, though you usually don't on a single user
	system) or \cmd{halt}.

	Alternatively, if your system has many users, use the command
	{\tt shutdown~-h~{\sl +time message}}, where {\sl time} is the
	time in minutes until the system is halted, and {\sl message}
	is a short explanation of why the system is shutting down.
		%
\begin{tscreen}
root ~ \# shutdown -h +10 'We will install a new disk.  System should \\
> be back on-line in three hours.'
\end{tscreen}
		%
	This will warn everybody that the system will shut
	down in ten minutes, and that they'd better get lost or loose
	data.  The warning is printed to
	every terminal on which someone is logged in, including all
	\cmd{xterm}s.
		%
\begin{tscreen}
Broadcast message from root (ttyp0) Wed Aug  2 01:03:25 1995... \\
\ \\
We will install a new disk.  System should \\
be back on-line in three hours. \\
The system is going DOWN for system halt in 10 minutes !!
\end{tscreen}
		%
	The warning is automatically repeated a few times before the
	boot, with shorter and shorter intervals as the time runs out.
	You can't use a delay with \cmd{halt}; it is seldom appropriate
	to use \cmd{halt} on a multiuser system.

	\meta /etc/inittab can give commands to execute when halting/rebooting

	When the real shutting down starts after any
	delays, all filesystems (except the root one) are unmounted,
	user processes (if anybody is still logged in) are killed,
	daemons are shut down, all filesystem are unmounted,
	and generally everything settles down.
	When that is done, \cmd{shutdown} prints out a message that
	you can power down the machine.  Then, {\em and only then},
	should you move your fingers towards the power switch.

	Sometimes, although rarely on any good system, it is
	impossible to shut down properly.  For instance, if the kernel
	panics and crashes and burns and generally misbehaves, it
	might be completely impossible to give any new commands, hence
	shutting down properly is somewhat difficult, and just about
	everything you can do is hope that nothing has been too
	severely damaged and turn off the power.  If the troubles are a
	bit less severe (say, somebody merely hit your keyboard with
	an axe), and the kernel and the \cmd{update} program still run
	normally, it is probably a good idea to wait a couple of
	minutes to give \cmd{update(8)} a chance to flush the buffer
	cache, and only cut the power after that.

	Some people like to shut down using the command
	\cmd{sync(8)}\footnote{\cmd{sync} flushes the buffer cache.}
	three times, waiting for the disk I/O to stop, then turn off
	the power.  If there are no running programs, this is about
	equivalent to using \cmd{shutdown}.  However, it does not
	unmount any filesystems and this can lead to problems with the
	ext2fs ``clean filesystem'' flag.  The triple-sync method is
	\emph{not recommended}.

	(In case you're wondering: the reason for {\em three} syncs is
	that in the early days of UNIX, when the commands were
	typed separately, that usually gave sufficient time for most
	disk I/O to be finished.)

\section{Rebooting}

	Rebooting means booting the system again.  This can be accomplished
	by first shutting it down completely, turning power off, and then
	turning it back on.  A simpler way is to ask \cmd{shutdown} to
	reboot the system, instead of merely halting it.  This
	is accomplished by using the \cmd{-r} option to shutdown, for
	example, by giving the command \cmd{shutdown -r now}.  You can
	also use the \cmd{reboot} command (which, like \cmd{halt}, doesn't
	wait until it perpetrates its foul deed).

\section{Single user mode}

	The \cmd{shutdown} command can also be used to bring the system
	down to single user mode, in which no one can log in, but
	\texttt{root} can use the console.  This is useful for
	system administration tasks that can't be done while the system
	is running normally.  Single user mode is discussed more
	thoroughly in chapter~\ref{chap:daemons}.

\section{Emergency boot floppies}

	It is not always possible to boot a computer from the hard disk.
	For example, if you make a mistake in configuring LILO, you might
	make your system unbootable.  For these situations, you need an
	alternative way of booting that will always work (as long as the
	hardware works).  For typical PC's, this means booting from the
	floppy drive.

	Most Linux distributions allow one to create an \defin{emergency
	boot floppy} during installation.  It is a good idea to do this.
	However, many such boot disks contain only the kernel, and assume
	you will be using the programs on the distributions' installation
	disks to fix whatever problem you have.  Sometimes those programs
	aren't enough; for example, you might have to restore some files
	from backups made with software not on the installation disks.

	Thus, it might be necessary to create a custom root floppy as well.
	The \emph{Bootdisk HOWTO} by Graham Chapman
	contains instructions for doing this.
	You must, of course, remember to keep your emergency boot
	and root floppies up to date.

	You can't use the floppy drive you use to mount the root floppy
	for anything else.  This can be inconvenient if you only have one
	floppy.  However, if you have enough memory, you
	can configure your boot floppy to load the root
	disk to a ramdisk (the boot floppy's kernel needs to be specially
	configured for this).  This frees the floppy drive after the
	root floppy has been loaded to a ramdisk.
