Broken RAID 0 after firmware update - Repair How-To

[idata]

I was running a RAID0 array with two X25-V drives, one with firmware 02HB and the other with the newest 02HD. I have been having some problems with the system, so I decided to update the other drive. I disabled RAID on my motherboard (which uses P45/ICH10R chips), enabled Legacy SATA mode, and powered down. I then booted to the update disc, it found both drives, said one drive's firmware was current, and asked if I wanted to update the other one. About 30 seconds after initializing the update, it reported that it had succeeded and the update was verified. I then powered down again, and after a few minutes entered the BIOS, switched RAID and Native SATA mode back on. The Matrix BIOS now reports the array as failed, and the drive that was updated is not marked as being part of an array.

I do understand that there was a risk of something happening, but I don't understand this. The update is non-destructive, so why would it change the array info on that disk? Or is the ICH10R simply not detecting it, maybe because of the changed version info? Either way, what a let-down. This was supposed to work OK, and while I haven't lost any data, I wasn't counting on having to do a complete reinstallation right-this-second. What's stranger is, I can't seem to find any other reports of this happening. Maybe I'm not using the right keywords, but you would think that having been around since late 2009 there would be plenty of them if it was a common issue with this update/updater.

From the brief information I've found so far, it's supposedly not possible to downgrade the firmware on these drives, so that's out. Is there anything else I can try before I wipe them and start all over?

[edit: see post 3 for solution]

[idata]

Just wanted to stop in and say thanks. I was able to follow your instructions and rebuild my Raid 0.

For some reason my bios returned to default. I think I may have a bad cmos battery, so it lost the raid config. I used this to solve it. One of my partitions was a bit wonky I guess, had to fiddle with testdisk for a while, but eventually got it working. Anyways thanks!

[idata]

Just dropping by from the recovered OS with a broken MBR and boot which resided in a broken RAID-0... Thank you.

[idata]

Well, it's been a while since I started this thread, and I'm glad to see a few people have had success with the fix. I had planned for a while to clean up the procedure a little - little did I know I'd need it again myself for another problem.

I needed to use a sanitary erase program for an older SSD, but the computer it was in did not support SATA. The application I planned to use (HDDErase) only works on integrated controllers, so it would not detect the drive plugged into the PCI-based card. I decided the fastest way to get it done would be to plug it into my ICH10R-based board and wipe it from there. To prevent any disasters I unplugged all the other drives, then switched the SATA mode from RAID to OFF (aka "legacy mode").

The program did not detect the drive, so it was a failed attempt. But what's worse, after re-attaching my drives and re-enabling RAID mode, the array status was shown as FAILED and while both disks were detected they were shown as "Offline Member". I tried several methods to rectify this, including fooling with the BIOS and changing cable order. The last attempt was a http://ubuntuforums.org/archive/index.php/t-1033869.html guide on the Ubuntu forums claiming that starting the machine from a LiveCD and installing dmraid (or running gparted) would revive the array. No success there, either.

I finally returned to the method detailed in this thread, and I'm glad to say that it worked for this issue as well. Until next time!

[idata]

@TGentry

Thank you for this excellent guide. There is one issue with this I would really like to get a definitive answer to.

The issue is described in another excellent thread running on this topic here

http://www.overclock.net/t/478557/howto-recover-intel-raid-non-member-disk-error/60 http://www.overclock.net/t/478557/howto-recover-intel-raid-non-member-disk-error/60

and it is that some users lost their RAID data after they re-built the RAID and re-booted into Windows to run TestDisk (on your guide this is at Step 3).

This was because the Intel Matrix Storage Manager initialised the re-built RAID.

Now I am not an expert on the inner workings of the Intel Matrix Storage Manager so I cannot be definitive about the cause but there is enough anecdotal evidence in this thread to warrant consideration if your RAID data is important to you.

It appears that to minimize the possibility of this catastrophic event, the Operating System used to run TestDisk to recover the RAID partitions should not have the Intel Matrix Storage Manager installed. The Intel Matrix Storage Manager should be uninstalled at the start and before the RAID is re-built. This applies in particular to computers where the Operating System is already resident on a non-RAID drive on the computer but should also be applied to an external temporary Operating System installation. It also seems that the Intel Matrix Storage Manager can be re-installed without issue at the end of the process (after Step 5 in your guide).

As this is an Intel forum, it would be great if there was some Intel(ligent) expert lurking out there who could log in here and explain fully how the initialisation process gets started and confirm if the above method is how it can be avoided.

I would like to add two further points of information if I may:

Point # 1

After and only after the completion of the recovery of the partitions (Step 4 on your guide), and before progressing further, there is an opportunity to use TestDisk to copy critical data to a non-RAID or external drive. This may be a good insurance policy against a failure of the next steps of the recovery procedure if you have critical files on the RAID that have not been previously backed up.

After using TestDisk to Write the partitions per Step 4 of the guide, on the Test Disk screen, use the up/down arrow keys to highlight the relevant partition and type p as directed at the bottom of the screen to list files and folders. Current files and folders are shown in white. Previously deleted files and folders are shown in red. You do not need to copy the red files/folders.

Use the on-screen instructions and the up/down/left/right arrow keys to navigate to the critical data folder and press c to copy.

At the copy Y/N prompt, by default Testdisk will copy the folder to wherever the TestDisk program is run from such as the testdisk-6.11.3.1.win\testdisk6.11.3\win folder if you are running TestDisk version 6.11. To copy to this folder hit Y.

If you want to copy the critical data folder to the root of the TestDisk drive, keep pressing the left arrow key to change the directory to the root drive letter of the drive and hit Y to copy.

Copying large folders will take some time.Repeat the copying procedure for other critical folders.

Point # 2

Like me, your RAID system may be on a computer that does not support the addition of another internal drive on which to install a temporary Operating System and does not come with an Operating System install CD to execute the repair of the master Boot Record (I have two Sony Vaio Vista laptops that came pre-configured with RAID 0 like this). One solution is to download and burn a bootable NeoSmart Recovery CD of your Operating System from here (cost is less than $10):

http://systemdiscs.com/?utm_source=neosmart&utm_medium=article&utm_campaign=Vista_Recovery http://systemdiscs.com/?utm_source=neosmart&utm_medium=article&utm_campaign=Vista_Recovery

To run the TestDisk program from a USB drive using the NeoSmart Recovery CD (if your are trying to recover your RAID system using TGentry's guide, this is Step 3 of the guide, you will have already completed Steps 1 & 2) do the following:

At the end of Step 2 of the guide, set the BIOS boot order set to boot first from the CD optical drive if it is not already set as first by default.

Connect a USB stick/thumb/drive that contains the TestDisk program. If the Operating System of the NeoSmart Recovery CD is XP, the USB drive will need to be connected before booting.

With the BIOS boot order set to boot first from the CD optical drive and the NeoSmart Recovery CD inserted, the computer should now boot with the Neosmart Recovery CD. Be ready to quickly press any key at the "Press any key to boot from CD/DVD" prompt. This may be critical in avoiding booting into an operating system where the Intel Matrix Storage Manager is installed leading to RAID initialisation and data loss as described above.

After booting, once the language page comes up, select Next and Repair your Computer.

No operating system may show or may show with errors. In any event click Next and Command Prompt.

Do not attempt to use the Startup Repair or Restore tools at this time.

At the Command Prompt, type cd\ and press Enter.

To find out what drive letter the USB drive is we can use the Notepad application.Type Notepad in the Command Prompt, press Enter, click File and Open, then click Computer on the left pane, this will show you the drives. Note the drive letters may be different than those assigned in the normal Operating System.

You can launch TestDisk from here as well.

Change the Files of type to All Files.Navigate to the USB drive and then the folder with the TestDisk executable file (in my case as I use TestDisk version 6.11) the \testdisk-6.11.3.win\testdisk-6.11.3\win folderRight click on testdisk_win.Click Open and use the TestDisk program per Step 4 of the guide.

The NeoSmart Recovery CD Repair your Computer Startup Repair function or Command Prompt function can be used to repair the Master Boot Record per Step 5 of the guide. Remove all USB connected drives before attempting the repair.

[APetr21]

It is 2015 and Intel chipset RAID controller (Intel® Rapid Storage Technology in my case with option ROM version 13.1.0.2126) still tends to lose RAID members after firmware upgrade. I have system built on MSI Z97 gaming 3 motherboard and I created RAID 0 volume on Z97 chipset ports from 4 SSD disks (it is used as system/boot disk). After MSI released new firmware for motherboard I installed it from UEFI BIOS. System restarted after firmware installation and SATA ports were reset to AHCI mode. After restoring SATA ports to RAID mode, RAID 0 array recognized only three SSDs as members and one SSD as separate disk not belonging to any RAID volume. Lucky me - I found this thread with detailed instructions so I recreated RAID 0 volume but disk was not bootable. Then I booted system from windows 8.1 installation CD and in command prompt run 64 bit version of TestDisk from USB key but results from several TestDisk runs were inconsistent so I tried to find another solution. My system used https://en.wikipedia.org/wiki/GUID_Partition_Table GPT partitioned disks so by design there should by partition table backup at disk end. So I put 64bit http://www.rodsbooks.com/gdisk/ GPT fdisk program to USB key and run it in system booted from windows installation CD. It found that both (main and backup) GPT partition tables where in perfect condition (there are checksums on disk for checking state) and only problem was missing very first sector (in GPT terms called protective MBR) that could be fully regenerated by the same GPT fdisk tool without any loses. So with GPT fdisk I regenerated this protective MBR (just by saving loaded from disk GPT partition table) and after reboot I got back to my intact Windows 8.1 system (there was no need to run any repair utilities). So this means that RAID creation process zeroes only first volume sector (512 bytes) which in MBR partitioning scheme (older or 32 bit systems) are very valuable thing and should be restored/repaired using TGentry provided steps 2 and 3 and with GPT partitioning scheme (new UEFI 64 bit systems) this overwritten sector is critical for system to recognize disk as GPT and boot but could be regenerated with simple GPT partitioning tools without any risks.