I Did a SmartArray 5Si Boo Boo

I don't know if this is recoverable or not, but I would appreciate some
advice. Someone here built a Windows 2000 Server system incorrectly and
placed the boot devices in a DL380 SCSI ID slots 5 and 6. Windows 2000 had
no problems installing to the logical drive at that location (RAID 1) and
Windows 2000 was booting fine there.

I decided to "clean things up" by moving the two drives over to SCSI ID 0
and 1 where they belong, assuming the SmartArray would see the new locations
and move them. No problem, the SmartArray announced the move but when
Windows 2000 goes to boot, I get "Non system disk."

No problem, I thought, the boot.ini needs adjusting, so I rebooted and moved
the drives back to the original location. Again, SmartArray announces the
move, and sees the logical drive in the original location, no problems.
But when Windows 2000 goes to boot, I am still getting "non system disk".

My pure guess here is that the data is still on the volume, but in the
course of the two moves back and forth SmartArray has assigned some new
logical SCSI ID number to the drive pair, and it was NOT able to recover
that ID. The Windows 2000 boot ini probably refers to the wrong SCSI ID,
hence the system can no longer boot.

Can someone educate me here about what may have happened? Any advice for
recovery? I'll go try to find a Windows NT boot floppy and pray.

--
Will

"Will" wrote in message
...
I don't know if this is recoverable or not, but I would appreciate some
advice. Someone here built a Windows 2000 Server system incorrectly and
placed the boot devices in a DL380 SCSI ID slots 5 and 6. Windows 2000
had
no problems installing to the logical drive at that location (RAID 1) and
Windows 2000 was booting fine there.

I decided to "clean things up" by moving the two drives over to SCSI ID 0
and 1 where they belong, assuming the SmartArray would see the new
locations
and move them. No problem, the SmartArray announced the move but when
Windows 2000 goes to boot, I get "Non system disk."

No problem, I thought, the boot.ini needs adjusting, so I rebooted and
moved
the drives back to the original location. Again, SmartArray announces
the
move, and sees the logical drive in the original location, no problems.
But when Windows 2000 goes to boot, I am still getting "non system disk".

My pure guess here is that the data is still on the volume, but in the
course of the two moves back and forth SmartArray has assigned some new
logical SCSI ID number to the drive pair, and it was NOT able to recover
that ID. The Windows 2000 boot ini probably refers to the wrong SCSI ID,
hence the system can no longer boot.

Can someone educate me here about what may have happened? Any advice for
recovery? I'll go try to find a Windows NT boot floppy and pray.

--
Will



sometimes its best to let sleeping dogs lie ....

did you take a full system backup (local drives and system state) before you
attempted this 'clean up'? I dont blame you, i would have been tempted to do
the same thing.

Boot from a smartstart CD and see if you can run the DAAD. It should be able
to interrogate the array controller and the drives to determine whom thinks
what is what. If the drives look good (like they are still pair members of a
1+0 config, then you can pop the drives and do a system erase which will
clear the config from the array controller. Then, pop the drives back in,
and let the disks teach the controller what thier story is.

It might only work with the disks in thier orginal positions.

Also, the ARC path in the boot INI really doesnt care about individual drive
ID's ... it cares about controllers, disks and partitions. Disks only
pertains to disk ID's when they are not part of a RAID set. With SCSI, goes
0 ~ 6, 8 ~14, with 7 usually reserved for the controller. For IDE, the first
designator is MULTI and not SCSI. But, you can still boot from a SCSI
controller if it starts with MULTI and not SCSI. Simple, no? hehehe

thus, SCSI(0) or SCSI(1) would differentiate between the controller channels
0 and 1. Disk(0) would be the first array found on that controller channel,
and PARTITION(1) would be the EISA volume (assuming you system had one).

Give the DAAD approach a spin and let us know how it goes.

- LC