mdadm: doesn't contain a valid partition table after reboot

[fermulator]

Thanks dtfinch.

I went with option 2) version 1.1 metadata. Since I was creating partitions 2048 blocks into the drive (DOS compatibility disabled [c] and in sector mode [u]), and I'm not booting off this array, storing the meta data at the start of the drive made a lot of sense.

Here's what I've got now for reference.

fermulator@fermmy-server:~$ cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md2000 : active raid6 sdh1[5] sdl1[3] sdk1[2] sdg1[4] sdj1[1] sdi1[0]
      7814053632 blocks super 1.1 level 6, 64k chunk, algorithm 2 [6/6] [UUUUUU]

fermulator@fermmy-server:~$ sudo mdadm -Q --detail /dev/md2000
/dev/md2000:
        Version : 01.01
  Creation Time : Fri Apr 22 01:12:07 2011
     Raid Level : raid6
     Array Size : 7814053632 (7452.06 GiB 8001.59 GB)
  Used Dev Size : 3907026816 (3726.03 GiB 4000.80 GB)
   Raid Devices : 6
  Total Devices : 6
Preferred Minor : 2000
    Persistence : Superblock is persistent

    Update Time : Wed Apr 27 22:54:41 2011
          State : clean
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 64K

           Name : fermmy-server:2000  (local to host fermmy-server)
           UUID : 15d2158f:5cf74d95:fd7f5607:0e447573
         Events : 11842

    Number   Major   Minor   RaidDevice State
       0       8      129        0      active sync   /dev/sdi1
       1       8      145        1      active sync   /dev/sdj1
       2       8      161        2      active sync   /dev/sdk1
       3       8      177        3      active sync   /dev/sdl1
       5       8      113        4      active sync   /dev/sdh1
       4       8       97        5      active sync   /dev/sdg1

fermulator@fermmy-server:~$ sudo fdisk -ul /dev/sd[ghijkl] | grep -E Start\|/dev/sd
Disk /dev/sdg: 2000.4 GB, 2000398934016 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sdg1            2048  3907029167  1953513560   fd  Linux raid autodetect
Disk /dev/sdh: 2000.4 GB, 2000398934016 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sdh1            2048  3907029167  1953513560   fd  Linux raid autodetect
Disk /dev/sdi: 2000.4 GB, 2000398934016 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sdi1            2048  3907029167  1953513560   fd  Linux raid autodetect
Disk /dev/sdj: 2000.4 GB, 2000398934016 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sdj1            2048  3907029167  1953513560   fd  Linux raid autodetect
Disk /dev/sdk: 2000.4 GB, 2000398934016 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sdk1            2048  3907029167  1953513560   fd  Linux raid autodetect
Disk /dev/sdl: 2000.4 GB, 2000398934016 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sdl1            2048  3907029167  1953513560   fd  Linux raid autodetect

[AllGamer]

i'm facing a similar problem here
http://ubuntuforums.org/showthread.php?p=10734927

mdadm RAID5 was running fine, until i reinstalled the OS

the OS sits on its own separate drive, not part of the mdadm RAID5

according to what you guys have commented above, i too had no partitions set on the individual devices, nor partition on the md0 device.

the RAID was a straight assembly of 4 disk using the full length of the drive, then /dev/md0 was formatted with EXT3

anyways, i'm having a hard time trying to make the /dev/md0 to mount

it keeps complaining about Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/md0

and i don't know what to do without causing more damage

[lister171254]

Similar problem after growing the array.

Everything works, but fdisk reports that /dev/md0 does not have a partition table.

Is this a problem, is there a fix, or should I ignore this.

Thanks

[vcrpcant]

Same here,
sudo fdisk -l says: Disk /dev/md0 doesn't contain a valid partition table (md2 too)

is it safe to ignore it ou what?

[krisb82]

HELP!!

I'm bumping this thread in hopes to get some advice on the same problem. I'm a noob to Linux and setup a RAID5 volume last week using mdadm and Webmin. Everything was working fine and I added an EXT4 partition to /dev/md0 and was able to save data to it after mounting at /mnt/<mount>. I tested it for a while and even was able to reboot and get the volume to come back up after booting a few times.

I felt I was fine to go ahead and put this volume into production as a Samba share for my company's design team (the volume is not a boot volume; my OS is installed on a separate HD). However, after a system-suggested reboot this morning I got an error that /dev/md0 could not be mounted on /mnt/<mount>. I skipped it and then ran fdisk -l to find that all member disks properly showing their "Linux raid autodetect" partitions; however, /dev/md0 lists the error: "Disk /dev/md0 doesn't contain a valid partition table."

Am I out of luck here? I just had the design manager come ask me for an update and I don't know what to tell him. I'm worried that in trouble on this one. Any way of recovering my data? I was just about to setup the backup system today...of course, a day too late!

[krisb82]

Follow up to previous post:
After reading through others' posts I did check to make sure that my UUID matched on my mdadm config file and on my entry in FSTAB. I noticed that I had added a uid and gid of the main share user account to the options of FSTAB:

UUID=<UUID>   /mnt/design   ext4   defaults,uid=1001,gid=1001   0  0

Upon viewing log files after trying to mount the share found that the uid/gid entry may have been the culprit.

After editing the FSTAB entry to:

UUID=<UUID>    /mnt/design    ext4    defaults    0 0

and running "sudo mount -a" I had success!!

I'm still stumped, however, as to why the uid/gid would get in the way. Any thought?

[rubylaser]

There's really no need for uid or gid in your situation as those are not ext4 filesystem options. As an aside, I always mount mdadm arrays by their device name. Because they are already defined by UUID in /etc/mdadm/mdadm.conf they can't get mounted incorrectly. I would modify your /etc/fstab to look like this.

/dev/md0 /mnt/design    ext4    defaults    0 0

Glad you got it working.