Sign in with
Sign up | Sign in
Your question

AA-8 / Boot hangs at Verifying DMI Pool / RAID Conundrum

Tags:
  • NAS / RAID
  • Motherboards
Last response: in Motherboards
Share
June 16, 2006 7:24:32 PM

I have a homebuilt system (specs below) that just stopped booting all of a sudden, after working perfectly for 9 months. I usually leave it on 24/7, but it was a warm night so I decided to shut it off to keep the room a little cooler. Anyway, next morning I begin booting and get the dreaded hang up at Verifying DMI Pool Data message. I haven't changed anything on the system - no new cards, etc. It just stopped booting.

I have my main disk set up as RAID 1 (mirroring) with 2 identical 320 GB WD HDs using the onboard RAID controller on the AA-8 Duramax. I am running WinXP MCE. I can boot off of the WinXP CD, and after loading the RAID drivers from floppy, I can get to the recovery console and see that the data seems OK. Here are a few of the things that I think might be wrong:

1. master boot record (MBR) corrupted
2. RAID controller or MOBO in general failing
3. some other piece of hardware on my system failing and causing lockup

My suspicion is towards #1, but I'm a little nervous about trying the FIXMBR command. When I issue it, I get a warning to the effect that I have a non-standard MBR and FIXMBR might make partitions unreadable. I suspect that the this might have to do with the RAID functionality and it would be really stupid of me to take down BOTH harddrives with FIXMBR. The whole point of RAID 1 is that I'm fully backed up, right?

Does anyone have any experience with this or any other ideas?

TIA - Jake

---SPECS---
Abit AA-8 MOBO (with onboard Intel RAID)
Intel 640 EM64T 3.2 GHz
Sapphire Radeon X800PRO
2 x 320 GB WD SATA HD in RAID 1
1 x 320 GB WD SATA HD not in RAID (TiVo drive)
Happauge Dual Tuner card
2 x 1 GB DDR memory

More about : boot hangs verifying dmi pool raid conundrum

July 31, 2006 4:24:08 PM

Quote:
I have a homebuilt system (specs below) that just stopped booting all of a sudden, after working perfectly for 9 months. I usually leave it on 24/7, but it was a warm night so I decided to shut it off to keep the room a little cooler. Anyway, next morning I begin booting and get the dreaded hang up at Verifying DMI Pool Data message. I haven't changed anything on the system - no new cards, etc. It just stopped booting.

I have my main disk set up as RAID 1 (mirroring) with 2 identical 320 GB WD HDs using the onboard RAID controller on the AA-8 Duramax. I am running WinXP MCE. I can boot off of the WinXP CD, and after loading the RAID drivers from floppy, I can get to the recovery console and see that the data seems OK. Here are a few of the things that I think might be wrong:

1. master boot record (MBR) corrupted
2. RAID controller or MOBO in general failing
3. some other piece of hardware on my system failing and causing lockup

My suspicion is towards #1, but I'm a little nervous about trying the FIXMBR command. When I issue it, I get a warning to the effect that I have a non-standard MBR and FIXMBR might make partitions unreadable. I suspect that the this might have to do with the RAID functionality and it would be really stupid of me to take down BOTH harddrives with FIXMBR. The whole point of RAID 1 is that I'm fully backed up, right?

Does anyone have any experience with this or any other ideas?

TIA - Jake

---SPECS---
Abit AA-8 MOBO (with onboard Intel RAID)
Intel 640 EM64T 3.2 GHz
Sapphire Radeon X800PRO
2 x 320 GB WD SATA HD in RAID 1
1 x 320 GB WD SATA HD not in RAID (TiVo drive)
Happauge Dual Tuner card
2 x 1 GB DDR memory


First off http://www.com
puterhope.com/issues/ch000474.htm


Now, what I'd do, If at all possible, use that TiVo drive to backup all your data, by booting the windows CD (or if you're familiar with Live LInux CD s perhaps use one of them).

afterwords:

I'd start by disabling boot from floppy, and disabling the floppy its self (if you have one installed), Obviously you're going to need your CD / DvD reader. Check for lose HDD cables and such, what I do here, is just pull each individual cable lose, on both ends, and then re-seat them. re-try booting. IF still no joy, follow the steps on the website I linked you to, in an order that is most convient for you (hint you may want to start with the easier to fix items first)

A few other things you can try, and maybe even try first is setting the Plug and play OS option in the BIOS to yes (if your BIOS has said option), and forcing an ESD update, and of course make sure your BIOS reconnises your HDDs to begin with (which if you can see the data, I dont know why it wouldnt).

If everything fails, and it does turn out ot be a bad HDD or two, I would strongly recommend buying Seagate, as thier drives have 5x the warranty, and I havent even seen a bad Seagate drive in 6-7 years (and I see alot of HDDs). This isnt to say they never go bad, but by comparrison to say WD, they are much less likely to go bad from my experience.

Good luck.

[EDIT]

As an after thought another recommendation, would be to forget about RAID altogether, and just use that second drive to back important data up. I've had all kinds of bad experiences with desktop class motherboard RAID failing from time to time, and Have made my own personal PC life easier by forgetting about using it :)  This isnt to say that it doesnt work, and sometimes it works well for a long time, but if it ever fails, and fails bad, you're screwed.
July 31, 2006 8:31:31 PM

Wow...thanks for responding after to my ancient topic. I guess I should have posted when I fixed the problem. It turns out that my suspicion of #1 was at least on target. After booting to WinXP recovery console via CD and issuing BOOTCFG /list, I was astonished to find that no boot devices were configured! So then I just 'BOOTCFG /add' -ed my installation (which was detected fine in the recovery console) and all was fine. I may have FIXBOOT -ed as well, but I definitely DID NOT FIXMBR.

http://support.microsoft.com/kb/314058/ came in helpful.

I suspect that the MOBO had no role in the problem, and possibly your Seagate vs. WD rant is on target. However, nothing funny has happened since so I'm going to chalk it up to the phase of the moon or something.

Thanks,
Jake
Related resources
August 1, 2006 1:40:22 AM

Quote:
Wow...thanks for responding after to my ancient topic. I guess I should have posted when I fixed the problem. It turns out that my suspicion of #1 was at least on target. After booting to WinXP recovery console via CD and issuing BOOTCFG /list, I was astonished to find that no boot devices were configured! So then I just 'BOOTCFG /add' -ed my installation (which was detected fine in the recovery console) and all was fine. I may have FIXBOOT -ed as well, but I definitely DID NOT FIXMBR.

http://support.microsoft.com/kb/314058/ came in helpful.

I suspect that the MOBO had no role in the problem, and possibly your Seagate vs. WD rant is on target. However, nothing funny has happened since so I'm going to chalk it up to the phase of the moon or something.

Thanks,
Jake


That is wierd, and sounds very suspicious, you DO run AV programs(s) ?
August 1, 2006 12:36:10 PM

Yes, of course I'm running an AV program (scans every night!) and I'm behind a router firewall. I actually don't think it's all that weird. I've heard of boot records/sectors crumping all the time. I certainly encountered more than a few cases when I first started searching for help with my own problem. I think that the chances for something like this probably increase with a RAID configuration where it's unclear how the RAID controller manages the boot sequence. If the boot record is actually only on one of the drives (rather than both) and for some reason the RAID decides to switch primary drive, this would almost happen by default. I don't know if this is actually the case, but it's a theory at least. Thanks for you input.

-Jake
August 1, 2006 4:45:50 PM

Quote:
Yes, of course I'm running an AV program (scans every night!) and I'm behind a router firewall. I actually don't think it's all that weird. I've heard of boot records/sectors crumping all the time. I certainly encountered more than a few cases when I first started searching for help with my own problem. I think that the chances for something like this probably increase with a RAID configuration where it's unclear how the RAID controller manages the boot sequence. If the boot record is actually only on one of the drives (rather than both) and for some reason the RAID decides to switch primary drive, this would almost happen by default. I don't know if this is actually the case, but it's a theory at least. Thanks for you input.

-Jake


Well in theory, you could yank the primary, and have the secondary pick up its slack. Works for software RAID 1 in Linux, couldnt say how well hardware RAID 1 in windows would do though.
!