Ghost Solution Suite

GSS 2.5.1 on Dell XPS 9000s

I have tried this with multiple images. and in each case the image is captured from the master machine with no complaints.  However during the restore (onto another box) I get one CRC32 error.  If I ignore the error, the newly restored machine is able to boot (luckily the damaged file is not critical).

I have tried restoring the images on more than one destination machine (all have identical hardware), and I hit the CRC error at the same place.  This suggests that the image itself is bad, rather than a communication error during the restore.  Yet, no errors were reported when the image was created.

I just attempted a restore on one machine and got an error "image file contains corrupt data run".  I was not able to continue from this error, so the machine was not left in a usable state.

I have tried the restore from the ghost console as well as booting off of CD and manually connecting to a ghostcast server.  I have tried multicast as well as unicast.

Do I need to turn on some option to validate images as they are created?  I really need a valid image on all of my machines.

Hi Jhd,

This could be quite possibly due to a corruption of data either on the source drive or image that has been created. Please find the link below that might give an insight into how to get over this issue.

http://service1.symantec.com/support/on-technology.nsf/854fa02b4f5013678825731a007d06af/8f9035560423b67a8825734e0059c1a3?OpenDocument

Hope this helps!

Windows 7 auto runs its defragmenter, not that this should be a problem on a new Windows 7 install.  So I'm virtually certain that this problem isn't what I'm hitting.  The issue linked above is also an oldie  (GSS 1.0 and Windows 2000).  We are running 2.5.1 with Windows 7.

Correct me if I'm wrong, but aren't the CRCs in question created by the ghost client?  No matter how messed up the source disk is, a CRC32 should be created for each chunk.  Either the ghost client is generating an incorrect CRC, or it is damaged on the way to the server (and the server isn't checking), or it is damaged on the way from the server to the new machine.  The last possibility is that the ghost client might perform an incorrect CRC calculation.

I've spent most of the day imaging, restoring, imaging, restoring, in an attempt to spot some pattern.  I've tried 3 different network switches, I've tried multicast/unicast transfers.  I've tried the universal packet driver as well as the driver I downloaded from Dell (and added to the WinPE image on tthe CD).  I'm messing around with transfer speeds right now.

Update:  I found ghost64.exe on the server and have been able to repeatedly check all of the images.  So it looks like the image was created correctly, but is not being restored properly.

Hi,

If you are able to boot from the restored image, then it means the image is not a bad one. It can be because of  bad data within the image which can be ignored if not serious.

Use  -CRCIGNORE switch while restoring your image. Your issue will be fixed.


Regards,
Dilip Sebastian




--------------------------------------------------------------------------
Mark  as solution once you find this helpful in fixing your issue
---------------------------------------------------------------------------

Hi Jhd,

You could try running the CHKDSK utility on the machine that you are trying to create an image from as the bad sector might be residing the source machine. You could try this and then try to take an image. Even though the imaging might be complete, the issue of CRC comes in when we try to restore it. So could try that and then image the machine. And as Dilip has mentioned you could try using the swtich -CRCIGNORE during image create and restore.

Hope this helps!

As a test, remove the file in question from the machine you are imaging. If the CRC errors stop, then there is a problem with the file itself which warrants further investigation.
If the CRC problem moves to another file, then it would suggest that the Ghost image being created has a problem at a particular offset - and this in turn could be caused by a pattern sensitivity in the RAM on the machine you are using to create the initial image. So in that case try a RAM swap, or better still, try using a different machine to create the initial image from, and see if that makes any difference.

Note that "pattern errors" can affect any data handling device that buffers data in local or computer memory, so other components such as NICs might be implicated if it is not caused by a RAM glitch.

Thanks for the comments and suggestions, it is comforting to have someone to bounce ideas off of.

I assume the source image is correct, since it passes an image check on the server.  (When I use the ghost client on the server and access a local image).  Your
comments seem to focus on image creation (which is what I was thinking earlier).  But if the image check is a valid experiment, we must move to the restoration process in our thinking.  I tried 3 switches, and various cable drops during the restore and still get errors.  When multicasting to a pair of clients, both hit a CRC error at the same time (suggesting that the error was either in the received data, or the CRC calculation of the receiver).  Since an image check on the server did not hit a CRC error, we have a limited number of candidates:  ghostcast server calculated a bad CRC, server NIC, cable from server to switch, switch server is connected to.

Please note that I have attempted restores to multiple machines, so the liklihood that each has a hardware fault is remote.  These are new machines, and I have ran a battery of diagnostics on each of them before moving them into the lab for imaging.  For example, memtest 4.1 was ran against each of these machines for around 1 week, something like 200 passes were ran (they have 12G so it takes a while).  Prime95 was ran for 3-4 days straight, except for one machine that had an error (we were not able to reproduce even after another 2 weeks of prime95).   I'll run chkdsk on the machines anyways, although I don't think it is a particularly strong test.  Drive manufacturers typically have far better tools available.

I strongly disagree with the idea that a bootable image which had CRC errors is correct (or suitable for production)!  If a particular DLL is damaged, the machine may be bootable and work fine until that particular DLL is used.  I need confidence that there are no unpleasant surprises in store for users, this means all files need to be exactly as they were when the image was taken.

BTW, for the benefit of anyone else reading this thread having similar problems:  the answer to the question at the end of the original post was to run the ghost client on the server.  A "check" option appears under local operations, navigate to where the images are stored and you can perform some level of validation of an image.
This is needed functionality, and I wish it was easier to find (perhaps add it to the ghost console?)  At present, the only way you can know of the option is to browse the ghost install directory with Explorer and run "ghost32.exe" or "ghost64.exe".  These are not added to the program group by default.

Are all the NIC drivers bang up to date, or have you had a search on google to see if there are any known issues with current drivers. The other candidate for checking is any hard disk drivers that your boot system mounts, and the system bios.
The consistency of the CRC error across different platforms suggests a common point of failure. Do you get this error with any other machines or only DELL XPS 9000s ? 

Is there an option to copy the Ghost image to a portable USB device, boot a test machine from WinPE, and image it locally to see if the same error occurs?

Alternatively, try imaging the source machine using the imagex.exe tool that comes with WinPE and then restore this image to another machine and see if imagex gives any errors.

Finally, how about extracting all the files from the ghost image using Ghost explorer and using something like windiff to compare each file with the original source ?

The NIC driver is up-to-date:  I downloaded the driver from Dell and added it to the WinPE image used for the boot CD as well as the ghost console (ie it is in the machine configuration).  The storage drivers were similarly updated.  If this were a driver issue, would it be possible to take an image successfully from one of these machines?

These drivers are on the Windows image as well -- although even if I had random data on the master image I would expect it to be faithfully copied during clone.

I am only using XPS 9000s -- all identical hardware.  I'd rather not spend time imaging another model of machine when our lab isn't using them.  I will if I need to, but I'd like to avoid adding more variables to the problem at this time.  (Are there hardware issues with the other type of machine, are the drivers/bios up to date).

Imaging from a portable USB device is a good experiment, and I'll move that to the top of my list.  Unfortunately I have limited time to work on this today, but I'll be able to run some more experiments tomorrow.  At the moment the server is running the full chkdsk, so the lab is unusable.

The Windiff approach seems intractable.  I'm not sure how many files are on an image, but I'm going to guess more than 10000.

One quick update:

Chkdsk didn't find any problems with the driver the server is using for images.

I'm trying a peer-to-peer install, and it is taking forever!  1/20 the speed of the unicast transfer from the server.  This is between machines on a single switch.

Out of curiosity I performed another server-client install while the above peer-to-peer was going on, and hit my normal CRC error.  But the filename looked different from what I remember.  So one experiment I would like to run is to perform multiple restore attempts to a single station and see if the CRC error moves.

It might be worthwhile to look closely at the network hardware.  I tried multiple switches, but the cabling between stations might be worth a look.  Isolating the server on a switch by itself with cabling going only to stations involved with the imaging might be a useful test as well.

I'll be disappoined if this is the problem, as the machines are able to send other traffic over the network without issue.  The ghost client uses TCP right?

I could have swore that I posted another update yesterday...

The peer-to-peer completed without error (although it took forever).

Client-server generates one CRC error per restore, yet the affected file changes.  One time a CRC error may occur when restoring file X, another time file Y.  So my suspicion was confirmed there.  Given that no single file consistently reports a CRC error, and given that the image verifies on the server, I am thinking that there is no problem with the source image.

I tried a restore with the client and server on an isolated network.  Their own switch, new cables.  Restores still fail as before.  My last test involved setting a bandwidth cap of 100MB/min, no changes there.  All network hardware in this test was gigabit/cat6.

I have been reading these posts with extreme interest, we have a similar situation with a non-production environment. The environment worked fine when we were using WinXP as the main OS of choice, however now that we have moved to WIN7 we are now encountering the CRC message during restore, and as stated in earlier posts if we ignore the message the image will restore and boot, however as you can appreciate it doesn't provide a confidence that  the image restore will be robust enough for long term use.

I am at a loss as to what the issue may be, so I will be looking forward to see if anyone has some ideas on this matter.

I'm also experiencing the same issue on a Lenovo M57, NIC is a marvell yukon.
If i ghostcast between 2 pc's, the image is fine, however if i try to deploy it using the console it fails with the CRC/data run error
I'll try with the -CRCIGNORE command

Hi,

CRCIGNORE would ignore the errors that might come up but the fault would be present in the machine to which the image has been restored.

Hope this helps !