Jaunty Broke Software Raid

[fjgaude]

Well, some folks have had issues using the whole drive and not a partition of the drive, like sdb1 instead of sdb... even through sdb1 is a partition of the whole drive. Can't say if that is an issue here.

The only thing left is to try a forced assembly:

sudo mdadm --assemble --force /dev/md0

There's something at issue with sdc from reading the logs, eh?

[flick152]

Can't even force it

root@griffie:/home/nutchy# mdadm -Af /dev/md0
mdadm: SET_ARRAY_INFO failed for /dev/md0: Device or resource busy

root@griffie:/home/nutchy# mdadm --assemble --force /dev/md0 /dev/sdc /dev/sdd
mdadm: failed to add /dev/sdc to /dev/md0: Invalid argument
mdadm: /dev/md0 assembled from 1 drive - not enough to start the array.

[77881.759077] md: md0 still in use.
[77881.817910] md: array md0 already has disks!
[77881.982294] md: sdc has same UUID but different superblock to sdd
[77881.982301] md: sdc has different UUID to sdd
[77881.982304] md: export_rdev(sdc)
[78980.828088] md: md0 still in use.
[78980.883480] md: array md0 already has disks!
[78980.926417] md: sdc has same UUID but different superblock to sdd
[78980.926424] md: sdc has different UUID to sdd
[78980.926427] md: export_rdev(sdc)
[79015.283112] md: md0 stopped.
[79015.283136] md: unbind<sdd>
[79015.283255] md: export_rdev(sdd)
[79015.286421] md: bind<sdd>
[79015.286662] md: sdc has same UUID but different superblock to sdd <-- Is this relevant?
[79015.286665] md: sdc has different UUID to sdd
[79015.286667] md: export_rdev(sdc)
[79015.370519] md: sdc has same UUID but different superblock to sdd
[79015.370525] md: sdc has different UUID to sdd
[79015.370528] md: export_rdev(sdc)

root@griffie:/home/nutchy# mdadm -Ev /dev/sdc
/dev/sdc:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 616e78cd:fc386bed:b928cd6d:81a874bc (local to host griffie)
  Creation Time : Sat Mar  7 18:56:48 2009
     Raid Level : raid0
  Used Dev Size : 0
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0 <--**  Should these be different?

    Update Time : Sat Mar  7 18:56:48 2009
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : d5088fc1 - correct
         Events : 1

     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     0       8        0        0      active sync   /dev/sda

   0     0       8        0        0      active sync   /dev/sda
   1     1       8       16        1      active sync   /dev/sdb

root@griffie:/home/nutchy# mdadm -Ev /dev/sdd
/dev/sdd:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 616e78cd:fc386bed:b928cd6d:81a874bc (local to host griffie)
  Creation Time : Sat Mar  7 18:56:48 2009
     Raid Level : raid0
  Used Dev Size : 0
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 127<--**

    Update Time : Sat Mar  7 18:56:48 2009
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : d5089052 - correct
         Events : 1

     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     1       8       16        1      active sync   /dev/sdb

   0     0       8        0        0      active sync   /dev/sda
   1     1       8       16        1      active sync   /dev/sdb

[fjgaude]

Gosh, there's something decidedly wrong here. When you examine sdc/d the data shows that sda/b is of the array.

Did you use the sda/b drives in the md0 array before?

[flick152]

Yes before I upgraded to jaunty these two hard disks where at sda & sdb

I have 4 hdds currenly sda/b are on the standard IDE controller and sdc/d are on my raid controller (pseudo raid I ditched dmraid for mdadm)

so jaunty switched sda/b and sdc/d around

root@griffie:/home/nutchy# fdisk -l

Disk /dev/sda: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x869726ba

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        9872    79296808+  83  Linux
/dev/sda2            9873        9964      738990    5  Extended
/dev/sda5            9873        9964      738958+  82  Linux swap / Solaris

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x94719471

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       30401   244196001   83  Linux

Disk /dev/sdc: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/sdc doesn't contain a valid partition table

Disk /dev/sdd: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/sdd doesn't contain a valid partition table

[fjgaude]

The switching of drive names is unimportant to mdadm, as it uses the array UUID to assemble. That UUID is the same for each drive of an array.

So, we have issues with your setup...

What does this show:

sudo mdadm -D /dev/md0

Being able to run this command means the array is assembled!

[flick152]

root@griffie:/home/david# mdadm -D /dev/md0
mdadm: md device /dev/md0 does not appear to be active.

[fjgaude]

Looking your log sheets, it seems you are in a bad way.

[79015.286662] md: sdc has same UUID but different superblock to sdd <-- Is this relevant?

Yes, it is. Indicates drive used in anothe array, or something like that.

Preferred Minor : 0 <--** Should these be different?

That's okay... the "0" is the start point for device ID for /md0 arrays.

I don't have any suggestion other than to start over. That will require you to zero the superblocks of the two drives to be used in the new array.

I guess you could go back to your old OS and see what happens.

[joeinbend]

I've been battling with the same problem on my setup: I have a RAID5 NAS that was running 8.10, with MDADM 2.6.8, when I updated to 9.04 I got similar results: array failed to assemble, stating that two of the 4 disks were unavailable. examining each disk, they have the correct UUID. I was able to force them to assmeble:
sudo mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sde --force

Doing that it assmbled clean, I just had to re-mount it for my Samba share to be visable. I am completing a full backup of my criticial data from the array, and am going to wipe and do a clean install of 8.04 LTS, and I should be able to mount the array clean without --force.

Not sure exactly what the issue is with MDADM on 9.04. I tried removing mdadm and re-adding it (sudo apt-get purge mdadm, sudo apt-get install mdadm, reboot), which rolled me to version 2.6.7.1, with the same results.

I imagine the perminant fix will be a new version release of MDADM, if that is possible.

[fjgaude]

Not sure exactly what the issue is with MDADM on 9.04. I tried removing mdadm and re-adding it (sudo apt-get purge mdadm, sudo apt-get install mdadm, reboot), which rolled me to version 2.6.7.1, with the same results.

From what little I've seen is 9.04 changes the UUID value of the array, and we then need to get the new one into the mdadm.conf file. That's it. One way to do that is:

sudo mdadm --examine --scan --config=mdadm.conf >> /etc/mdadm/mdadm.conf

Or you can auto create a new mdadm.conf file by uninstalling mdadm, re-naming or deleting mdadm.conf, then re-booting, re-installing mdadm, and run this:

sudo mdadm --assemble --scan

Then you are good to go with a new auto-created mdadm.conf file.

[joeinbend]

I found on mine i was actually able to fix it by changing the ARRAY line in my mdadm.conf. the UUID was correct still, but I changed:

ARRAY /dev/md0 uuid=insert:uuid:here

to.... :
ARRAY /dev/md0 level=raid5 num-devices=4 UUID=insert:uuid:here


Rebooted, everything worked normally after that. very strange.