Video Screencast Help

error message ghost 8.2: Abort 19913, unable to start TCP/IP

Created: 13 Mar 2007 • Updated: 21 May 2010 | 3 comments

Hello all,

I have a problem with the ghost

My configuration is:

Windows 2003 server with DHCP, Domain controller, Wins, ghost 8.2,RIS,DNS. Every thing seems to work correctly, with a client running windows xp, I?ve got an ip from dhcp, can join domain etc...

I follow, step by step, Microsoft and Symantec guide to install correctly ris and ghost cast.

When I boot from network, just before dhcp give an ip, the network chipset is detected as RTL8139(x)/8130/810X;

The ris work fine, I can boot from network and launch a windows xp installation.

I installed all application I need on my Nec ml4 computer and would like to make a ghost image to deploy it on many post. I create with the boot wizard a image with the appropriate setting, called rtl8139, (ris Microsoft boot, selected RTL 8139 cards, using pc dos, let dhcp give an ip etc..)

I launched ghostcast server and choose create a image. I boot from the client, the dhcp give it an ip, the ris ask me a user that has the correct right (I used domain admin) and then the ris menu appears. I choose rtl8139 and then the client boot and ghost is launched. At this point whatever I chooses under ghost cast (uni/multi diffusion ) I've got always the same error

Abort 19913, unable to start TCP/IP
Can't find DHCP server
Possible network setup problem.

I try several solutions:
Adding several other driver from realtek/nec/gigabyte to the boot wizard
Trying some other drivers on the boot wizard (like pxe packet drivers)

The hardware configuration of the client is:
Powermate Nec ml4 :

motherboard gigabyte ga8siml

network chipset : realtek 8139

Both client/server are on the same hub (nothing else on the LAN can troubles them). i'm still on test so i m not on our LAN.

If I try to make a ghost image with a different computer (I tested with a powermat DT wich have a 3com network controller) it s working fine.

some other tips:
-the computer is present in the Active Directory after i pass the ris menu
-the computer is present in the dhcp (juste something strange, i have a ip but no hostname)

I search a lot with my friend Google and into this forum, but I didn't t find any issue, I suppose there is a sort of conflict between the ip of the dhcp give at the boot and the ip that ghostcast client try to get...

If someone has any idea, I take them (or something that could exorcisme me ;) )
(I hope my English is not so awful)

Discussion Filed Under:

Comments 3 CommentsJump to latest comment

Krish Jayaratne's picture

Hi David,

Thanks a lot for the detailed explanation.

Based on your post, you have done everything correctly. For Ghostcasting, we use a packet driver so there is no computer name involved. Having only the IP address in DHCP is correct.

Could you press F8 when client booting to DOS (When it says starting PCDOS) and run it step by step and see if there are any error messages when loading the network driver? (since DHCP has given an IP address, network should be OK but just to make sure)


David Arnold's picture

hello Krish and sorry not to answer sooner (lot of work this last days)

So i hit f8 at the startup booting dos (i forgot that command, ms dos is not the os i use everyday). Everything was working exept the mouse driver, i didn t plug it (i ve got 'mouse driver not installed"). I was so desesperate that i plug a mouse, booting and.... it s work!!!!
I make several test (with and without mouse) and my conclusion is (you surely not belive me) with a mouse pluged it's working, without a mouse pluged i got the error message 19913!

I would like to understand how a missing hardware (not related with network) can cause a ghost error related with network (the dhcp tcp/ip error)?

in conclusion, i eat my mouse!

Thank a lot Krish for you answer it s helping me a lot (now my ghost working fine)

Krish Jayaratne's picture

Hi David,

Good to hear that the problem is solved, and thanks a lot for reporting back.

You are correct to say that we won't believe you :-) becasue this is a very strange situation.. We haven't head this before, but it could be due to an interrupt chaining or something. We will investigate it and thanks for telling this.