mdadm not running RAID1 after boot

[Tomi]

After I replaced my two aging 120GB disks with newer 500GB, always
rebuilding the array and enlarging it, my /dev/md0 doesn't start
anymore after a boot. I have to go into the webUI and start it
manually on DISKS>RAID>start. Very annoying.

I think I might've screwed up the partitioning in some way; see
logread after I start the raid manually (and everything works).

Feb 28 18:00:00 kernel: md: md0 stopped.
Feb 28 18:00:00 kernel: md: bind<sdb2>
Feb 28 18:00:00 kernel: md: bind<sda2>
Feb 28 18:00:00 kernel: md/raid1:md0: active with 2 out of 2 mirrors
Feb 28 18:00:00 kernel: md0: bitmap initialized from disk: read 1/1
pages, set 0 bits
Feb 28 18:00:00 kernel: created bitmap (4 pages) for device md0
Feb 28 18:00:00 hot: Changing DEVTYPE from disk to partition for "md0"
Feb 28 18:00:00 kernel: md0: detected capacity change from 0 to
499599933440
Feb 28 18:00:00 kernel: md0: unknown partition table
Feb 28 18:00:01 hot: Start fscking md0
Feb 28 18:00:02 hot: Finish fscking md0: fsck 1.41.14 (22-Dec-2010) /
dev/md0: clean, 55539/60997632 files, 28451103/121972640 blocks
Feb 28 18:00:02 kernel: EXT4-fs (md0): mounted filesystem with ordered
data mode. Opts: (null)
Feb 28 18:00:02 hot: Users directory found in md0
Feb 28 18:00:03 hot: ffp directory found in md0


Unknown partition table? I have both drives partition as 500MB SWAP on
sdX1 and the rest on sdX2. sdX3 and sdX4 are empty.

[Joao Cardoso]

On Feb 28, 5:15 pm, Tomi <fafar...@gmail.com> wrote:
> After I replaced my two aging 120GB disks with newer 500GB, always
> rebuilding the array and enlarging it, my /dev/md0 doesn't start
> anymore after a boot. I have to go into the webUI and start it
> manually on DISKS>RAID>start. Very annoying.

Have you used the Disk Wizard? No? Set the partition to RAID?

Anyhow, to diagnose the auto-start problem what I need are the
hot*.log, which shows what happens at "hotplug" time (i.e., when the
kernel recognizes the device/partitions, either at boot time or upon
insertion). Please post it (attach, not pasted) immediately after a
reboot, as it is very verbose.

But, for now, just post the output of

cat /proc/mdstat
mdadm --detail /dev/md0
mdadm --examine /dev/<the raid partitions> # such as /dev/sda2 /dev/
sdb2

I don't have such problems with my current RAID1/JBOD test disks.

> I think I might've screwed up the partitioning in some way; see

Plase post the output of

sfdisk -luS

> logread after I start the raid manually (and everything works).

...

> Feb 28 18:00:00 kernel:  md0: unknown partition table

...

> Unknown partition table? I have both drives partition as 500MB SWAP on
> sdX1 and the rest on sdX2. sdX3 and sdX4 are empty.

This is normal, a RAID can be partitioned like a disk, the message
just says that it is not partitioned.
RAID is a device, it is like a disk, you can do 'fdisk /dev/md0' --
but don't, Alt-F don't support it.

[Tomi]

I have found the issue. I think I probably messed up something during
configuration.
There was apparently also an md superblock on /dev/sda. Don't ask me
why. So mdadm examine return two items; one for /dev/sda on /dev/md0
and one for /dev/sda2, /dev/sdb2 on /dev/md0. Confusing the
executable:

+ mdadm --examine --scan
+ echo DEVICES /dev/sd*
+ mdadm --incremental --run /dev/sda2
mdadm: we match both /dev/md0 and /dev/md0 - cannot decide which to
use.

I have now used mdadm --zero-superblock --force /dev/sda which fixed
the problem.