From: Geoff on
On 17/05/2010 05:34, E wrote:
>
>
> I'm working on a Dell XPS-600 with a failed motherboard. The PC had two
> 160GB drives that I assume were set up in a RAID 0 configuration since
> it was a gaming PC. I hooked them to a new motherboard and tried to boot
> from the drives but it halts in POST because it can't find anything to
> boot from.

raid 0

named because of the amount of data you will get back if something goes
wrong

enjoy :)
From: Man-wai Chang to The Door (33600bps) on
> raid 0
>
> named because of the amount of data you will get back if something goes
> wrong

Whether one used RAID or not, one should always back up your data! :)

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (x86_64 Ubuntu 9.10) Linux 2.6.34
^ ^ 18:57:01 up 2 days 22:08 2 users load average: 1.02 1.03 1.00
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
From: kony on
On Mon, 17 May 2010 00:34:05 -0400, E
<eddie180(a)xlxoxcxaxlxnxext.com> wrote:

>
>
>I'm working on a Dell XPS-600 with a failed motherboard. The PC had two
>160GB drives that I assume were set up in a RAID 0 configuration since
>it was a gaming PC.

That is a strange assumption to make. Most OEM, and most
gaming systems, do not ship with RAID0.

Do you have other evidence to suggest it was a RAID0, for
example that you can't pull the drives out and read each
independently on another system after the HDD manufacturer's
diagnostics cleared them as functioning normally?


>I hooked them to a new motherboard and tried to boot
>from the drives but it halts in POST because it can't find anything to
>boot from.

Did you go into the bios and set it to boot from either
drive? I could assume you did, but at some point I could
assume a lot of things and overlook what has not been done
yet, since the problem remains meaning something hasn't been
done yet.


>
>I have gone into the BIOS and RAID setup utility of the new board and
>tried to set up a RAID 0 array hoping it would at least boot part way
>into the OS which did not work.

Don't ever do that. Do not ever ever set up an array trying
to get one back. (If it is an array at all). If the raid
controller is compatible it would recognize the array itself
with no "help" from the user, all that would be needed is,
if the bios had defaulted to non-raid/legacy emulation mode,
is to enable raid support.

As it stands, if it has written to the discs as I suspect it
has, you may be out of luck unless you can use a motherboard
with the same chipset to make the same array config on a
different drive, use a sector editor to show what was
written, then use a sector editor to write that to the discs
with the array... and if it didn't write to the same area on
the drive you may still have lost the data overwritten by
the new raid controller and attempt to make the new array.

If the data is valuable stop now and contact a data recovery
center detailing what you have done thus far.


>I have also booted a live Suse Linux CD
>to see if I could access them from there. Partitioning software in Suse
>says it can't read the partitioning information, but does show that
>there is a FAT partition labeled DellUtility. I have not tried to
>configure the two drive as RAID 1.

OK. Unplug one drive and see if it still shows the
DellUtility partition. If it does not, unplug that drive
and plug in only the other drive and see if it shows the
partition. If it can see the partition on either drive with
only one drive plugged in, that in itself is proof the
drives did not have a RAID0 array.


>
>I have no experience with RAID, but since the drives are the same size
>and this was intended by Dell to be a gaming PC I assume that they were
>originally set up as RAID 0.

Don't ever assume that. Assume the simplest and typical OEM
PC configuration and work from there, only assuming RAID
when something suggests it directly from evidence trying to
access the discs.

For the record, when you are dealing with a RAID0 array you
don't want just any random board with a raid capable
controller, you want a board with the same raid controller
chipset and ideally even the same raid bios (embedded in the
motherboard bios file).

For RAID1 it is a different matter, each drive can be
treated as a duplicate of the other and read by any
(non-raid too) controller unless it is a very strange
proprietary controller which is hardly ever the case since
there is no reason to deviate from the standards to do a
RAID1, except to lock people out of access and try to force
repurchase of the same hardware again which is a possibility
I can't rule out but thus far it is not at all common if it
happens at all in the industry.


>There is an option to set the stripe size
>in the RAID setup of the motherboard but I am afraid to change it
>because it warns that it will delete the MBR. The user probably has no
>back up of data.

Ask user if data is valuable. However, you are trying to
salvage an existing windows installation to reuse it on
another board with a different chipset, which in itself is
an operation which requires adding drivers to let windows
finish booting, and registry entries, which are probably
needing written to an NTFS filesystem which linux could do,
but not the registry AFAIK.

In other words, your best bet is trying to salvage the data
and starting with a fresh windows installation after
formatting the drives.

However, 160GB drives are fairly old by now (unless WD
Raptors which may not be yet), IMO when you are setting up a
system for another tour of duty it is prudent to get a new
drive so your work is not wasted by a drive failing in a
short period, nor the owner suffering additional expenses or
burden beyond the cost of the new hard drive... they are
already at the end of their expected lifespan even though
some drives continue to work years longer (but others
don't).

First step is ask the owner how valuable the data is and
what folders it is in. IMO, the data can't be too terribly
valuable since anyone can Google search for how to backup
data and find some way to do it if motivated by the value of
the data.
From: E on
kony wrote:
> On Mon, 17 May 2010 00:34:05 -0400, E
> <eddie180(a)xlxoxcxaxlxnxext.com> wrote:
>
>>
>> I'm working on a Dell XPS-600 with a failed motherboard. The PC had two
>> 160GB drives that I assume were set up in a RAID 0 configuration since
>> it was a gaming PC.



>
> That is a strange assumption to make. Most OEM, and most
> gaming systems, do not ship with RAID0.

They are indeed in RAID 0. I have since booted the system with a live
Open Suse CD, and ran a python script that reconstructed the RAID 0
array and copied an image to a third single hard disk. I am able to
browse the directory of the third disk. Data, WinXP system folders, etc.
I also am able to boot with the Windows installation. It's not very
stable of course, since it was expecting the hardware it was originally
installed on.

>
> Do you have other evidence to suggest it was a RAID0, for
> example that you can't pull the drives out and read each
> independently on another system after the HDD manufacturer's
> diagnostics cleared them as functioning normally?

The disks were detected by the motherboard firmware, and the RAID
controller firmware. The drives could be seen while booted into Open
Suse. But Linux's fdisk reported that one of the drives did not have a
valid partition table while the other one did. According to recent
replies to my posts and internet searches this seems to indicate that
the drives where together in a RAID 0 array.

I do have evidence now. Since the Python script took 64k chunks of data
from the two drives and put them together in sequence on to a third hard
drive. And that third hard drive can be read and booted from.



>
>
>> I hooked them to a new motherboard and tried to boot
>>from the drives but it halts in POST because it can't find anything to
>> boot from.
>
> Did you go into the bios and set it to boot from either
> drive? I could assume you did, but at some point I could
> assume a lot of things and overlook what has not been done
> yet, since the problem remains meaning something hasn't been
> done yet.

If I recall correctly, I did try to boot the drives as if they were not
in a RAID setup of any kind.

After I de-interlaced the RAID 0 image and wrote it to the third drive,
I disconnected it and I did try once more to set the two original drives
up in a RAID 0 array. This time I made sure the one with the valid
partition table was connected to the first SATA port. The system tried
to load windows. I got the Windows XP spash screen, but it restarted
part way into the load and restarted itself. I tried to boot into safe
mode from there. It showed the list of DLLs being loaded, then got stuck
on one and restarted again. Why does it restart, is it a RAID 0 thing?
Does it need the RAID controller driver for the new chipset?

>
>
>> I have gone into the BIOS and RAID setup utility of the new board and
>> tried to set up a RAID 0 array hoping it would at least boot part way
>> into the OS which did not work.
>
> Don't ever do that. Do not ever ever set up an array trying
> to get one back. (If it is an array at all). If the raid
> controller is compatible it would recognize the array itself
> with no "help" from the user, all that would be needed is,
> if the bios had defaulted to non-raid/legacy emulation mode,
> is to enable raid support.

I see your point it could be a risk. But now it seems with the drives
connected in the proper order, that it has a chance of booting off the
original two drive's RAID 0 setup. I'm wondering if I can do a repair
install of Windows on the old array and have it boot completely, and run
stable, with the users programs intact and able to run without fault.
I may try this on the single disk first.

>
> As it stands, if it has written to the discs as I suspect it
> has, you may be out of luck unless you can use a motherboard
> with the same chipset to make the same array config on a
> different drive, use a sector editor to show what was
> written, then use a sector editor to write that to the discs
> with the array... and if it didn't write to the same area on
> the drive you may still have lost the data overwritten by
> the new raid controller and attempt to make the new array.
>
> If the data is valuable stop now and contact a data recovery
> center detailing what you have done thus far.

As I mentioned above. I have a copy of the entire de-interlaced image on
a third 500GB hard drive. I can use this as the main drive if I can do a
repair install of Windows.

>
>
>> I have also booted a live Suse Linux CD
>> to see if I could access them from there. Partitioning software in Suse
>> says it can't read the partitioning information, but does show that
>> there is a FAT partition labeled DellUtility. I have not tried to
>> configure the two drive as RAID 1.
>
> OK. Unplug one drive and see if it still shows the
> DellUtility partition. If it does not, unplug that drive
> and plug in only the other drive and see if it shows the
> partition. If it can see the partition on either drive with
> only one drive plugged in, that in itself is proof the
> drives did not have a RAID0 array.

I didn't completely state everything that was reported to me by the
partitioning software in the my above paragraph. It read a valid
partition table on one disk but not on the other.

>
>
>> I have no experience with RAID, but since the drives are the same size
>> and this was intended by Dell to be a gaming PC I assume that they were
>> originally set up as RAID 0.
>
> Don't ever assume that. Assume the simplest and typical OEM
> PC configuration and work from there, only assuming RAID
> when something suggests it directly from evidence trying to
> access the discs.

Well, I think I did try to set them up in standard non-RAID as an
experiment, but I just had a hunch that it wasn't going to work out like
that.

>
> For the record, when you are dealing with a RAID0 array you
> don't want just any random board with a raid capable
> controller, you want a board with the same raid controller
> chipset and ideally even the same raid bios (embedded in the
> motherboard bios file).
>

Yes. Part of me now wishes I would have taken that route. It might not
be too late. There is a lot of games in the installation and I would
hate to give them a system back without all of it on there.


> For RAID1 it is a different matter, each drive can be
> treated as a duplicate of the other and read by any
> (non-raid too) controller unless it is a very strange
> proprietary controller which is hardly ever the case since
> there is no reason to deviate from the standards to do a
> RAID1, except to lock people out of access and try to force
> repurchase of the same hardware again which is a possibility
> I can't rule out but thus far it is not at all common if it
> happens at all in the industry.
>
>
>> There is an option to set the stripe size
>> in the RAID setup of the motherboard but I am afraid to change it
>> because it warns that it will delete the MBR. The user probably has no
>> back up of data.
>
> Ask user if data is valuable. However, you are trying to
> salvage an existing windows installation to reuse it on
> another board with a different chipset, which in itself is
> an operation which requires adding drivers to let windows
> finish booting, and registry entries, which are probably
> needing written to an NTFS filesystem which linux could do,
> but not the registry AFAIK.

Since the image is now on a single HD, and can boot in to safe mode,
what do you think the chances are of doing a repair install of Windows
XP, with the correct drivers for the new hardware, and having all the
installed games run without problems?

>
> In other words, your best bet is trying to salvage the data
> and starting with a fresh windows installation after
> formatting the drives.

Yes. This is what I would rather do. I don't have any specifics on what
data they are interested in. Other than 'games down loaded from the
internet' or something to that affect. I think we need product keys from
somewhere. In e-mails, the registry?

>
> However, 160GB drives are fairly old by now (unless WD
> Raptors which may not be yet), IMO when you are setting up a
> system for another tour of duty it is prudent to get a new
> drive so your work is not wasted by a drive failing in a
> short period, nor the owner suffering additional expenses or
> burden beyond the cost of the new hard drive... they are
> already at the end of their expected lifespan even though
> some drives continue to work years longer (but others
> don't).

I have considered that now that you mention it and am now leaning toward
just the single new disk if the two 160GBs are not Raptors. They are
Western Digital, but I'm not sure if they are Raptors. I need to run the
system again, take note of the drive model numbers and do a search.

The new disk and controller are SATA2. What would give the better
performance: SATA1 RAID 0, or SATA2 standard IDE setup?

>
> First step is ask the owner how valuable the data is and
> what folders it is in. IMO, the data can't be too terribly
> valuable since anyone can Google search for how to backup
> data and find some way to do it if motivated by the value of
> the data.

I don't know yet how many games were bought online. There are many many
games installed. They haven't yet mentioned any other data that is
really important.

Thanks for your suggestions
Eddie


From: Paul on
E wrote:

>
> Since the image is now on a single HD, and can boot in to safe mode,
> what do you think the chances are of doing a repair install of Windows
> XP, with the correct drivers for the new hardware, and having all the
> installed games run without problems?
>
> Thanks for your suggestions
> Eddie

If you have a copy of the contents of the 500GB disk, then there
is no loss (except your time), in trying a Repair Install.
A Repair Install gives you an opportunity to press F6 and offer
drivers on a floppy, if you have a storage controller on the new computer
for which there isn't a build-in driver already in Windows.

Repair install leaves the third party software alone. So the
games and game settings are all preserved.

A repair install, will disturb the add-ons in the OS. Examples are:

1) Internet Explorer. My SP3 WinXP install CD would try to put back
IE6. If the machine has IE7 or IE8 on it, the repair install might
not be entirely trouble free. Of course, there is no easy way to
know what is on there, when Windows is broken and you no longer
have the luxury of fiddling with it.

2) Windows Media Player. There are probably a few versions of that,
which are later than the version on a WinXP SP3 CD. My C: drive
has WMP 9 and I think they go up to at least WMP 11.

3) DirectX software. That is used by the games. Doing the repair install
could take you back to DirectX 9c. And due to a lack of a proper naming
convention, the software already on the machine may claim to be 9c.
There are updates released at regular intervals, and they add some
specific dated software to the install. If you find any game is
"broken", the game may ask for a particular file from DirectX, and
from that information (missing "April 2007..." blah blah), you can
track down the particular, dated update to supply the missing file.
It's not a big deal, as at least one site had a small collection of
DirectX 9c releases. A thorough effort would require starting up
each 3D game, and verifying the necessary system software was there
to support it.

4) It's always possible, that some Windows Live software might be
upset, replaced or disturbed. This list could be longer for all
I know...

To me, the biggest exposure would be the Internet Explorer, and
mainly because I'd have to spend half a day researching what
issues it'll cause.

This is a taste of the brain-dead advice Microsoft has to offer.
Don't they see the exposure here ? The user that doesn't have
a working Windows to be doing the uninstalls they're asking for ?
It makes using IE7 or IE8, detrimental, if you can't repair
install over top of them.

http://support.microsoft.com/kb/917964

Paul