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

FreeBSD Manual Pages

  
 
  

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

NAME
       crash --	FreeBSD	system failures

DESCRIPTION
       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	incon-
       sistency.  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  file	system	during the bootstrap process.  Either the root
       file system has been corrupted, or the system is	attempting to use  the
       wrong  device  as  root file system.  Usually, an alternate copy	of the
       system binary or	an alternate root file system 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 file
       system 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 file system	 inconsistencies  are  detected.   The
       problem generally results from a	failure	to repair damaged file systems
       after  a	 crash,	 hardware failures, or other condition that should not
       normally	occur.	A file system check will normally correct the problem.

       timeout table full  This	really should not be a panic,  but  until  the
       data  structure	involved  is made to be	extensible, running out	of en-
       tries causes a crash.  If this happens, make the	timeout	table bigger.

       init died (signal #, exit #)  The system	initialization process has ex-
       ited 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
       image  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 cur-
       rent  system  in	 a  specified  directory  for  later   perusal.	   See
       savecore(8) for details.

       To analyze a dump you should begin by running kgdb(1) (ports/devel/gdb)
       on  the	system load image and core dump.  If the core image is the re-
       sult of a panic,	the panic message is printed.  For more	 details  con-
       sult  the  chapter  on  kernel  debugging  in  the  FreeBSD Developers'
       Handbook	(https://www.freebsd.org/doc/en/books/developers-handbook/).

SEE ALSO
       kgdb(1) (ports/devel/gdb), dumpon(8), reboot(8),	savecore(8)

HISTORY
       The crash manual	page first appeared in FreeBSD 2.2.

FreeBSD	14.3			 July 23, 2011			      CRASH(8)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=crash&sektion=8&manpath=FreeBSD+14.3-RELEASE+and+Ports>

home | help