How do I get mdadm to auto assemble my raid array?

27,373

Solution 1

Using the UUID is the preferred method. Also see what /usr/share/mdadm/mkconf outputs and try using that.

You are updating the initramfs after you change /etc/mdadm/mdadm.conf right? If you don't, when you boot your changes won't be used. update-initramfs -u should do it.

Solution 2

In MY experience mdadm does not respect device-by-id names in mdadm.conf and just plain fails to rebuild the array.

If you replace device-by-id with /dev/sdXn controller references it should work fine.

BA

Share:
27,373

Related videos on Youtube

Asik
Author by

Asik

Like to play, compute, exist

Updated on September 17, 2022

Comments

  • Asik
    Asik almost 2 years

    After upgrading to Ubuntu 9.04, my raid 5 array is no longer being assembled correctly. Right now, from boot, it will start a raid array using ata-MAXTOR_STM3500630AS_9QG03T0L-part1, at /dev/md0, but that is fail because it isn't my whole Raid 5 setup. This was working fine in 8.10.

    I've tried tweaking the following config. I figured mdadm would follow my config on boot but it seems to have a mind of its own.

    If I stop /dev/md0 and then restart /dev/md1 it will sometimes cleanly start. Otherwise I have to re-add ata-MAXTOR_STM3500630AS_9QG03T0L-part1 to the array and it starts a 300 minute recovery.

    Tried:

    • Setting array to "/dev/md0"
    • Using the straight /dev/sd[bcde] in DEVICE and ARRAY config file.

    How can I get Ubuntu and mdadm to start /dev/md1 cleanly on boot again?

    My /etc/mdadm/mdadm.conf:

    MAILADDR [email protected]
    DEVICE /dev/disk/by-id/ata-MAXTOR_STM3500630AS_9QG03T0L-part1 /dev/disk/by-id/ata-MAXTOR_STM3500630AS_9QG07KQW-part1 /dev/disk/by-id/ata-MAXTOR_STM3500630AS_9QG07KZB-part1 /dev/disk/by-id/ata-MAXTOR_STM3500630AS_9QG07N72-part1 /dev/sdb1
    ARRAY /dev/md1 level=raid5 devices=/dev/disk/by-id/ata-MAXTOR_STM3500630AS_9QG03T0L-part1,/dev/disk/by-id/ata-MAXTOR_STM3500630AS_9QG07KQW-part1,/dev/disk/by-id/ata-MAXTOR_STM3500630AS_9QG07KZB-part1,/dev/disk/by-id/ata-MAXTOR_STM3500630AS_9QG07N72-part1,/dev/sdb1
    

    mdadm --misc --detail /dev/md1:

    /dev/md1:
            Version : 00.90
      Creation Time : Sun Aug 12 20:28:18 2007
         Raid Level : raid5
         Array Size : 1465151808 (1397.28 GiB 1500.32 GB)
      Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
       Raid Devices : 4
      Total Devices : 4
    Preferred Minor : 1
        Persistence : Superblock is persistent
    
        Update Time : Tue Jul 21 23:07:44 2009
              State : clean, degraded, recovering
     Active Devices : 3
    Working Devices : 4
     Failed Devices : 0
      Spare Devices : 1
    
             Layout : left-symmetric
         Chunk Size : 4K
    
     Rebuild Status : 14% complete
    
               UUID : 0223d5de:73491d5e:a219b166:4fedadc6
             Events : 0.7040
    
        Number   Major   Minor   RaidDevice State
           0       8       49        0      active sync   /dev/sdd1
           1       8       65        1      active sync   /dev/sde1
           4       8       17        2      spare rebuilding   /dev/sdb1
           3       8       33        3      active sync   /dev/sdc1
    

    Would specifying the UUID in the mdadm.conf work to help get mdadm started on boot?

    Thanks for your help!

    • Asik
      Asik almost 15 years
      Fixed finally. Had to run `mdadm --assemble /dev/md0 --update=homehost. Then I used the modified my mdadm.conf to use 'DEVICE partitions' and pointed the ARRAY line to the new uuid of the array. Things magically work now
  • Asik
    Asik almost 15 years
    I've tried setting the UUID as the device in the ARRAY of my mdadm.conf and rebuilding using update-initramfs -u but that hasn't helped. It seems like one of the superblocks might be confusing mdadm since it will continue to load /dev/md1 with a separate subset of the drives. Running sudo mdadm --stop /dev/md1 and then sudo mdadm --assemble /dev/md1 is required to get things going after a boot.