If it's partition 3, wouldn't you by trying to assemble the raid on /dev/sda3 instead?  Make sure you set the partition to type fd for linux raid autodetection.

mb@host:~$ sudo fdisk /dev/sdi -l

Disk /dev/sdi: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6b7aa52b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdi1   *        2048      206847      102400   fd  Linux raid autodetect
/dev/sdi2          206848   234441647   117117400   fd  Linux raid autodetect

..where /dev/sdi1 is /boot, and /dev/sdi2 is my luks crypt volume and pv for lvm.

Use gdisk if/when doing gpt, acts largely like fdisk for mbr-based partitions.

Try just doing an auto assemble/scan, maybe your raid superblock got blasted...

mdadm --assemble --scan

I use gdisk if available, or make sure it is available, but like ubuntu installs are really stupid these days and don't make these available at install, but you can still apt-get install gdisk or mdadm to get them present to rebuild raids.

I spent a good chunk of a week figuring out idiosyncrasies with efi, gpt, raid, luks, and lvm.  Only thing it told me is everyone does something different between distros at this point.

-mb


On 02/02/2014 09:25 AM, George Toft wrote:
I've spent over 15 hours on this (google . . . head . . .desk . . . repeat).

I need to recover the data off of one of these hard drives.

Background
Two 3TB hard drives in a Raid 1 mirror, working fine for months. OS: Centos 6.5
Woke up a few days ago to a dead system - looks like motherboard failed.  And when it failed, it appears to have corrupted the RAID partition (supposition - see problems below).  I moved the drives to another system and it will boot then the kernel panics.

Partitions
part 1 - /boot
part 2 - swap
part 3 - RAID

I think the RAID partition has just one filesystem (/).


What I've done:
Rescue mode: Boots, unable to assemble raid set:

# fdisk -l | egrep "GPT|dev"
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sda: 80.0 GB, 80025280000
Disk /dev/sdb: 3000.6 GB, 3000591900160 bytes
/dev/sdb1                          1           267350  2147483647+ ee  GPT
Disk /dev/sdc: 3000.6 GB, 3000591900160 bytes
/dev/sdc1                          1           267350  2147483647+ ee  GPT

# mdadm --assemble --run /dev/md0 /dev/sdb
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted

# mdadm --assemble --run /dev/md0 /dev/sdb1
mdadm: cannot open device /dev/sdb1: No such file or directory
mdadm: /dev/sdb has no superblock - assembly aborted


parted tells me I've found a bug and gives me directions to report it.

-----------

Booted Knoppix and ran disktest.  I can copy the RAID partition to another drive as a disk image and I end up with image.dd.  When I try to build an array out of it, I get an error: Not a block device.

Tried commercial RAID recovery software (Disk Internals) - it hung after identifying 2.445 million files.


-------------

Ideas on what to do next?

Is anyone here up for a challenge?  Anyone need beer money? I need the data recovered, and will pay :)

All help is appreciated :)