Re: Raid 5 Problem

nterry wrote:

[root@homepc ~]# mdadm -Esvv /dev/sdb
/dev/sdb:
         Magic : a92b4efc
       Version : 0.90.02
          UUID : c57d50aa:1b3bcabd:ab04d342:6049b3f1
 Creation Time : Thu Dec 15 15:29:36 2005
    Raid Level : raid5

Yup - that's leftover block from one of your earlier arrays/attempts. It just happens to sit in unused area of /dev/sdb1, but is picked as valid /dev/sdb superblock

I added the DEVICE /dev/sd[bcde]1 to mdadm.conf and that apepars to have fixed the problem.  2 reboots and it worked both times.

I also note now that:
[root@homepc ~]# mdadm --examine --scan
ARRAY /dev/md0 level=raid5 num-devices=4 UUID=50e3173e:b5d2bdb6:7db3576b:644409bb
  spares=1
[root@homepc ~]#

That DEVICE line limits mdadm to only look at sd[bcde]1 as potential array members, so examine shows only current array. If you plan to add more raid arrays later, be sure to change it. Also read below.

Frankly I don't know enough about the workings of udev and the boot process to be able to get into that.  However these two files might mean something to you:

[...]

AND...

[root@homepc ~]# cat /etc/udev/rules.d/70-mdadm.rules
# This file causes block devices with Linux RAID (mdadm) signatures to
# automatically cause mdadm to be run.
# See udev(8) for syntax

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", \
   RUN+="/sbin/mdadm -I --auto=yes $root/%k"
[root@homepc ~]#

That's the part of the problem. In human language it means, that during udev event related to device add or change, any device detected as being part of linux raid, will be incrementally assembled. ID_FS_TYPE is exported in one of the earlier rules by vol_id helper tool. So during initial udev run, /dev/sdb is picked up, and forces mdadm later to drop /dev/sdb1 from array during every boot.

You can comment it out safely (or just remove whole 70-mdadm.rules file). Then you can remove DEVICE line from mdadm.conf

Thanks for getting me working

np :)