Manual Pages  — DUMPON

System administrators should typically configure dumpon in a persistent fashion using the rc.conf(5) variables dumpdev and dumpon_flags. For more information on this usage, see rc.conf(5).

Starting in FreeBSD 13.0, dumpon can configure a series of fallback dump devices. For example, an administrator may prefer netdump(4) by default, but if the netdump(4) service cannot be reached or some other failure occurs, they might choose a local disk dump as a second choice option.

netdump(4) specific options include:

-c client
	The local IP address of the netdump(4) client.
-g gateway
	The first-hop router between client and server. If the -g option is not specified and the system has a default route, the default router is used as the netdump(4) gateway. If the -g option is not specified and the system does not have a default route, server is assumed to be on the same link as client.
-s server
	The IP address of the netdumpd(8) server.

All of these options can be specified in the rc.conf(5) variable dumpon_flags.

The loader(8) variable dumpdev may be used to enable early kernel core dumps for system panics which occur before userspace starts.

It is recommended to test if the kernel saves encrypted crash dumps using the current configuration. The easiest way to do that is to cause a kernel panic using the ddb(4) debugger:

    # sysctl debug.kdb.panic=1

In the debugger the following commands should be typed to write a core dump and reboot:

    db> dump

    db> reset

After reboot savecore(8) should be able to save the core dump in the "dumpdir" directory, which is /var/crash by default:

    # savecore /dev/ada0s1b

Three files should be created in the core directory: info.#, key.# and vmcore_encrypted.# (where "#" is the number of the last core dump saved by savecore(8)). The vmcore_encrypted.# can be decrypted using the decryptcore(8) utility:

    # decryptcore -p private.pem -k key.# -e vmcore_encrypted.# -c vmcore.#

or shorter:

    # decryptcore -p private.pem -n #

The vmcore.# can be now examined using kgdb(1) ( ports/devel/gdb):

    # kgdb /boot/kernel/kernel vmcore.#

or shorter:

    # kgdb -n #

The core was decrypted properly if kgdb(1) ( ports/devel/gdb) does not print any errors. Note that the live kernel might be at a different path which can be examined by looking at the kern.bootfile sysctl(8).

The dumpon rc(8) script runs early during boot, typically before networking is configured. This makes it unsuitable for configuring netdump(4) when the client address is dynamic. To configure netdump(4) when dhclient(8) binds to a server, dhclient-script(8) can be used to run dumpon(8). For example, to automatically configure netdump(4) on the vtnet0 interface, add the following to /etc/dhclient-exit-hooks.

case $reason in
BOUND|REBIND|REBOOT|RENEW)
        if [ "$interface" != vtnet0 ] || [ -n "$old_ip_address" -a \
             "$old_ip_address" = "$new_ip_address" ]; then
                break
        fi
        if [ -n "$new_routers" ]; then
                # Take the first router in the list.
                gateway_flag="-g ${new_routers%% *}"
        fi
        # Configure as the highest-priority dump device.
        dumpon -i 0 -c $new_ip_address -s $server $gateway_flag vtnet0
        ;;
esac

Be sure to fill in the server IP address and change the interface name if needed.

This process is sandboxed using capsicum(4).