linux-kernel - Re: RAID array is gone, please help

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Mar 2017 15:27:26 -0400
From:   lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:     raid@...ller.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: RAID array is gone, please help

On Thu, Mar 23, 2017 at 07:09:41PM +0100, raid@...ller.org wrote:
> Thank you very much or your reply.
> 
> I naively thought that starting without partitions would be the best
> starting point, given 3 of the disks had been in a RAID5 array
> previously (possibly with partitions, not sure), but that looks like
> a bad choice, based on some other things I've googled. Lesson learned.
> 
> I have an mdadm.conf file, but it could be a remnant of my previous array.
> I've already edited it trying to get things to work, so I'm
> not sure if it was updated when I created the new array or not.
> 
> I see various people online have had success in my situation using
> madadm --create /dev/md0 --assume-clean --verbose --level=10 \
> --raid-devices=4 /dev/sdc /dev/sdd /dev/sde /dev/sdf
> 
> Some people used --assume-clean, and some didn't. Given my array wasn't done
> with its resync, maybe I should leave that out.
> 
> If that would work, I guess then I need to get the data off the array,
> delete it, and recreate it with disk partitions, or risk this happening
> again at the next reboot, for whatever reason.
> 
> Anyone think it's a bad idea to try mdadm --create at this point?
> 
> Sorry, I'm not sure how to write 0's to sector 0...

Well the other possibility is that by having a MBR saying this has GPT and
probably having mdadm corrupt the GPT by writing to 4k in, but nothing
overwriting the backup GPT at the end of the device, something may have
restored the GPT to the original location, even if it was an empty GPT,
in which case your superblock is likely overwritten.

Does 'gdisk -l /dev/sdc' claim that it is a valid GPT table or corrupt?

So if that is what happened (not sure what would have done it, although
it seems badly defined who is responsible for fixing the GPT if it is
detected that the backup is valid but the primary is corrupt), then you
will want to make sure the MBR and GPT tables are removed, before you
do anything else.  Likely the data is still there, since I think the
first data block is offset a bit into the device, and the GPT is only
the first 32KB or so of the device.  If that is the case, doing the
create would probably work.  Of course the safest thing to do would be
to clone your disks before trying to reassemble them (which means you
need another four 4TB drives, but if the data is important, that's
probably worth it).

Of course you would also have to be sure the mdadm command you use to
create it again is exactly the same as before, and that the device names
are exactly the same as before.

-- 
Len Sorensen