Pushing Image to Dell Latitude D630 fails three times in ten.

[Migration User]

Hi,

 

I have a problem pushing images to the D630.

It fails in roughly 3/10 cases, on a Unicast.

If I try to multicast, then one of the clients will drop off, all the others will wait for many minutes, before eventually carrying on. (Until the next client drops off, etc.)

If I use "force Unicast" then it works better, but roughly 3/10 still drop off. However the others finish more quickly.

I'm using UNDI drivers, since the Broadcom 57 drivers won't work at all.

All of my other models work correctly, and can use Broadcom drivers too.

 

I'd be grateful for any help.

 

T

 

[Migration User]

Hi,

There is couple of posts about Dell 630. When you say B57 driver does not work, does it fails to initialize or initializes, but fail to communicate?

Do you use UNDI or UNDI (irqcfg) driver?

Krish

[Migration User]

Hello!

 

I don't know if I will get a response about this issue, but I also am having tremendous amounts of trouble imaging a DELL Latitude D630 using Ghost Solutions Suite 2.02.

 

Like the individual that started this thread I cannot get the D630 to recognize the B57 drivers.  I contacted DELL and they had no answer, they simply sent me a link to download the same drivers I have been trying to use?!

 

I am connected thru a Gigabit switch, using XP SP2, and I use the Ghost Boot Wizard to create the .sys & .pxe files needed to process the GhostCast, and the 3Com PXE Server, as well. So, I tried to use the B57 drivers that are installed in the C:/Docs & Settings/All USers/App. Data/Symantec/Ghost/Templates/common, but they are not recognized either. 

 

The problem starts after the PXE boot selection is made, and the TFTP seems to be running ok, but when the process states "Starting PCDOS", the whole thing stops there, and nothing happens unless I restart the laptop?!

 

I was able to access the Multicast portion of the GhostCast server using the UNDI driver (not irqcfg), and finish a singular image job, but the drivers for the onboard Broadcom 57XX NIC are not intsalled on the laptop after the imaging process completes?  It seems that the issue is related to the drivers, and should be handled by DELL, but Ghost seems to fail to initialize the GhostCast server, or the drivers are not communicated correctly to the laptop.  I have exhausted all other options, and I am in the middle of a HUGE deployment consisting of about 100 laptops, and I cannot image them!?! AAARRRGGGHHH!!

 

Someone, Anyone, please help!!!!

[Migration User]

Hi,

As I understand, imaging is successful but when you boot the machine to Windows BC drivers are not installed in the system. Am I correct?

Installing drivers to the image is not part of Ghost functionality (though a tool, DeployAnywhere, will be available with the next version). If you need to install the drivers in Windows, probably the best approach is using sysrpep.

 

Krish

[jltrice]

A simple rule when dealing with Dell and network drivers:  Don't use the Dell version of the onboard NIC driver. 

The Dell version of the NIC drivers are genrally out of date and while they work fine for getting on the internet, for DOS level communication they genrally suck.  So, go get the latest NDIS DOS driver from Broadcom (since your using B57) or Intel depending on your machine model and use them update your drivers on your model machine and on your ghost boot disks.  I just recently deployed a batch of D630 using the Broadcom 10.63 driver and GX755 using the Intel 825660DM driver and had no failures.

[Migration User]

Thanks for the update, J!

 

I saw somewhere else online that if you are using McAfee AV, you should stop the port blocking to enable the D630 to respond to the drivers and enable the image?  Have you or anyone else heard of such a thing?

 

 

[Migration User]

Hi Matt,

 

Regarding the port blocking - this is not limited to Mcfee AV or dell 630. There were couple of posts in the forum about various FW products blocking ports in the server (used by GhostCast server). Even after opening the ports, some users said that they are blocked again after definition updates.

 

We add the exceptions to Symantec products and Windows firewall, but you need to configure other FW products manually.

 

There is a section in the manual specifying what ports are needed for the operation.

 

Krish

[Migration User]

Exactly the same issue I have.
This is taken from my today's email to Symantec

 

PXE boot issues with Dell Latitude D630

(using PXE boot image created from working DOS diskettes)

Product used Symantec Ghost Suite 2.5  

 

Symantec suggested following but nothing worked 

 

1. I normally use AHCI mode. The image I use was taken from hard drive that was in AHCI mode and is not compatible with ATA mode. Changing to legacy ATA mode for testing purpose did not help.

2. Updated BIOS to current  A12 version, did not help

3. Already had latest NIC Broadcom driver, did not help

4. UNDI driver is not available in GBW for floppy disk, only NDIS2 can be used. Boot order does not make difference.

5. Instead of using PC DOS, I created boot disk using Win98 boot diskette to load MS DOS to GBW templates. Did not help. 

 

Now what I found: 

 

While PC DOS boot floppy diskette (which I prefer) worked fine from floppy drive, MS DOS boot diskette was giving me error which gave me a clue what is going on.

So, my theory that I believe is right, is that Latitude D630 BIOS during boot copies its instruction to RAM memory, to the same memory addresses that boot diskette is trying to use.Since it is occupied, in the lack of available memory, the diskette stops loading and just hungs at certain step.

Why this BIOS instruction is different than in previous Latitude models I do not know, but it could be due to SATA drive introduction in this model.  

 

For MS DOS based boot diskette I found that adding [NOMOVEXBDA] switch to existing EMM386.EXE line in config.sys will resolve this problem.

Line in my config.sys is DEVICE=EMM386.EXE NOMOVEXBDA and it prevents EMM386 from moving the extended BIOS data from conventional memory to upper memory area.  

 

Now I have working PC DOS and MS DOS based network boot floppy diskettes with appropriate mappings and they work fine loaded from a floppy drive. I used both, either one or another diskette to create PXE boot image but I am still having problem booting through PXE boot. I believe that is the same BIOS memory issue I had initially with MS DOS floppy.

I guess that PXE loads boot image to different memory area than floppy drive loaded diskette and it causes system to hangs. So to summarize, the PXE boot problem is caused by memory conflict between BIOS instruction and DOS instruction.

 

Now knowing that software manufacturers design their products to be compatible to existing hardware, it should be Symantec's task to provide support and find a solution.It might be as simple as adding a couple lines of code instruction to DOS boot diskettes how to handle memory, so once it is used as base for PXE boot image, it handle memory in appropriate way to avoid memory conflict.

 

Maybe some people on this forum who know better MS DOS or have more time to do research could come up with MS DOS based PXE boot image with instruction how to tune EMM386.EXE manager through config.sys

 

Message Edited by roaddirt on 08-06-2008 10:07 AM

Message Edited by roaddirt on 08-06-2008 10:12 AM