-and save the output.
-Be sure to boot up
-``vmunix''
-before coming up multi-user.
-.PP
-Do a
-.I sync,
-and proceed to check and fix all file systems,
-performing a
-.I dcheck
-and
-.IR icheck (1)
-on all file systems which could have been in use at the time
-of the crash.
-If any serious file system problems are found, they should be repaired.
-When you are satisfied with the health of your disks,
-log out by typing an EOT (<control-D>).
-The command sequence in /etc/rc will be executed and the system will
-be in multi-user mode.
-.PP
-To even boot \s8UNIX\s10 at all,
-three files (and the directories leading to them)
-must be intact.
-First,
-the initialization program
-.I /etc/init.vm
-must be present and executable.
-If it is not,
-then the cpu will loop at location 0x13.
-For
-.I init.vm
-to work correctly,
-.I /dev/console
-and
-.I /bin/sh
-must be present.
-If either does not exist,
-the symptom is best described
-as thrashing.
-.I Init
-will go into a
-.I fork/exec
-loop trying to create a
-Shell with proper standard input and output.
-.PP
-If you cannot get the system to boot,
-a runnable system must be obtained from
-a backup medium.
-The root file system may then be doctored as
-a mounted file system as described below.
-If there are any problems with the root
-file system,
-it is probably prudent to go to a
-backup system to avoid working on a
-mounted file system.
-.PP
-.I "Repairing disks.||"
-The first rule to keep in mind is that an addled disk
-should be treated gently;
-it shouldn't be mounted unless necessary,
-and if it is very valuable yet
-in quite bad shape, perhaps it should be dumped before
-trying surgery on it.
-This is an area where experience and informed courage count for much.
-.PP
-The problems reported by
-.I icheck
-typically fall into two kinds.
-There can be
-problems with the free list:
-duplicates in the free list, or free blocks also in files.
-These can be cured easily with an
-.I "icheck \-s."
-If the same block appears in more than one file
-or if a file contains bad blocks,
-the files should be deleted, and the free list reconstructed.
-The best way to delete such a file is to use
-.IR clri (1),
-then remove its directory entries with
-.IR rm (1).
-(Do not use
-.IR mv (1).)
-If any of the affected files is really precious,
-you can try to copy it to another device
-first.
-.PP
-.I Dcheck
-may report files which
-have more directory entries than links.
-Such situations are potentially dangerous;
-.I clri
-discusses a special case of the problem.
-All the directory entries for the file should be removed.
-If on the other hand there are more links than directory entries,
-there is no danger of spreading infection, but merely some disk space
-that is lost for use.
-It is sufficient to copy the file (if it has any entries and is useful)
-then use
-.I clri
-on its inode and remove any directory
-entries that do exist.
-.PP
-Finally,
-there may be inodes reported by
-.I dcheck
-that have 0 links and 0 entries.
-These occur on the root device when the system is stopped
-with pipes open, and on other file systems when the system
-stops with files that have been deleted while still open.
-A
-.I clri
-will free the inode, and an
-.I "icheck -s"
-will
-recover any missing blocks.
-.PP
-.I "Why did it crash?||"
-UNIX types a message
-on the console typewriter when it voluntarily crashes.
-Here are some of the possible panic messages,
-with enough information to provide
-a hope at least of the remedy.
-The message has the form `panic: ...',
-`Trap from kernel mode', or `ILL I/E VEC'
-(possibly accompanied by other information).
-In rare cases the system will ``panic'' but the console message
-will not appear; if this happens, you can trace the message easily
-through the variable
-.I panicstr
-in the system.
-Left unstated in all cases
-is the possibility that hardware or software
+on the console, takes a dump on a mass storage peripheral,
+and then invokes an automatic reboot procedure as
+described in
+.IR reboot (8).
+(If auto-reboot is disabled on the front panel of the machine the system
+will simply halt at this point.)
+Unless some unexpected inconsistency is encountered in the state
+of the file systems due to hardware or software failure the system
+will then resume multi-user operations.
+.PP
+The system has a large number of internal consistency checks; if one
+of these fails, then it will panic with a very short message indicating
+which one failed.
+.PP
+The most common cause of system failures is hardware failure, which
+can reflect itself in different ways. Here are the messages which
+you are likely to encounter, with some hints as to causes.
+Left unstated in all cases is the possibility that hardware or software
projects / unix-history / blobdiff