Wednesday, October 18, 2006


So, the last period of the day, yesterday, I spent connecting the aforementioned second-to-last classroom up to a GhostCast session (Symantec Ghost 8.0 is what we use to image the workstations) and was having very strange problems.

First of all, the NIC link lights were all flickering the way they should, network connectivity was there. However, every other time I tried to connect to the GhostCast server it said it couldn't find the session, and to check the server to make sure it was ready to accept clients. Grrrrrrr. Drop to the A:/> prompt, autoexec, and run it again and Bam!, it would work fine this time. (Sometimes I had to drop to the A:/> prompt several times to get it to work, but it would eventually work)

I have NEVER had problems connecting to the server before, so I was a bit wary. When I tried to run the session it claimed to be in progress, but no information was being sent. I left it overnight and this morning it has simply crapped out with an error (GhostCode 19922) that might mean the wrong NIC drivers (no), might mean that the client has 2 NICs (no), that the server has more than one IP address (no), or that the file has permissions issues (no).

It's my impression that this error code is one of those vague errors that could be just about anything. It's my impression that the problem is a network switch in there. I can run Ghost fine anywhere else. I found, this morning as I've been troubleshooting to figure out what the problem really is, that when I'm imaging a machine outside of the English pod, it goes at 400 MB/s or more!

I just self-censored a lot of not-very-constructive chatter that would have gone here.



Blogger Nigel said...

You're absolutely right about the 19922, it's just a generic catch-all (as are most of the reported errors related to networking - by the time things filter out of the internal network API layers to the cloning world there's not a lot of specific context left to report) and some of the timeouts inside there are unreasonably long.

It'd be good to dig into the switch side, because there clearly is some packet loss going on. The trouble is fingering the real culprit; it could be a switch, a dud cable, or something we're starting to see a bit now is IRQ conflicts between SATA host adapters and the network cards. Lots of places to look.

If you don't have any immediate joy do drop a us note over at our support forums at for the current version.

The technique-of-last resort at that point would probably be for me to ask you to collect a packet trace using WireShark on the GhostCast server end for me to poke through (just the last 10Mb or so of traffic leading up to the failure is what I'm after, although more isn't necessarily a problem) so I can verify what that the server end of things is seeing and what I can infer from that side of the conversation.

I don't recall if we included a 32-bit executable in 8.0 (I have a feeling that it didn't get bundled in until 8.2) which you could try with a Windows PE boot CD. The thing about the 32-bit version is that it helps distinguish between things on the client machine (DOS driver issues, IRQ assignment conflicts, and the like) and real network problems.

6:20:00 PM  

Post a Comment

Links to this post:

Create a Link

<< Home