Ghost Solution Suite

Hi,

I am using GhostSuite 2.5 to create images for Windows 7.  I start the session from GhostCast Server (version 11.5.1.2266) and use the USB Ghost Boot Disk to boot up the laptops that I need to restore the image to.  I have been using this version for almost a year and have never had this problem before. 

I have "backup" images of 2 important laptops, just in case anything happened to them.  Well, they both had an issue this week & I am trying to restore the image that I had created for each of them a few months ago. 

Here's what I do to create the images.  I set up the session from GhostCast Server.  I do DISK images for Windows 7 with FAST compression.  I create the image on a local hard drive on the Ghost server (G: drive).  I do this all of the time, and don't have any issues restoring. 

Well, we ran out of room on the G: drive a few months ago, so I copied these 2 "backup" images out to a network share drive.  Once they were finished copying, I opened up each one, just to make sure Ghost Explorer opened it OK so knew the image was still OK after copying it.  Both images are very large (around 25 GB) so they took a long time to open off the network share drive, but they did open OK and I was able to browse folders in the image.  Since I needed room on the G: drive, I deleted the 2 "backup" images that I had just copied out to the network drive.

Now, a few months later, both of the laptops need to be reimaged.  So, I made room on the G: drive & copied both "backup" images from the network share drive back to the G: drive on the Ghost server.  I tried to do a restore (the same way I always do), but I am getting the following error on BOTH images:

Application Error 19240. Ghost has detected corruption in the image file.  Please perform an integrity check on the image.  Then I click OK, and get the following error in DOS:

ABORT: 19240, Decompress corruption

I normally use Multicast (I didn't realize there was a Unicast option), so I tried Unicast, but that didn't work either.  I tried multiple switches.  I tried to open the images off the G: drive & they open up fine.  I tried to COMPILE the image into a different named image, but got the same decompression corruption error on the restore. 

I try to run the integrity check, but a few minutes into it, I get an application error with the SEND or DON'T SEND buttons, so it will not finish the integrity check. 

I have the standard clean image that I put on all new laptops backed up on the same network share.  So I copied that back to the G: drive, and it restores fine.

Both of these laptops have software installed that is a royal pain to get set up & configured, which is why I ghosted them as a backup to begin with.  I just wanted to be able to restore these images instead of having to go through the time & hassle of reinstalling the software, etc.

Can anybody please help me so I don't have to rebuild both of these laptops from scratch again? 

Thanks...

From a number of past postings, it is my assessment that opening the images in Ghost Explorer may have led to the corruption.  There is no specific evidence of this I can point to, but corruption and the use of Ghost Explorer have been reported together on too many occasions for this to be entirely coincidental in my personal opinion.

Checking file integrity is best done using an external checksum utility such as MD5 if you have any reason to believe that a server to server data copy may not have generated a faithful copy.

You made a passing reference to DOS - I also recall a user posting that his experiments had shown that an image size around 27Gb was the maximum he could generate using DOS.  If you are currently using DOS, I would STRONGLY suggest moving to WinPE as this is sooooo much better with modern hardware.

Finally, I cannot advise you whether your images can be recovered in any way. This is an area where Nigel Bree, one of the former Ghost developers, would be able to advise you, so if he sees this posting he may be able to suggest a course of action.

Just to be clear, merely *opening* an image with Ghost Explorer cannot possibly corrupt an image  for the simple reason (easily verified with Process Explorer) that Ghost Explorer does not open the files constituting an image read-write but rather opens them read-only. Also note that Explorer works with read-only files on CD, so... the simple fact is that working with image data strictly read-only is what it was actually created to do, and image modification was a separate feature added years later with entirely separate code paths up and down the line.

So it *is* possible to corrupt images with Ghost Explorer, but it requires deliberate action. You have to do something like drag-and-drop a file into the image and then kill the Explorer process (or have it run out of disk space, or hit a hard media error) *while it's rewriting the image*. When you use Explorer to do a destructive action (such as dragging and dropping a file into it) the underlying image file is closed and then re-opened read-write so that the explicit request to modify the content can be actioned. But not before!

It's also very true that Explorer is not, and never has been, any kind of useful guide to whether an image is structurally valid. It processes the image file in an entirely different way to Ghost, which is why the -CHKIMG flag exists and has been documented as the right way to check an image for structural validity for basically as long as the Ghost product has existed.

The 90% reason for reported image corruption on restore (other than damaged or marginal optical media) is driver failure/bad hardware. Usually the images are not corrupt when tested with -CHKIMG on a host system, but during restore (whether via network or some other method) reports failure; the ones of these cases that have been resolved with different drivers (actually, the cause is usually some form of in-system data corruption in the chipset which is worked around by a particular driver aware of the chipset bugs).

Beyond this, there's a small residual number of cases which have been reported over the years which aren't easily explainable and in which an image fails to verify with -CHKIMG immediately on creation; unfortunately, no such case ever resulted in a customer willing to supply said image for developer analysis and recovery. It may well be that the underlying trigger is a subtle fault in Ghost which is data-dependent, and that a small number of particular image files contain a specific data pattern which causes a repeatable failure. However, no case like that ever resulted in a customer willing to supply an image to determine the cause (note that up to 2009 when the site was closed, we at Symantec New Zealand had a standing offer to ship image data to us at our expense for analysis and we would make a best effort to recover it at no charge).

For instance, if there was a subtle fault in the data-decompression code, it might live undetected and only appear in some specific images, because data compression is an innately data-dependent process with subtle edge cases. A fault which affected, say, one in 2^16 images because they contained a data-dependent boundary fault would be almost impossible to detect until someone ran into an image which was structurally valid but triggered that code path and failed to restore - once such an image which had such a fault emerged, discovering the cause using a debugger would be simplicity itself, but having the trigger data would be crucial for determining the cause.

Maybe such a category of error exists; it's certainly not beyond the bounds of possibility, and back in the day we'd certainly have been willing to pursue that possibility. Quite what the best approach now is, I can't suggest much. Ghost Explorer should be able to recover most of the files from the image (since as I noted above, it uses different techniques and code to process the data in the image file than Ghost does), but in general when -CHKIMG fails then Ghost has no recourse to continue and you can't use it. So, Explorer is the only route.

Unfortunately in terms of official Symantec support, I suspect now there's basically nothing. While I'm sure the current maintenance team would be more than willing to take on recovering customer data just as the original team used to be (the current team are good guys, committed to customer care, and understand how doing that kind of work is important for the health of the product) my understanding of their situation is that they can't take on work not explicitly referred to them from Technical Support - they are just too underfunded and understaffed for the job of GSS maintenance.

Nigel - are there any boundary conditions when creating large images using DOS ?  A customer reported that DOS images appeared to fail around the 27Gb size, but do you happen to know if this corresponds to a known factor or is just heresay?

I don't think so. We did our own internal tests regularly with DOS-based imaging on images *way* bigger than that from around 2004 onwards (as 2Tb disk arrays started appearing then, so support for >2Tb NTFS filesystems was a big push in the Ghost Enterprise 8.x releases). If there was a specific problem with Ghost and mere image size, we'd have heard about it bigtime sometime in the last 6 years.

Internally, Ghost's structure for abstracting platform differences like DOS files/Win32 files/GhostCast/direct NTFS over IDE/ASPI wasn't ideal, but it worked well enough that I really don't recall an issue like that in Ghost.

One image-file-size bug did slip through our QA during that era, incidentally, but it wasn't in Ghost. We changed versions of Visual Studio we built with in one release and for some reason one of the library functions in Visual Studio that took a 64-bit file offset was changed to silently truncate the value to a 32-bit offset. My memory (which is a bit hazy now, this was years ago) is that it bit Explorer when working with unsplit GHOs. However, that was the only error like that I can ever recall, and it appeared at the 2Gb boundary, and it was an "oops, here's a new executable on the FTP site" fix really fast after release.

Thanks!

Hi EdT,

I always open the images in Ghost Explorer afterwards and have never had this problem until now.  The only thing different was that I opened them off of the network share, which took FOREVER to open them since they are so big and it had to pull it off the network. 

I wasn't really in doubt that the server to server data copy might not have generated a faithful copy.  My being overly cautious is the only reason that I open them up in Ghost Explorer afterwards.  I only use the basics in Ghost & I was not even aware that this was not a valid way to test the integrity of an image.  I always assumed if it opened up, then the image was OK. 

Where can I download MD5 and is it easy to use? 

Thank you for your quick reply.

Hi Nigel,

Thank you for your quick reply, as well. 

I definitely wouldn't have dragged and droppeda file into the image or anything like that.  The only thing I MAY have done (I don't think I did, but it's possible) is clicking the X to close the image before it completely opened up in Ghost Explorer off the network drive since it took a really long time. 

So, should I be using the -CHKIMG flag every time I create a new image??  I

Or AFTER the image has been created?  If it's after, where do I run it from?  I see that the syntax is:  -CHKIMG,filename  --> Is the filename the whole path?  Like G:\Images\Laptops\HP\.....\imagename.gho??

Is the WinPE that EdT refers to the same as the "Process Explorer" that you are referring to? 

Currently to create a USB Boot Disk, I choose PC-DOS and then choose the "Network Boot Package" for MultiCasting & select the NIC driver package that I want to use.  When I boot the client laptop off of the USB Boot Disk, it loads the NIC driver and then boots into Ghost.  I am then able to connect to a session that I have set up on the GhostCast Server.

I tried to create the same scenario with the WinPE option, but it doesn't give me that "Network Boot Package" for MultiCasting.  I tried to select TCP/IP Network Ghost Client Boot Image, thinking it was the same thing, but it's obviously not.  It askes for the TFTP Root Directory & tells me I first need to configure my network boot server before I can boot from this image.  Excuse my ignorance, but I have no idea what this is talking about or how to configure it. 

As for why these 2 images are corrupted, I have no idea.  You had mentioned maybe a hardware/driver issue on the client laptop, but I was able to restore 2 good images to the same laptop, and the same 2 corrupt images failed on different client laptops. 

I'm really confused on what to do to prevent this from happening again in the future. 

Thanks again for your help. 

Just Google on MD5. 

Download sites like SourceForge often publish the MD5 checksums of their downloads so you can check them for integrity if something is not quite right. The tools are free downloads.

>Is the WinPE that EdT refers to the same as the "Process Explorer" that you are referring to? 

Not at all. WinPE is a command line boot system (a modern DOS) which is based on an operating system kernel. The version of WinPE used by Ghost is V2, which uses the Vista 32 bit kernel, so is able to use Vista 32 bit drivers for hardware compatibility. To all intents and purposes it is a cut down version of Vista which does not use Windows.

The reason more and more Ghost users are moving to WinPE is that DOS is very very old and does not have support for modern hardware. It is no longer commonplace for PC vendors to supply DOS drivers for modern LAN hardware. In addition, the hard disks shipping in new machines are all based on the SATA interface, which DOS is not able to communicate with. As a transitional measure, the BIOS code in modern machines usually supports a hard disk "compatibility" mode which allows a SATA hard disk to look like an older PATA hard disk so that older DOS programs can see the disk, but it may be necessary to enable this feature in the bios. (Terms like AHCI are associated with the SATA setting). Older SATA hardware is natively recognised by WinPE but as new chipsets are being released all the time, it may be necessary to add both the NIC and the SATA drivers for a new machine to your WinPE boot system using Ghost Boot Wizard.

Laptops tend to be in the lead with new hardware as the models change more frequently than desktop machines, and therefore tend to be the first to show the need for additional drivers in your Ghost environment.

This forum has a search function if any of the subjects I've mentioned are new to you, and of course you can Google the wider internet as there is plenty of information out there to bring you up to speed on the various technologies.

Hi,

I'm in the same situation, and I started researching winPE but it doesn't look like it will allow downloading/uploading of images between the target machine and the server. It looks like winPE is for booting up a client and running an actual installation of the OS on it, instead of popping an image onto the client machine from the server  (Or copying the client machine's drive to the server to be used as an image for later). Ghosting is much faster, and of course would be the preferred method in this case. Am I right about winPE?

Hi again,

OK, so I took your advice & figured out how to set up the WinPE USB Ghost Boot Disk (as opposed to the PC-DOS USB boot disk I was previously using).  All of the machines all have at least 2 GB RAM, so I chose the WinPE-512 version.

What I normally do is set up a session using GhostCast, boot off the USB boot disk, then connect to the session to image the computer.  This is what I was doing with PC-DOS and this is how I recently set up WinPE. 

I have 5 generations of HP laptops that I need to keep current images for. 

The oldest 2 generations (nc6400, 6910p) work perfectly fine.

The newest 3 generations (EliteBook - 6930p, 8440p, 8460p) all boot into WinPE fine.  They load Ghost fine.  But when I go to connect to the Session that I have set up on the GhostCast server, it hangs for about 5 minutes before coming back with the following error message:

"Unable to establish contact with session <session-name>.  Check that the GhostCasting server application is ready to accept clients!  (10030)

I'm guessing it's something to do with the newer hardware, but not sure if it's something in the BIOS or the NIC drivers or what.

Can you please help? 

Thanks again!

@Paul1234567

You are not correct about WinPE. WinPE is a command line version of Windows (Vista in the case of the GSS version), so can have drivers added to it for NIC and Hard disk chipsets. Once you have a network connection established to a server resource under WinPE, you can run any of the tasks you have mentioned.

After all, the process of installing an O/S involves transfer of files from a server resource (for example) to the local hard disk, so copying of any other filetypes should present no problems either.

WinPE is used very extensively for making and deploying images using Ghost, or the Imagex utility within WinPE, and you can run XCOPY from within WinPE to copy files around from one place to another.

If you are having specific problems getting any of this to work, please supply specifics.

For imaging operating systems, you do need to use something like Ghost, as a straightforward file copy of the system hard disk will not work as an image to create another bootable disk from.

In general, these problems are caused by the base GSS Windows PE having a driver load from about 2008, when GSS 2.5 was released (later revisions having been put off since Symantec decided to lay off everyone who worked on it in 2009).

Most of what goes into a Windows network driver is actually just recognising the internal hardware IDs that designers/manufacturers/system integrators assign to the chipsets. In any windows driver there is a plain-text file called an INF file which describes exactly what hardware is supported by the driver.

For many modern manufacturer like Intel, their designers strive hard to maintain software compatibility within an overall "family", so that often many different generations of Intel chips can actually use the same driver *code*. However, each individual device still has a unique ID (for good reasons), and so in Windows the INF text file has a list that matches up driver *code* with the actual *devices*.

So, there is lots of new hardware being produced now that have chips with only microscopic revisions to the earlier chips, but which have sufficiently different ID codes that the older driver set baked into Windows PE in GSS doesn't have the right table to match them up.

[ Of course, there are also manufacturers, mainly Dell in consumer world but also pretty much every server, which will take a standard Intel design and then mess around with it; often, such designs cannot run any driver other than one crafted specificically by the OEM to work around their design alterations, which are usually done to shave a tenth of cent or so per unit off their manufacturing process compared to the reference designs. ]

In general, the easiest way to do that is to figure out what hardware your machines have, and download a suitable driver *for 32-bit Windows Vista* for them from the manufacturer or from the chipset designer. At its hard, a Windows driver is an INF file plus the driver code, and you can use the Ghost Boot Wizard to take that driver and add it to its built-in Windows PE (generating a new boot disk) mainly so that Windows has an up-to-date INF file and can match up the hardware in the machine with some code to run the device.

There are other ways of doing this, such as a tool called DRVLOAD included in Windows PE which you can use when figuring out whether a driver you've downloaded really is the right one, but in the long run once you've identified the drivers you need, being able to build a custom version of Windows PE with the drivers you need is the best way to go.

It's a slightly tedious process to start out and it's unfortunate that it's necessary - particularly if you're stuck with a manufacturer that uses customised drivers but makes them hard to get hold of - but it's not complex once you get the hang of it.

Nigel, I didn't see drvload in winpe, is it available somewhere else?

It is a standard file in WinPE V2 - the version that is used in GSS 2.5

Just type DRVLOAD at the WinPE command line and see if it responds. If not, follow the process in the article here: https://www-secure.symantec.com/connect/articles/readyadventures-winpe  as all the boot images I have made with this process have DRVLOAD available.