Video Screencast Help

Error 19913 when using PXE boot

Created: 15 Jun 2006 • Updated: 21 May 2010 | 11 comments

I am using GSS 1.0 and 3Com PXE boot services to do network boot and imaging.

The target computers boot to the network normally, boot into DOS and run Ghost.exe. Then it says "Application error 19913 - Cannot find DHCP server. The funny thing is that if you exit Ghost and run it again with the same command line switches, it works.

I tried all the suggestions in the Symanted KB's and manuals with no luck.

Configuration:
DHCP server is running on a Netware 6.5 server.
PXE server is running on an XP Professional computer with DHCP Proxy enabled.
TFTP server is running on the same XP computer.
PXE / TFTP computer has a static IP address.
Target computers have an Intel Pro 100 VE onboard NIC with Intel Boot Agent.
Boot image uses MS-DOS. I tried PC-DOS with the same results.

Discussion Filed Under:

Comments 11 CommentsJump to latest comment

D J's picture

Hi Bryan,

If the PC is directly connected to a switch, in some cases it takes a while to establish the connection if the connection is re-started when loading the driver. Could you check if you just introduce a delay before running Ghost if it works?

Nigel Bree's picture

In order to figure out what's going wrong it would be handy if you could connect the client machine to a hub along with a second machine running some packet capture software. That way you can get a packet trace of the DHCP traffic the client machine generates (and is sent) so that we can analyse what is happening on the network.

Ethereal http://www.ethereal.com is a handy free packet capture tool you can use for this purpose.

Gilles Therreault's picture

Ive been testing Symantec Ghost 8.0 Corporate Edition and have had sucess on my test PC which has an Intel D915GUX motherboard. Now I'm testing on an Intel D945GTP motherboard and i'm getting the Error 19913.

I don't want to go into all the details, but just wanted to post a possible solution. On my D915GUX PC I had an IDE drive and on the D945GTP I had a SATA drive. As soon as I put an IDE drive on the D945GTP, the error 19913 was gone.

I now have another error, which may only be related to a bad drive, which I'm testing right now.

Now I have to figure out why the IDE drive works and the SATA drive doesn't.

Maybe this can work for you.

Gilles Therreault's picture

Further to my previous post, I just tried something that worked. On the Intel D945GTP motherboard in the BIOS there is an option in Advanced settings to change the drive from Enhanced mode to Legacy mode, which I did, and now my SATA drive works on the D945GTP with Ghost.

So basically for Ghost to work on my D945GTP I have to make sure the drive setting is Legacy mode for IDE and Enhanced mode for SATA.

Nigel Bree's picture

> As soon as I put an IDE drive on the D945GTP, the error 19913 was gone

That sounds to me awfully like there's a IRQ conflict between the BIOS assignment of the SATA controller's interrupt line and the IRQ assigned to the network card (or some similar kind of PCI-bus resource clash). It's possible that a conflict of that nature is blocking the receipt of packets by the DOS network drivers.

In the original poster's situation the second time Ghost runs it works, which seems a little odd unless some of the hardware-related startup and shutdown code happens to be unjamming one of these conflicts somehow.

Bryan Hardie 2's picture

I tried adding a 10 second pause to the autoexec.bat file but it still did the same thing. I was able to make it work by adding the -batch switch, then running the ghost.exe command again after the first one fails. This is what the autoexec.bat looks like:

GHOST.EXE -batch -sure -afile=NUL -clone,MODE=load,SRC=@MCE4000,DST=1,sze1=10000M
GHOST.EXE -sure -afile=NUL -clone,MODE=load,SRC=@MCE4000,DST=1,sze1=10000M

Nigel,
I'm not sure what to look for with Ethereal. Does it have log or something that I can paste into this discussion so you can look at it?

Thanks everyone,

Bryan

Nigel Bree's picture

That's a clever workaround. The fact that a time delay doesn't help certainly adds to the suspicion that it's something like an IRQ or other PCI-bus configuration problem.

> I'm not sure what to look for with Ethereal.

Well, what I'd be looking at is the flow of DHCP traffic the first time Ghost runs in this situation (if you can tweak the autoexec.bat in order to add a pause so you can start the capture at the right time to focus on this situation, that helps) and then comparing that to the second time Ghost runs and successfully acquires a DHCP lease.

For instance, the first time ghost runs it should be the initial DHCPDISCOVER, which your DHCP service should respond to with a DHCPOFFER. After that, Ghost should send a DHCPREQUEST. If there is some problem with the NIC driver, what I'm interested in is whether
a) no traffic at all is generated the first time Ghost runs, or
b) one or more DHCPDISCOVER packets are sent but it ignores the DHCPOFFER

As to the Ethereal logfiles, hopefully you won't be capturing a lot of data. Under the "File" menu is an "Export" option. You can export a plain-text log of the captured data with varying levels of detail and paste some of that here for us to look at (Ethereal can also save the complete packet trace in binary form, but we'd need to arrange for you to send it to us separately somehow).

Bryan Hardie 2's picture

As far as I can tell there only appears to be one DHCP sequence. Maybe the first time it tries to run it doesn't broadcast at all?

Here is the log:

No. Time Source Destination Protocol Info
27 21.759563 Cisco_bf:12:a5 Cisco_bf:12:a5 LOOP Reply

Frame 27 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Cisco_bf:12:a5 (00:0e:84:bf:12:a5), Dst: Cisco_bf:12:a5 (00:0e:84:bf:12:a5)
Configuration Test Protocol (loopback)
Data (40 bytes)

0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 00 00 00 00 00 00 00 00 ........

No. Time Source Destination Protocol Info
28 21.920460 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xdc72ea31

Frame 28 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: Intel_75:2c:61 (00:07:e9:75:2c:61), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol

No. Time Source Destination Protocol Info
29 21.920733 10.10.0.15 10.10.0.106 DHCP DHCP Offer - Transaction ID 0xdc72ea31

Frame 29 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: Intel_61:0d:3b (00:07:e9:61:0d:3b), Dst: Intel_75:2c:61 (00:07:e9:75:2c:61)
Internet Protocol, Src: 10.10.0.15 (10.10.0.15), Dst: 10.10.0.106 (10.10.0.106)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol

No. Time Source Destination Protocol Info
30 21.920922 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0xdc72ea31

Frame 30 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: Intel_75:2c:61 (00:07:e9:75:2c:61), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol

No. Time Source Destination Protocol Info
31 21.921531 Cisco_a4:f7:80 Broadcast ARP Who has 10.10.0.100? Tell 10.10.0.1

Frame 31 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Cisco_a4:f7:80 (00:0f:f7:a4:f7:80), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

No. Time Source Destination Protocol Info
32 21.923116 10.10.0.15 10.10.0.106 DHCP DHCP ACK - Transaction ID 0xdc72ea31

Frame 32 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: Intel_61:0d:3b (00:07:e9:61:0d:3b), Dst: Intel_75:2c:61 (00:07:e9:75:2c:61)
Internet Protocol, Src: 10.10.0.15 (10.10.0.15), Dst: 10.10.0.106 (10.10.0.106)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol

No. Time Source Destination Protocol Info
33 21.923195 Intel_75:2c:61 Broadcast ARP Who has 10.10.0.106? Tell 0.0.0.0

Frame 33 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Intel_75:2c:61 (00:07:e9:75:2c:61), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

Robert Chester's picture

Hi Bryan,

The SATA drive failing sounds similar to something I've seen before with a PXE boot image.

The 3Com PXE images can be configured to keep either "Base Code" or "UNDI" (Universal Network Driver Interface) driver or both after the PXE boot is complete and when booting DOS. Typically both "Base Code" and "UNDI" are kept in the environment. The keeping of "UNDI" is what enables the Ghost UNDI Packet Driver (undipd or Universal Packet Driver) to be used to control the network card. Are you using the Universal Packet Driver? Selecting "Base Code" to be kept is a good default as in some BIOS/PXE implementations the UNDI driver will only be kept if "Base Code" is kept.

In some cases keeping the Base Code as well as the "UNDI" driver can cause problems when running ghost or other DOS networking programs. This is because ghost/DOS and the Base Code are both trying to use the same network card and can conflict. Hence I'd suggest disabling the Base Code in your PXE image if it is enabled. WIth the 3Com PXE server this can be done by opening the PXE image with the "3Com Boot Image Editor". Edit the existing image, select"Advanced..." and then deselect "Keep Base Code in memory".

The scenario you describe isn't an exact match for what I've seen before with SATA and PXE, however it sounds close enough for this to be worth trying.

Regards, Robert.

Bryan Hardie 2's picture

I disabled "Keep base code in memory" like you suggested but it still has the same problem. If it helps, here is the autoexec.bat file:

SET TZ=GHO+08:00
prompt $p$g
\net\Undipd.com 0x60
echo Loading...
CD GHOST
GHOST.EXE -sure -afile=NUL -clone,MODE=restore,SRC=@MCE4000,DST=1,sze1=10000M

I can keep using the work around I mentioned above with the -batch switch. It just adds a little more time for the process to complete.

Harald_S's picture

I'm facing exactly the same problem. I'v done everything like described in this article: http://entkb.symantec.com/security/output/n2000103...
but when Ghost starts on the Client machine it stops withe error code 19913.

DHCP is running on a Linux server in the network.
Ghost Cast Server, 3Com TFTP and 3Com PXE Server is running an a Windows XP machine.

If I configure the image to use a static IP it stops with error code 503 and ghost code 19901 saying its unable to connect to my ghost cast session.