This is documented in the guide at the bottom of step 9:
Note To debug any errors that may happen in the recovery process, use the debug module-boot command to enable debugging of the system reimaging process.
A usual poblem with the System Re-imaging process is that the card winds up in a boot loop because of an error. When ROMMON detects an error it reboots and tries the same steps again which usually winds up with the same error which causes a reboot, etc.....
So determining if the card is in a reboot loop, and what the error is would be the next step in your debugging process.
Execute "debug module-boot". Enter "hw-module module 1 recover stop". Wait for a few minutes, and then enter "hw-module module 1 recover boot".
The output from ROMMON on the SSM will be seen on your ASA connection.
Look at the configuration being passed to the SSM's ROMMON and look for any bad entries.
Watch to see if it able to download the System Image file, or if it continuously reboots.
If it continuously reboots, then look to see what error message is seen just prior to the reboot.
Some common problems:
1) Typos in IP address, gateway, tftp server IP, or system image filename.
2) If the tftp server is on the same subnet as the SSM's IP Address, then try leaving the Gateway address blank since it is not needed.
3) Remember that the IP Address is for the external interface of the SSM. So be sure you are using an address that is applicable for the network where you are pluggin in the SSM's external interface.
4) If the TFTP Server is on another subnet, then be sure there is a route to the other network. If having to route back through the ASA, then ensure that the ASA will allow TFTP packets to pass through the ASA. (The ASA could wind up blocking the TFTP packets depending on the ASA configuration)
5) Be sure the file can be downloaded from the TFTP server. Check the file permissions, and the directory where the file is located. From your desktop try to downlaod the file from the tftp server. This will ensure you are using the correct directory and that the file has correct permissions. Once common problem is that the file may be /tftpboot/sensorfiles/IPS-SSM_20-K9-sys-1.1-a-6.1-1-E1.img. But because the tftp server automatically starts in /tftpboot, you may need to NOT specify it for the file and instead just use: sensorfiles/IPS-SSM_20-K9-sys-1.1-a-6.1-1-E1.img
6) Check to make sure the file is not corrupted by running an md5sum and checking it against the value listed on cisco's web site.
=================
With all of that said, however, you need to question whether or not you should be using a System Image file in the first place.
The System Image files are meant to be used only when a complete erasing of the sensor's image is needed. This is generally because the installed files were corrupted, or so old that it would be easier to start over and make it look like it came from the factory; than to use the standard "upgrade" files.
In more than 90% of the cases, most customers will want to "upgrade" rather than do a System Image. The "upgrade" is done from within the sensor itself, and will both load the higher version as well as convert your current configuration to work with the newer version.
Instructions for "upgrading" to 6.1(1)E1:
http://www.cisco.com/en/US/docs/security/ips/6.1/configuration/guide/cli/cli_system_images.html#wp1142504
The IPS-K9-6.1-1-E1.pkg works across ALL sensors (including the SSM-20) except the AIM.
http://www.cisco.com/cgi-bin/tablebuild.pl/ips6
In fact I would use IPS-K9-6.1-1-E2.pkg rather than IPS-K9-6.1-1-E1.pkg. The E2 is the most recent set of releases.
Try using "hw-module module 1 recover stop" to stop the current recovery. If it goes back to an older running image, then use the "upgrade" method rather than the System Image method to get to the higher version.
