Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
CRASH(8)		  BSD System Manager's Manual		      CRASH(8)

     crash -- FreeBSD system failures

     This section explains a bit about system crashes and (very	briefly) how
     to	analyze	crash dumps.

     When the system crashes voluntarily it prints a message of	the form

	   panic: why i	gave up	the ghost

     on	the console, and if dumps have been enabled (see dumpon(8)), takes a
     dump on a mass storage peripheral,	and then invokes an automatic reboot
     procedure as described in reboot(8).  Unless some unexpected inconsis-
     tency is encountered in the state of the file systems due to hardware or
     software failure, the system will then resume multi-user operations.

     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.	In many	instances, this	will be	the name of the	rou-
     tine which	detected the error, or a two-word description of the inconsis-
     tency.  A full understanding of most panic	messages requires perusal of
     the source	code for the system.

     The most common cause of system failures is hardware failure, which can
     reflect itself in different ways.	Here are the messages which are	most
     likely, with some hints as	to causes.  Left unstated in all cases is the
     possibility that hardware or software error produced the message in some
     unexpected	way.

     cannot mount root
	     This panic	message	results	from a failure to mount	the root
	     filesystem	during the bootstrap process.  Either the root
	     filesystem	has been corrupted, or the system is attempting	to use
	     the wrong device as root filesystem.  Usually, an alternate copy
	     of	the system binary or an	alternate root filesystem can be used
	     to	bring up the system to investigate.  Most often	this is	done
	     by	the use	of the boot floppy you used to install the system, and
	     then using	the "fixit" floppy.

     init: not found
	     This is not a panic message, as reboots are likely	to be futile.
	     Late in the bootstrap procedure, the system was unable to locate
	     and execute the initialization process, init(8).  The root
	     filesystem	is incorrect or	has been corrupted, or the mode	or
	     type of /sbin/init	forbids	execution or is	totally	missing.

     ffs_realloccg: bad	optim
     ffs_valloc: dup alloc
     ffs_alloccgblk: cyl groups	corrupted
     ffs_alloccg: map corrupted
     blkfree: freeing free block
     blkfree: freeing free frag
     ifree: freeing free inode
	     These panic messages are among those that may be produced when
	     filesystem	inconsistencies	are detected.  The problem generally
	     results from a failure to repair damaged filesystems after	a
	     crash, hardware failures, or other	condition that should not nor-
	     mally occur.  A filesystem	check will normally correct the	prob-

     timeout table full
	     This really shouldn't be a	panic, but until the data structure
	     involved is made to be extensible,	running	out of entries causes
	     a crash.  If this happens,	make the timeout table bigger.

     init died (signal #, exit #)
	     The system	initialization process has exited with the specified
	     signal number and exit code.  This	is bad news, as	no new users
	     will then be able to log in.  Rebooting is	the only fix, so the
	     system just does it right away.

     That completes the	list of	panic types you	are likely to see.

     If	the system has been configured to take crash dumps (see	dumpon(8)),
     then when it crashes it will write	(or at least attempt to	write) an im-
     age of memory into	the back end of	the dump device, usually the same as
     the primary swap area.  After the system is rebooted, the program
     savecore(8) runs and preserves a copy of this core	image and the current
     system in a specified directory for later perusal.	 See savecore(8) for

     To	analyze	a dump you should begin	by running gdb(1) with the -k flag on
     the system	load image and core dump.  If the core image is	the result of
     a panic, the panic	message	is printed.  For more details consult the
     chapter on	kernel debugging in the	FreeBSD	Developers' Handbook

     gdb(1), dumpon(8),	reboot(8), savecore(8)

     A crash man page first appeared in	FreeBSD	2.2.

BSD			       February	2, 1996				   BSD


Want to link to this manual page? Use this URL:

home | help