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 :)
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)