Ghost Solution Suite

Move to the correct forum for you......

For nine yeras I have been using a Floppy Disk to boot DOS and load Norton Ghost 2003 with ...

 GHOST.EXE -clone,mode=copy,src=1,dst=2,szeE

 This would clone SCSI Disk ID #0 (top) to SCSI Disk ID #1 (bottom).

 There are only two drives in the Dell PW650 computer during cloning.

 Nothing has changed, still Win Server 2000 O/S

 Top drive is still SCSI ID #0 (production) and bottom drive is still SCI ID #1 (backup)

 But now all of a sudden it clones in the REVERSE direction!

 The Norton Intergrity Check works backwards, as well.

 WHY? HOW?

 I even RESET the BIOS to Factory defaults - No affect still clones in reverse.

 Now I can change the -clone command to "src=2,dst=1" and it works but WHY?

Something has clearly changed.

Have you always successfully imaged the Dell PW650 before, or is this a new bit of hardware?

Have your SCSI drives always been identical in size?  Are they actually SCSI or just an emulation?

Does DOS correctly report the SCSI drive letters and more importantly, the correct size of the SCSI disks?

Bottom line is that DOS has severe limitations when it comes to working with modern hardware as, for example, it has no SATA support and it cannot handle really large disks as there is a limit on CHS addressing due to the number of bits available. Therefore you may find it wise to move to WinPE.

Yes, clearly "something" has changed.

This "something" eludes me.

I use ONLY Seagate Cheetah ST336753LW Ultra U-320 SCSI Drives.

The SCSI controller is built-in to the Dell PW 650 motherboard.

The GHOST has worked perfectly, every month, since Nov 2004.

Just checked, in DOS, there is no C: or D: Drive - not sure there ever was.

I just boot the Floppy and run AUTOEXEC batch to launch GHOST with command line.

Was ... "GHOST -clone,mode=copy,src=1,dst=2,szeE" 

Now it must be "GHOST -clone,mode=copy,src=2,dst=1,szeE" <<<- HUH?

I verified Drive ID's have switched in GHOST using Integrity and watch which HD Light up.

I have SCSI ID #0 HD in top bay (production HD), was "src=1", now "src=2"

I have SCSI ID #1 HD in bottom bay (back-up HD), was "dst=2", now "dst=1"

SCSI Controller is SCSI ID #7 (all info per BIOS start-up)

I only run with Production Hard Drive SCSI ID #0 in the Top Bay.

I always remove the Back-Up SCSI ID #1 HD from the bottom bay and store in vault.

Do you have an existing system that was configured "correctly" in the past that you could use as a test machine?  My initial speculation is that something has changed either on the base system or within the SCSI drive firmware that is affecting the way that LUNs are allocated.  Its been a while since I worked with SCSI drives but back then there were jumpers that had to be set to allocate the LUN, but is this still the case or is there now an "automatic" option? 

What happens if you switch the top and bottom bays on a new machine?  There could be a hardware change in the DELL which is causing the two devices to be reversed. From my experience of DELL machines in corporate environments, one can never assume that two machines with the same model number but from different delivery dates actually have the same internal hardware.

My strategy therefore would be to try and evaluate old and new DELL hardware and old and new hard drive hardware and see if there is any correlation between the emergence of your problem and the revision of hardware.

Edt,

   The plot thickens ...

   Actually, I do have two (almost identical) Dell Precision Workstations 650's. They are identically equipped and have identical MB's except for BIOS A04 vs BIOS A05. Both computers have now "flipped" their GHOST Drive Assignments, after years of use. About one year ago the first Dell PW 650 computer "flipped" and now the second Dell PW 650 computer has "flipped" two weeks ago! That is when I said to myself, "I need to discover the root cause of this problem".

   I install No Windows Updates, No Software Updates, No Firmware Updates, No Hardware Updates, No Updates what-so-ever. These two computers are part of a PLC Industrial Control environment and they run a single Industrial Control Application. There is no email, no internet, no other application on these two computers. And the user is severely "locked-down".

When the BIOS boots ...

The Top SCSI Bay still displays "SCSI ID = 0" (HD always present) 

The Bottom SCSI Bay displays "SCSI ID = 1" (HD only present during back-up)

The SCSI ID is set by the BAY, not on the Hard Drive.

I have four indentical "cloned" SCSI drives.

Any HD inserted into the Top Bay is SCSI ID #0.

Any HD inserted into the Lower Bay is SCSI ID #1.

Maybe, my question should be ...

How are the GHOST "src" and "dst" values assigned when I have a SCSI 0 HD and a SCSI 1 HD?

GHOST runs using MS-DOS 5.0 Bootable floppy disk.

Am I guaranteed that ...

GHOST "src=1" device is always SCSI ID #0 ?

GHOST "dst=2" device is always SCSI ID #1 ?

The definition of the Ghost clone switches can be seen here: http://service1.symantec.com/SUPPORT/ghost.nsf/d87bb6ce0bde286d88256d6a00452701/6377b07cce1c0c2b8825666a0071dd8b

The problem I perceive is that there are different ways of assigning drive numbers. Are there any other drives in the DELL machines especially any AT or SATA devices, or peripherals with block storage within them?

Although the SCSI LUNs may be 0 and 1 at the SCSI interface, does this remain true at the bios level?

How does your DOS boot mount the SCSI controller?

Generally, a system bios will traditionally mount any IDE devices, or IDE emulating devices first, so the logical drive numbering may be affected by non-SCSI devices. Since SCSI controllers usually have their own bios as an extension to the system bios, any devices on the SCSI bus get assigned drive numbers after devices natively supported by the system bios. Drive numbering is of course entirely separate from drive letter assignments under Windows - it is, for example, entirely normal for drive number 4 to be the boot drive with the drive letter C:\

I can only speculate but perhaps the assignment of drive numbers is controlled by which drive goes ready first, and where you have different revisions of drive electronics, chances are that they will have different boot times to readiness, especially where they are "green" technology which attempts to limit maximum power drawn.

If you have a WinPE boot device with appropriate SCSI drivers, you could boot to the command prompt, run DISKPART and then type

LIS DIS  (ie list disks)

which will list the visible disk drives in order of assigned drive number.

The great strength of WinPE is that it supports NTFS natively and you can run WMI commands, which facilitates identifying the source and destination drives explicitly. Unless you can determine exactly what is causing the random nature of src and dst assignment, I would suggest that a cloning scheme that checks which drive is which and reacts accordingly is going to present the safest way forward. It could be as simple as placing a flag file on the root of the image source drive and then checking which drive has the flag file present when the system is booted, and then branching to the appropriate bit of batch code.

My gut instinct is that this problem relates to hardware revisions and/or timing issues as I've mentioned earlier, and thus it may be difficult to find a simple solution which is reliable.

EdT,

"...The definition of the Ghost clone switches can be seen here ..."

Are these not the correct "switches" for CLONE Disk1 to Disk2 ?

GHOST -clone,mode=copy,src=1,dst=2,szeE

That was the command line until, one day, the src and dst "flipped" on each Dell computer.

My SWITCHES question was ...

Is SRC=1 aways SCSI ID #0 and DST=2 always SCS ID #1 ?

I assumed this would be fixed sicne there have been no changes to the computers.

".... Are there any other drives in the DELL machines especially any AT or SATA devices ..."

No other Hard Drive in the computer unless I am backing-up.

There is an Internal Floppy Drive - always been there.

There is an Internal IDE CD Drive - always been there.

"... I can only speculate but perhaps the assignment of drive numbers is controlled by which drive goes ready first, and where you have different revisions of drive electronics, chances are that they will have different boot times to readiness, especially where they are "green" technology which attempts to limit maximum power drawn ..." 

Hmm, very good point but why would this take 9 years to manifest itself?

The BIOS Scans for ID's from 0 through 15 on the Internal SCSI Contoller card on POST.

So if I swap SCSI HD #0 and #1 in the bays then the problem would be solved?

TESTING now ....

Sorry, swapping physical drives does not fix problem on either computer.

PER BIOS POST ...

All 3 devices are LUN = 0

Upper Bay is always ID #0

Lower Bay is always ID #1 (present only during CLONING)

SCSI Controller Card is always ID #7

No changes there ever.

"...How does your DOS boot mount the SCSI controller?..."

SCSI is supported by the BIOS since SCSI controller is embedded on MB?

There is nothing on the MS-DOS v5.0 boot disk but GHOST command.

There is no C: Drive or D: drive from the "A:" prompt.

"... WinPE ..."

Sorry, I am not familiar with WinPE.

"...Unless you can determine exactly what is causing the random nature of src and dst assignment ..."

What has me stumped is once the Drive Assignment in GHOST "flipped", it stayed flipped.

This is not random.

I have booted GHOST, at least, 50 times in the past two weeks.

The GHOST Drive Assignment is now always "flipped", maybe forever?

The Firmware revision is DX10 on both ST336753LW SCSI HD's

"... I would suggest that a cloning scheme that checks which drive is which and reacts accordingly is going to present the safest way forward. It could be as simple as placing a flag file on the root of the image source drive and then checking which drive has the flag file present when the system is booted, and then branching to the appropriate bit of batch code ..."

The drives are a MIRROR / CLONE of each other making this more complicated.

And I do not have File Access to either drive from the GHOST Boot Floppy.

There is no C: Drive and no D: Drive when CLONING.

OK, there is no logical explanation for this, so it's time to go back to basics and work through possible hardware issues due to configuration. I don't know the specific DELL configuration for the SCSI bus, so I will work from the information I picked up back in the 1980's when working with one of the ex-Seagate guys who defined the SCSI bus when is was still known at the SASI bus.

One thing that concerns me in your last posting is that all the drives are at LUN 0. This should never be the case in my understanding of the SCSI bus as it is equivalent to having every drive in your system as drive C:\.  The SCSI bus allocates three pins to support LUN 0 to LUN 7 and each drive on a single SCSI bus should therefore have a different LUN set in the jumpers.  My personal preference would be to set LUN 0 for the boot device, LUN 1 for the next device, and so on. The only way that having all drives at LUN 0 would work is if each drive has a separate SCSI controller, which would be grossly inefficient in hardware terms.

The other thing I would check is how the SCSI bus is terminated.  Some SCSI drives have terminators installed which of course need to be removed if the drive is not the last one in the chain. Other implementations have a terminator separate to the drive bays, so any drives used need to have their terminators removed.  The normal setup has a terminator at the SCSI interface and a terminator at the other end of the bus, whether this is on the last device or just on the end of the bus cable. Having too many or too few terminators is going to cause excess noise on the SCSI bus and potential errors.

I cannot really explain why this would suddenly become a problem now, but I have seen similar issues arising in IDE systems where master and slave jumpers were not set correctly.  In these circumstances, the outcome is pretty much random even if it appears to be working correctly for a long time. However, a minor change can affect the electrical environment sufficiently to cause a new random default.  I'm not saying this is the case in your scenario but it is always a good move to ensure that the hardware configuration is exactly right and nothing is left to chance.

Finally, how about asking DELL if they have seen anything like this before?  Chances are high that they haven't, but you never know, and it might be something simple. Googling around is also worth spending a few minutes on, as I've found solutions to obscure problems this way in the past.

Let me know how you get on.

EdT,

There may be some confusion ragarding BIOS "ID" vs. BIOS "LUN".

When the BIOS POST runs it counts ID = 0 to ID = 15 for LUN = 0, only.

It is searching for SCSI Devices.

Then the BIOS displays this ...

ID   LUN   DEVICE        REV

== ==== =========   =====

 00  00    ST336753WL DX10

 01  00    ST336753WL DX10

 07  00    LSI Logic 1020/1030

Top HD Bay is SCSI ID # 0

Bottom HD Bay is SCSI ID # 1

SCSI Controller is SCSI ID # 7

I have verified jumpers and I am very sure of the above settings.

Both drives are on the same SCSI cable with Terminator on end of cable.

Since the BIOS and Windows 2000 are performing as expected by DELL,

they state "it is a GHOST problem".

I started "googling" this problem, a year ago, when the first computer flipped. Now that the second computer flipped from "src=1,dst=2" to "src=2,dst=1",  I was stunned.

If another SCSI Device had been added or found then I would expect ...

"src=1,dst=2" to change to "src=2,dst=3" <- Now, that I could understand but not "flipped".

In fact, I have even tried using a USB Boot Drive with FreeDOS instead of MS-DOS Boot Floppy.

In GHOST ...

Drive 1 = USB Drive

Drive 2 = SCSI ID # 1 (Bottom Bay - Backup HD)

Drive 3 = SCSI ID # 0 (Top Bay - Production HD) 

Dang, the SCSI drives are still "flipped".

So, I used this "src=3,dst=2" on USB Flash Drive and that did work.

I have already RESET the BIOS to Faoctory Default - no change.

I will continue to my research ...

Ah, I see where my thinking has gone a bit astray.

Am I correct that your drive is as described here: http://www.codemicro.com/support/disc/iguides/scsi/100148125b.pdf

If the drive is a type "LW"  (you put WL - was this a typo?) then the ID is set by the controller. If you are setting the ID explicitly by jumper, please indicate, but from what you stated earlier, it would suggest that the bays somehow differentiate the ID setting.  

If you are using the same version of Ghost that you have always used, then it is inconceivable that its function should "flip" arbitrarily as executables don't rewrite themselves in some sentient manner, so the problem lies elsewhere despite DELL trying to fob you off with the usual excuses.

If the two drives are truly on a single bus, and ID is set by the controller, how can you be sure which bay represents ID#0 and which bay represents ID#1 ?  If you swap the two drives around, does Ghost see them the other way around also?

As far as the operating system goes, any drive can be the system drive, so its correct operation under Windows 2000 really tells you nothing about which ID it's running from.

If you have the time, check out this article:

https://www-secure.symantec.com/connect/articles/readyadventures-winpe

The following articles describes the process of testing candidate drivers for hard disk interfaces, etc:

https://www-secure.symantec.com/connect/articles/do-i-have-correct-driver-winpe

(WinPE can load drivers dynamically)

It takes you through the process of building a WinPE boot device, and you can run Ghost from this in the same way as you run it from DOS. It's just a more modern command line interface based on the windows kernel.

Under WinPE's command prompt, you can run the DISKPART utility which can then be used to determine the order of disk drives using the LIS DIS command. WinPE also allows WMI code to be run, which can be used to extract things like serial numbers from the hard disks, so you can be absolutely sure which drive is which when dealing with two identical models.

I assume it's impossible to determine what factor(s) may have changed a year ago when the first drives "flipped" ? I would assume nothing changed as far as the Ghost version being used, or the source media, so the only thing left is the hardware, including BIOS revisions. 

Do you have any alternative makes of SCSI drive to try in one of the bays to see if this makes any difference?

Since WinPE can access drives on USB ports, having a WinPE boot environment would allow you to use an external hard disk to load an image from, and should make it even easier to distinguish which drive is which.

I've used Ghost 2003 with WinPE V2 and the combination works very well, so trying WinPE would at least give you an alternative environment to work with.

Aside from that, I'm running out of ideas, but if anything else occurs to me, I will post again.

Just goes to prove that DELL technicians don't know their systems particularly well.....

Found the problem  !

Press F2 during POST

Enter BIOS Setup

Go to BIOS Option "Hard Drive Boot Sequence"

Use +/- Keys to move SCSI ID # 01 BELOW ID # 00 in teh Boot Order List

ESC & SAVE BIOS

Boot the Ghost Floppy

SCSI ID #00 (top bay - production HD) is now "scr=1" 

SCSI ID #01 (bottom bay - backup HD) is now "dst=2" 

Problem solved ...

    Maybe this "flip" occurs when someone accidently boots the computer to Windows 2000 with both hard drives ( Production HD and Backup HD ) still in the computer after Ghosting? We should never do this. But apparently it has - twice - once on each computer!  I think, this improper boot-up adds SCSI ID # 01 to the TOP of the Boot Order List. Normally, the Lower Bay is EMPTY and therefore SCSI ID # 01 should never be in the Boot Order List. But "stuff" happens. When SCSI ID # 01 is automatically added, it goes to the top of  the Boot Order List. This does not affect Windows 2000 but it does FLIP the GHOST Drive assignment. Now that I have manually moved SCSI ID # 01 BELOW SCSI ID # 00, in the Boot Order List, GHOST should be good forever.

So, the answer to my GHOST question:

If I only have SCSI ID #00 HD and SCSI ID #01 HD then will src=1 always be SCSI ID #00 and will dst=2 always be SCSI ID #01 ?

The answer is a NO, not always!

You must check your BIOS "HD Boot Sequence" List !