Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965221AbdCWRm5 (ORCPT ); Thu, 23 Mar 2017 13:42:57 -0400 Received: from caffeine.csclub.uwaterloo.ca ([129.97.134.17]:53432 "EHLO caffeine.csclub.uwaterloo.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756580AbdCWRmt (ORCPT ); Thu, 23 Mar 2017 13:42:49 -0400 X-Greylist: delayed 326 seconds by postgrey-1.27 at vger.kernel.org; Thu, 23 Mar 2017 13:42:49 EDT Date: Thu, 23 Mar 2017 13:37:21 -0400 To: raid@mueller.org Cc: linux-kernel@vger.kernel.org Subject: Re: RAID array is gone, please help Message-ID: <20170323173721.GA14188@csclub.uwaterloo.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3474 Lines: 92 On Thu, Mar 23, 2017 at 05:49:05PM +0100, raid@mueller.org wrote: > I am hoping someone here will help me. Was reading this site... > > https://raid.wiki.kernel.org/index.php/Linux_Raid > > and it said to email this list if you've tried everything other than mdadm > --create. > > > I am running Ubuntu 16.04. Machine name is fred. I used webmin to create a 4 > disk RAID10 array yesterday. I moved all my data onto the array. > > Today, I had to reboot my PC. The resync was still not done, but I read > online that it's OK to boot during resync. After boot, my array was gone. I > checked syslog, and it just has this line: > > DeviceDisappeared event detected on md device /dev/md0 > > I did not partition my disks before building the array. So I believe the > array consisted of /dev/sdc, /dev/sdd, /dev/sde, and /dev/sdf. > > Here's some info... > > stephen@fred> lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 117.4G 0 disk > ├─sda1 8:1 0 109.7G 0 part / > ├─sda2 8:2 0 1K 0 part > └─sda5 8:5 0 7.7G 0 part [SWAP] > sdb 8:16 0 465.8G 0 disk > └─sdb1 8:17 0 465.8G 0 part > sdc 8:32 0 3.7T 0 disk > sdd 8:48 0 3.7T 0 disk > sde 8:64 0 3.7T 0 disk > sdf 8:80 0 3.7T 0 disk > > stephen@fred> sudo mdadm --examine /dev/sdc > [sudo] password for stephen: > /dev/sdc: > MBR Magic : aa55 > Partition[0] : 4294967295 sectors at 1 (type ee) > stephen@fred> > stephen@fred> sudo mdadm --examine /dev/sdc1 > mdadm: cannot open /dev/sdc1: No such file or directory > stephen@fred> > stephen@fred> sudo mdadm --examine /dev/sdd > /dev/sdd: > MBR Magic : aa55 > Partition[0] : 4294967295 sectors at 1 (type ee) > stephen@fred> > stephen@fred> sudo mdadm --examine /dev/sde > /dev/sde: > MBR Magic : aa55 > Partition[0] : 4294967295 sectors at 1 (type ee) > stephen@fred> > stephen@fred> sudo mdadm --examine /dev/sdf > /dev/sdf: > MBR Magic : aa55 > Partition[0] : 4294967295 sectors at 1 (type ee) > > stephen@fred> sudo mdadm --assemble --force /dev/md0 /dev/sdc /dev/sdd > /dev/sde /dev/sdf > mdadm: Cannot assemble mbr metadata on /dev/sdc > mdadm: /dev/sdc has no superblock - assembly aborted > > Thank you for any help you can provide. Did your disks have partitions previously? That output looks a lot like the protective MBR partition table for a disk with GPT partitions. Could that still existing in sector 0 be confusing mdadm? I have never personally done any md raid without partitions. To me they just make more sense. One way to test could be to save a copy of sector 0, then overwrite sector 0 with zeros and then run mdadm --examine again to see if that makes a difference. You can always put back the saved copy of sector 0 that way. My understanding is that the default is to put the raid superblock at offset 4k, so it would not overwrite an existing MBR partition table. If it also happens due to rounding that the end of the disk isn't overwritten (or even just because that part of the filesystem wasn't written to yet), then the backup GPT from before would still be intact, and could perhaps cause even more confussion later if gdisk or similar is pointed at the disk. Really want to be sure there is no trace left of the partition table before using it raw for md raid. Any chance the system saved an mdadm.conf file of your setup? -- Len Sorensen