Preparing for Disasters

Under certain circumstances, a driver can render the system incapable of booting. To avoid system reinstallation in this event, some advance work must be done.

Back Up Critical System Files

A number of driver-related system files are difficult, if not impossible, to reconstruct. Files such as /etc/name_to_major,/etc/driver_aliases, /etc/driver_classes, and /etc/minor_perm can be corrupted if the driver crashes the system during installation (see the add_drv(1M) man page).

To be safe, after the test machine is in the proper configuration, make a backup copy of the root file system. If you plan on modifying the /etc/system file, make a backup copy of the file before modifying it.

Prepare and Boot an Alternate Kernel

A good strategy to avoid rendering a system inoperable is to make a copy of the kernel and associated binaries, and to boot that instead of the default kernel. To do so, make a copy of the drivers in /platform/* as follows:

# cp -r /platform/`uname -i`/kernel /platform/`uname -i`/kernel.test

When developing your driver, place it in /platform/`uname -i`/kernel.test/drv and boot that kernel instead of the default kernel:

# reboot -- kernel.test/unix

or from the PROM:

ok boot kernel.test/unix

This results in the test kernel and drivers being booted:

Rebooting with command: boot kernel.test/unix
Boot device: /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@0,0:a  File and args:
kernel.test/unix
SunOS Release 5.9 Version Generic 32-bit
Copyright 1983-2002 Sun Microsystems, Inc.  All rights reserved.
...

Alternately, the module path can be changed by booting with the ask (-a) option:

ok boot -a

This results in a series of prompts which you can use to configure the way the kernel boots:

Rebooting with command: boot -a
Boot device: /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@0,0:a  File and args: -a
Enter filename [kernel/sparcv9/unix]: kernel.test/sparcv9/unix
Enter default directory for modules
[/platform/sun4u/kernel.test /kernel /usr/kernel]: <CR>
Name of system file [etc/system]: <CR>
SunOS Release 5.9 Version Generic 64-bit
Copyright 1983-2002 Sun Microsystems, Inc.  All rights reserved.
root filesystem type [ufs]: <CR>
Enter physical name of root device
[/sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@0,0:a]: <CR>

Prepare Other Backup Plans

If the system is attached to a network, the test machine can be added as a client of a server. If a problem occurs, the system can be booted off the network. The local disks can then be mounted and fixed. Alternatively, the system can be booted directly from the Solaris 9 CD-ROM.

Another way to recover from disaster is to have another bootable root file system. Use format(1M) to make a partition the exact size of the original, then use dd(1M) to copy it. After making a copy, run fsck(1M) on the new file system to ensure its integrity.

Later, if the system cannot boot from the original root partition, boot the backup partition and use dd(1M) to copy the backup partition onto the original one. If the system will not boot but the root file system is undamaged (just the boot block or boot program was destroyed), boot off the backup partition with the ask (-a) option, then specify the original file system as the root file system.

Saving System Crash Dumps

When the system panics, it writes an image of kernel memory to the dump device. The dump device by default is the most suitable swap device. The dump is a system crash dump, similar to core dumps generated by applications. On rebooting after a panic, savecore(1M) checks the dump device for a crash dump. If one is found, it makes a copy of the kernel's symbol table (called unix.n) and dumps a core file (called vmcore.n) in the core image directory which by default is /var/crash/machine_name. There must be enough space in /var/crash to contain the core dump or it will be truncated. mdb(1) can then be used on the core dump and the saved kernel.

In the Solaris 9 operating system, crash dump is enabled by default. The dumpadm(1M) command is used to configure system crash dumps. Use the dumpadm(1M) command to verify that crash dumps are enabled and to determine the location of the directory where core files are saved. See the dumpadm(1M) man page for more information.

savecore(1M) can be prevented from filling the file system if there is a file called minfree in the directory in which the dump will be saved. This file contains a number of kilobytes to remain free after savecore(1M) has run. However, if not enough space is available, the core file is not saved.