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.

       Mounting	from <device> failed with error	<err>  The system  was	unable
       to  mount  the  configured root filesystem.  Either the root filesystem
       has been	corrupted, or the system is attempting to use the wrong	device
       as root filesystem.

       This is not a panic message; rather it is followed  by  an  interactive
       mountroot>  prompt  where  the  operator	 can list detected devices and
       filesystems, and	select an alternative root filesystem to  mount.   Al-
       ternatively, the	system can be booted from recovery media to repair the
       situation.   The	system install media provides a	live environment which
       is suitable for this task.

       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.

       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	15.0			 July 25, 2025			      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+15.0-RELEASE+and+Ports>

home | help