Ghost Solution Suite

Exact Error message:
Question: (1808) Decompression error, abort?

Additional Info:
This error is occuring on multiple targets with multiple images. Often a simple reboot and attempt to push the image succeeds. Other times it takes several attempts and many hours.

Hardware: Dell PowerEdge 1850 w/ Intel� PRO/1000 MT Network Card, Dell PowerEdge 6850 w/Broadcom NetXtreme Network Card, Dell PowerEdge 850 w/Broadcom NetXtreme Network Card

Driver Versions: Obtained by DELL

Intel NIC Driver Version: 8.4.21.0 built by WinDDK.

Broadcom NetXtreme Driver version: 8.22.1.0

Ghost SW Version: 8.0 (Have tried with 8.1, 8.2, and 8.3 with the same results).

A boot floppy starts the machine, maps a share and runs the ghost.exe from the share. (Therefore ghost is running on each target)


It runs the command:

s:\ghost -clone,mode=load,src=s:\%GhostImage%,dst=1 -sure -RB -FDSZ -FFS

Configuration: We have the server NIC hard coded to negotiate at 1GB/sec Full Duplex. We have our switches hard coded to negotiate at 1GB/sec. (Need to verify if full duplex).


Any information anyone can provide is most appreciated. Even a defined description of what the 1808: Ghost Decompression error is would be of benefit. I've seen other GHOST decompression error messages - but never 1808.

Thanks in advance.

This error occurs while one small portion of the image file is being decompressed. The cause of the decompression error can vary but if 'abort' is chosen then there should be a second error message something like 19225, Decompression error 'x'. This message provides some additional detail about how the decompression failed. Is this message displayed, if so what is the number 'x'?

Because rebooting will sometimes allow the image push to succeed, it seems more likely to me that something in the network transfer is causing the image is to be subtly corrupted and as a result the decompression process is failing. One way to verify this, as an experiment only, would be to deploy the image without the network.

If there is a network transfer problem then it could be to do with the DOS environment. What version of DOS is running on the boot disk?

Robert,
Thank you very much for your reply. It has been VERY helpful in trying to track down this issue. To answer your questions - when I choose Abort from the initial Decompression error message I do get another message:

Application Error 19225: Ghost has detected corruption in the image file. Please perform an integrity check on the image. If this problem persists, contact Symantec Technical Support at http://service.symantec.com

Also, to determine the level of DOS from the boot disk, I booted to the boot disk and ran the 'ver' command. The output is:
"windows 98 version 4.10.2222"
I am not sure if this is the best way to determine the version of DOS - so if you have another method that would produce a more accurate DOS version please let me know and I will try it.

Since we can re-image just by rebooting (sometimes several reboots) I am inclined to think this is occuring as a result of some network condition, or possibly the NIC on the server hosting the ghost images. I am less inclined to think it is the NIC because I have other ghost image servers that deliver to other targets getting the same problem.

If you have any thoughts - they are most welcome. Again, thank you very much for replying to this post it has been very helpful.

Greg,

Thanks for your answers. There's a few things that I can think of to try from here. First up, if this is a problem with the DOS networking stack probably the best way to isolate it is to try a new mapped network drive boot disk built with PCDOS (using GhostBootWizard) instead of MSDOS. The network driver will be the only common point in the network stack at that point, hence if problems persist they are more likely to do with another component. I'd be interested if an error does still occur with this boot environment whether it is the same or not.

Another option would be to try a GhostCast session and see if you still encounter problems. This would eliminate the use of file network sharing software from both client and server.

Finally some gigabit network cards have support for offloading checksum computation to the network card, this appears to be giving problems in some cases. One example is the following thread: http://bbs.ondemandsoftware.com/forum/printer-friendly.asp?threadid=2011
Hence it could be worth trying to turn off "checksum offloading" on the servers network card (if it is supported). This can be done on some network cards by going to "Network Connections|Local Area Network|Properties" then selecting "Configure" and select the advanced tab. Look for 'checksum offloading' (both TX and RX if it distinguishes them) and try disabling it.

Kind Regards, Robert.

Robert,
Thank you again for your very helpful suggestions. I will go ahead and run these tests shortly. We have recently made a change on the switch to communicate half duplex (instead of previously full duplex) to see if that effects the environment. Once I am fully aware of how that change effects the environment I will go ahead and begin testing with what you suggest. I am waiting to see if the decompression errors still occur while running at half duplex. If so, I will then move on to your steps. Once again, thank you & I appreciate your effort. I will be sure to update this message with any/all findings until I get this resolved.

Best Regards,
Greg