Is it Possible to Rebuild RAID on PERC 5/i without knowing settings?

Nick,,

If the foreign is greyed out then the only way I can think of getting the array configuration would be to boot to OMSA Live, then run a dset and with that it should pull a controller log. Here is the links to both.

OMSA Live - linux.dell.com/.../OMSA64-CentOS55-x86_64-LiveCD.iso

Dset - www.dell.com/.../DriverDetails

Run the dset in the OMSA live gui and then you can mount a USB and then offload it. Or extract it there and then you will go to dell/log/controller# open that and then look for a section in the log that looks like the example and then cut and paste it in your reply. We should be able to determain the configuration from that.

Example -

ARs configured: 2

T98: Ar 0: size=22dc0000, activeLd=1, numPd=2, seq=0, PDs: 08(0a/8) 09(0a/9)

T98: Ar 1: size=ae980000, activeLd=2, numPd=8, seq=0, PDs: 00(0a/0) 01(0a/1) ff(0a/2) 03(0a/3) 04(0a/4) 05(0a/5) 06(0a/6) 07(0a/7)

T98: LD  0: L=1  SS=128  Size=22dc0000  NL=3763  Status=3  DT=1655  BT=2606, prop=[ID=00,dcp=01,ccp=01,ap=0,dc=0,dbgi=0]

T98:        span 0: sBlk=00000000, nBlk=22dc0000, ar=0

thanks for the fast reply!

when I go into the utility, the "Foreign Config" option is greyed out.

if I do a "retag" and select the wrong raid (say I select RAID 5 and its a RAID 1) any idea what would happen? when its retagging that is simply recreating the RAID data based off the drive (as I understand the RAID data is stored on the drives itself, right?) so if I guess wrong and it doesn't boot, could i simply go back blow it up and try another RAID setup?

how long should it take to "retag" the RAID once I select it? a few seconds? a few minutes? or much longer then that?

The memory/battery message will not  usually cause this on this generation of machine (the 8th generation machines are a different story).

With a PERC 5/i, you can usually recover the array by importing the "Foreign Configuration" on the drives.  In CTRL-R, highlight the controller and hit F2, go to Foreign Config and Import.  

If it imports successfully, then great - you can probably go ahead and boot the OS (or repair, in the case of corruption).  

If the import fails, it could be because you have an old, problematic firmware (older than 5.1.1.0040), in which case, updating the firmware can help the controller better handle and import the foreign config.  

It may also fail to import if the configuration is corrupt or incoherent.  

If the Foreign config is greyed out, then the controller has detected no valid configuration on the drives and your only option would be data recovery or possibly a "retag" (this WILL require knowledge of what exact RAID settings were used to configure the array(s)).

If it is critical that the information is recovered, your client should be informed that professional data recovery will run them in the thousands-of-dollars range and a professional should be contacted before doing anything.  Importing the Foreign Config will not affect drive data - it simply tells the controller to use the config on the drives ... if it can.

A retag only takes seconds, as all it does is set a header on the disks telling them what their configuration/position in the RAID array is.  It is not based on any existing configuration - either on the controller or on the drive(s) ... it is creating a new array independent of (and overwriting of) any other RAID configuration on the disk(s).  The important thing with a retag is that an array is configured withOUT initializing it (as you would do for a new array) ... you are simply hoping that the RAID mapping will make sense and work together once you retag the disk headers to amount to discernable data on the drive.

I'm not saying that if you guess wrong the first time that you can't have another shot at retagging with a different configuration and have it work, but I have never seen multiple retags work.  This could be because the configuration/data was already lost/corrupt or it could indeed be that you only get one shot at retagging.

Do everything you can to find out the configuration ... Chris' suggestion of checking the controller log to see if the layout was recorded is a good place to start.  Whatever the outcome, your client may need a lecture on the value of documentation and record-keeping :)

So, I attempted to retag the drives as a RAID 5, it seemed to accept it, and then the utility froze. (it wouldn't respond to any commands, yet when I hit num lock or caps lock the lights on the keyboard would go on and off) I let it sit for a while to see if it was doing anything.. but it was frozen. I rebooted it, and it gave the message that the controller recovered configuration but files in cache were lost. it then gave the same DIMM error and said to replace the DIMM. is it possible a bad DIMM caused the freeze and possible all of these issues?

I ordered a new DIMM and battery (as I said before) going to wait til these arrive before I try anything else

It was common for the memory/battery problem to cause the OS to not function on 8th generation servers (PERC 4e/Di), but I've never seen it with 9th generation servers - the OS should continue to operate normally even if the memory or battery were bad (the cache feature is just turned off).  You may have another problem with the controller (that could be manifesting itself as a memory/battery issue) that is causing the lockups and/or loss of configuration, but the memory/battery problem would not directly affect the RAID configuration, as that is not what stores the RAID config on the controller.  See what happens once the memory/battery are replaced.

Chris's idea of running Dset to help with the configuration is the best option, you really dont' want to use the multiple retag option unless you really thrive on slot machine odds, especially since your not even sure of the raid level type.

As to re-tagging, as long as you do not initialize you can retag to your hearts delight... years ago I need to figure out the config of a raid 5, constantly tried different disk combinations for  >8 hours before I resurrected the raid ( fun for the first hour, becomes agony after the forth during the early A.M.); regretfully I needed to figure out raid configs using retagging more then once. Mind you these retags were with 3-4 disk arrays and I knew the raids were raid 5, forget it with > 4 disks arrays, at that point it is time for an array recovery service . Personally I always save the the raid config to a file after I set it up.

"wait til these arrive before I try anything else" definitely

thanks for all the tips, I just got the new battery and DIMM, installed them. I tried tagging the drives as a Raid 5.. no luck.. then I tried tagging as a RAID 1.. no luck either... at this point im waiting for the OMSA iso to download (38 minutes to go..) I'll then try to grab a copy of the logs.... is it possible the original logs were wipes when the battery lost power? or is it possible I wiped the log when trying the Raid 5 and Raid 1?

OMSA Live is a modified CentOS linux OS.  MSI's are Windows installation packages.  Go to and download the 32-bit linux version.

thanks! I thought it was strange I had an msi.. didn't think ti would work on linux, but honestly im not a linux guy at all. downloading the correct version right now. I'll post back the log once I find it

thanks for the info, I downloaded OMSA and booted to it, but I can't get DSET to work. I loaded the MSI on a flash drive, I can see the flash drive but when I try to run the MSI it says "couldn't display "root/desktop/Dell_DSET_2.2.0.118.msi"

Any ideas?

I went to the site, and clicked "32 bit linux" I was then brought here:

www.dell.com/.../DriverFileFormats

only 3 options, 1 is a text doc, the other a PDF and the 3rd a linux download.. but the file name says x64... I went back to the link you gave me and tried clicking on the 64 bit version and it brought me to the same page.. so either this version work on both 64 and 32... or they don't have the 32 bit version up anymore..

gonna download it anyway and try it..