Optiplex GX270 and Symantec Ghost 8.0 Corporate Edition

(From my posting on Symantec's Newsgroups)

Ok, guys.  Here are my latest findings with this situation.
I swapped out the SATA drive for an IDE drive and the ghost boot partition works with the onboard Intel Pro 1000.
Ok, so to recap:

Ghost Corporate Edition version 8.0.0.999
Intel Network Driver Version: all recommended versions from this site and Dell's.

Working configurations with the Ghost Boot Partition:
PC-DOS, Network Card Adapter(non-onboard) and SATA Drive
PC-DOS, Network Card Adapter(non-onboard) and IDE Drive
PC-DOS, on-board Adapter and IDE Drive
MS-DOS, on-board Adapter and IDE Drive

Non-working configurations with Ghost Boot Partition:
MS-DOS, on-board Adapter and SATA Drive (just hangs, and same results with booting from floppy with this configuration)
PC-DOS, on-board Adapter and SATA Drive (errors out after long pause and displays a missing command interpreter error)

So, this is starting to smell like an incompatibility with the i865 chipset and Ghost 8.  Is there a -FNI or -NOIDE switch for ngctdos.exe?

If anyone has anything suggest, I'd appreciate it.

lol, and no I'm not buying 24 IDE drives :)

Well, you got further along than I did in getting anything useful out of Symantec.  I'm having the same problem, with one minor difference: I never get an error message after the MAC address, it just hangs.  I've spent the last two days going back and forth with a Symantec tech who has most recently dismissed the problem as a timing issue:

"...we have seen issues where the Virtual Partition will fail to boot but a machine booted with a floppy disk using the same drivers boots successfully. This is most commonly caused by a timing issue, since a machine will boot much quicker from a harddrive (Virtual Partition) when compared to the time it takes to boot from a floppy disk. Unfortunately, there's nothing Ghost can do to resolve this timing issue."

He also told me to download the latest Intel drivers for the NIC.

I haven't switched out the SATA drive with an IDE drive (we don't have any IDE drives lying around), so I wasn't able to make that breakthrough.  However, a different thread in this forum resolved with Symantec admitting to a chipset problem with Ghost 7.5.  In addition to providing a patch for 7.5, they said that the problem was corrected in 8.0 (something I am starting to doubt).

Full disclosure: my Ghost version is 8.0.0.984.  I've tried running LiveUpdate to get to your version (I think you said 8.0.0.999), but it says I'm up to date.

I've sent the Symantec tech a not indicating what I've learned here (I'd like to send another quoting your email, with your permission) and I'm hoping for something more productive.  I'm not holding my breath, though.

I was only able to get the 999 build by calling Symantec.

I do get a solid hang when I use MS-DOS to create the boot image(partition or floppy).

Try PC-DOS and see if you get an error message from the boot partition.

I've been talking to Symantec about and they're going to do so more research on it.

Sounds like an issue between the SATA controller and the onboard NIC having conflicting resources. (If a Dell Rep can verify this, I'd appreciate it)

Thanx for responding Fiservguy,

Tim

P.S. Feel free to qoute my e-mail on the working/not working results.

One more thing, which may or may not have anything to do with the actual problem:

The boot process dies (apparently for both of us) after the config.sys runs but before autoexec.bat runs.  You can confirm this by pressing F8 prior to boot and stepping through the boot process.  For me, it actually asked me if I wanted to parse the autoexec.bat file before hanging.

When you comment out the E1000.dos driver line in the config.sys it should finish without hanging......but you'll get bind errors for obvious reasons :)

Got the final word from Symantec on this issue.

It's a problem dealing with the motherboard sharing IRQ's between the newtwork card and the SATA controller.

So, they can't fix it.  They advised me to get a BIOS update(won't happen as I'm already running the current A03 version).

And I'm not going to bother to mention anything to Dell or Intel as they'll blame it on the fact that symantec is using a non-plug and play OS for their boot-partitions.

So, it looks like I'm buying 24 nic's to use in place of the onboard one.

I've been looking at this all morning with something bothering me, and it finally hit me:  Why is there a resource conflict when booting from the virtual partition, but no resource conflict when booting from a floppy?  What's different about the virtual floppy?  Can whatever is different be modified?

Did Symantec tell you what resources were conflicting?  IRQ, I/O, interrupt, a combination?  maybe the NIC (or SATA) can be moved...

(I don't have the luxery of buying NICs for my Optiplexes...On the other hand, I have few enough at this point that I can probably manually connect and multicast.)

Regardless of who wants to point the finger at whom, I would hope Dell and Symantec figure this out.  I mean, we're not talking white box PCs and fly-by-night software.  I have to believe this issue will start biting more and more people.  For all I know some multinational has already forced the two to solve the problem and they're not willing to share.

Why is there a resource conflict when booting from the virtual partition, but no resource conflict when booting from a floppy? 

Because the resource conflict is between the SATA hard drive controller and the network card, not between the floppy controller and the network card.

What's different about the virtual floppy? 

See above.

Can whatever is different be modified?

No

Did Symantec tell you what resources were conflicting? 

No

IRQ, I/O, interrupt, a combination? 

No idea

maybe the NIC (or SATA) can be moved...

Both are onboard devices.  If Intel would provide us with any switches to use with the protocol.ini to reassign resources......yes, I coud try that.

My problem is between the Serial ATA Storage controller and the Pro/1000MT onboard card.

The system works fine if I either put an external NIC card and/or use a drive attached to the Ultra ATA Storage Controller.

Try it with the SATA controller in yours and see if your results change.   That is.....if you have a SATA drive on hand :)

I've contacted Dell about this via their online form, have gotten one response saying that version 7.5 or above will fix the problem(I'm running 8.0.999).

At any rate, I've seen postings in this forum mentioning that RIS doesn't work with this combination of hardware either, at least since version A03 of the BIOS.  Several have fixed the problem by downgrading their BIOS, however if you have a system that arrived with the A03 BIOS you cannot downgrade, and I guess a few people have botched the BIOS on the motherboard by forcing it.  Bottom line, if you're trying to system on this machine that cannot redirect the IRQ's you're doomed to fail with some combinations of hardware.

So, I'm going to wait until June for the "rumored" follow BIOS that was mentioned in the other thread.

Link to the thread if no one believes me: http://forums.us.dell.com/supportforums/board/message?board.id=oplex_bios&message.id=6129

Also(to no one in specific), make sure you read the other postings in this thread before you respond to this posting.

Thanx

Hey guys. 

I had this problem with Ghost 7.5 and upgraded (at a different site) to Ghost 8.0.  I'm still having this problem.  Symantec said the same - must be a timing problem - but I believe it's an IRQ problem.

FYI - The GX270's on-board NIC is sharing (PCI) IRQ 18 with:

Ultra ATA Storage Controller

USB Universal Host Controller - 24D7

Pro/1000 MT Network Connection

If I could change either the Ultra ATA Controller or the Network Connection IRQ, I'm sure we could get it to work.  I don't have the luxury of buying IDE drives or disabling the onboard NIC and using some other NIC.

I know this doesn't solve the problem, but at least you know where the conflict is located.

Thanks for the new information.  So far, I've been fortunate enough to not have to do anything except throw the initial image on one of our Optiplexes, and we use floppies to put the initial images on.

I'm amazed this doesn't appear to be causing more problems.  Based on the information at hand, it is impossible to use Symantec Ghost's virtual boot features (all the good ones) with this model Dell.

Now all we need is a method to change the default IRQs on Dell's built-in components and we'll be set.

Or, at least given DOS drivers for the components involved that have switches to manipulate the IRQ's.

Hi,

I finally got Symantec (version 7.5) to work with the GX270 with the onboard Intel card. Here is what I did:

1. Downloaded the latest NDIS2 drivers for the NIC from Intel's website, and used them to create a boot disk. Actually, I'm using a bootable USB thumb drive since the GX270's in our environment don't have floppy drives. It shouldn't matter whether you use a floppy disk, bootable CD or thumb drive. Check out the instruction I wrote on how to create a bootable USB thumb drive here:  http://ucsu.colorado.edu/~shaher/Bootable_USB.html

2. Added the switch -fni when using ghost.exe. "ie. ghost.exe -fni ". This disables direct disk access. I don't why it wouldn't work otherwise, but who cares!

That's it.

M.Shaher

Information Technology Services

University of Colorado at Boulder