lesson-boot() {
cat << EOF
	This is a particularly difficult problem to solve.
	However, many clues are presented to help guide you.

	First, during the reboot, the system hangs.  This means
	that something went wrong, most likely with the
	/etc/rc.d/rc0.d scripts.  When the system is rebooted,
	the boot process happens without error until the init
	command executes.  Then, the rc.sysinit, rc, and prefdm
	commands fail.  What all of these have in common, besides
	being startup and shutdown programs, is that they are all
	shell scripts.

	Rescue mode is needed to solve this problem, as you will
	readily find if you attempt to solve it in single user
	mode.

	When entering rescue mode, you will note that filesystems
	are basically sane: the partitions will mount.  Now, you
	must begin your investigations.  This may take you down a
	number of routes, but one possible route is to attempt to
	chroot into the disk:

		chroot /mnt/sysimage

	This fails, giving the error message:

		chroot: cannot execute /bin/sh: No such file or directory

	There is something wrong with the /bin/sh command.  It
	may not be immediately obvious which /bin/sh command is
	referenced: the /bin/sh in the rescue environment or the
	/bin/sh in the chroot'ed environment.  You may
	investigate each, but the more likely one will be in the
	chroot'ed environment.  Do a long listing of this file:

		ls -l /mnt/sysimage/bin/sh

	You will note that this is a symbolic link to the bash
	command in the same directory (understand how symlinks
	work when using relative pathnames).  Now investigate the
	bash command:

		ls -l /mnt/sysimage/bin/bash

	The file is missing!  You have uncovered the problem.
	Consider the symptoms that you have experienced so far:

		o  The /etc/rc.d/rc0.d scripts failed.  These are
		   shell scripts, requiring a shell to execute.

		o  The rc.sysinit, rc, and prefdm commands all
		   failed to execute.  Again, these are shell
		   scripts.

		o  The chroot command failed, as it could not
		   execute the /bin/sh command, a symbolic link
		   to the bash command.

	The missing bash command explains all of these symptoms.

	The question remains: how should this be fixed.  Usually,
	a missing file can be recovered by reinstalling a
	package.  This will present special problems in
	recovering the bash command, as the bash command is often
	used in rpm installations.  Here is a possible solution:

	First, determine which package you need to install:

		rpm -qf /bin/bash --root /mnt/sysimage

	This will tell you that you need to install the bash
	package.  Install it:

		cd /mnt/source/Server
		ls bash*
		rpm -ihv --replacepkgs --root /mnt/sysimage bash-3*

	This may hang.  If so, it will hang after the 50 hash
	marks, that is, after the the software has been installed
	but perhaps before the concluding scripts have been run.
	This may indicate trouble, but it may recover the system
	sufficiently to allow you to reboot the computer.

	Upon rebooting the computer, you now have a more
	extensive job ahead of you.  First, you must confirm that
	the rpm install of the bash package worked.  You may do
	this by reinstalling it.  Second, you should ask yourself
	how this problem occurred in the first place.  Did a
	person with root access accidentally delete the file?  Is
	this a symptom of a hard disk failure?  Did a cracker
	break into your system and damage it?  Toward answering
	these questions, you might consider running and then
	analysing the output of this command:

		rpm -Va > /tmp/va.out 2>&1 

	This will take a while to run and it will be quite
	chatty.  Can you distinguish expected changes from
	unexpected changes?  Consider:

		o  The c character before the file name indicates
		   that the file is a configuration file.
		   Changes in these files are considered
		   expected.

		o  The g character before the file name indicates
		   that the file is a hashed database, typically
		   changeable.

		o  Changes to the /dev directory, particularly to
		   active ttys are ordinary.

		o  Changes to naturally dynamic files are
		   ordinary, such as changes to database files.

		o  Files in executable directories should almost
		   never change.  These directories include (but
		   are not limited to): /bin, /sbin, /usr/bin,
		   /usr/sbin, /usr/local/bin, /usr/local/sbin.

	Familiarity with this output should lead you to conclude
	that this was a singular incident, not a symptom of a
	greater problem.  But you would only be sure of this if
	you had previous experience running an rpm -Va command
	and reading the output carefully.

	Lessons:

		o  Know rescue mode.

		o  Know the rpm command and its many useful
		   options, especially the options described
		   above.  Particularly useful is the rpm -Va
		   command, but only if you can interpret the
		   results.

		o  Consider how symptoms relate to each other.

		o  Read error messages carefully and take them
		   seriously.  Yes, occasionally error message
		   can be deceptive, but, more often than not,
		   they guide you directly to the problem.

EOF
}

