# Did  RAID  change since  2.6.15-gentoo-r1? - SOLVED

## Moriah

I just built a new 2.6.28-gentoo-r5 kernel to replace an ancient 2.6.15-gentoo-r1 kernel, and my RAID-5 refuses to start with the new kernel.  Here are the details of the RAID:

```

ezekiel ~ # mdadm --detail /dev/md0

/dev/md0:

        Version : 0.90

  Creation Time : Sat Feb 25 14:14:24 2006

     Raid Level : raid5

     Array Size : 468760320 (447.04 GiB 480.01 GB)

  Used Dev Size : 234380160 (223.52 GiB 240.01 GB)

   Raid Devices : 3

  Total Devices : 3

Preferred Minor : 0

    Persistence : Superblock is persistent

    Update Time : Tue Apr 28 00:43:20 2009

          State : clean

 Active Devices : 3

Working Devices : 3

 Failed Devices : 0

  Spare Devices : 0

         Layout : left-symmetric

     Chunk Size : 64K

           UUID : 7bbb5886:92db0ae1:521ca23e:1f7f0ebf

         Events : 0.70907144

    Number   Major   Minor   RaidDevice State

       0      33        1        0      active sync   /dev/hde1

       1      34        1        1      active sync   /dev/hdg1

       2      56        1        2      active sync   /dev/hdi1

ezekiel ~ # 

```

It still works fine when I boot the old kernel.  I just copied the old .config into the kernel build directory (/usr/src/linux) and did a make oldconfig and responded with a <CR> to each prompt to take the default, then did a make && make modules_install, followed by copying the new kernel into my /boot partition and then updated the grub.conf and did a reboot.

Thanks for any help or insight that you can provide.    :Very Happy: 

PS  The above output was made under the old kernel; the new kernel is similar, except that it shows active instead of clean for the state.

----------

## pigeon768

is CONFIG_MD_AUTODETECT enabled in the new kernel? I believe this is new as of 2.6.25 or something and the default is to have it disabled. All the partitions are of type 'fd' (linux raid autodetect) correct?

----------

## eccerr0r

What's the exact error you're seeing?

Sometimes minute changes from kernel to kernel occur... would be helpful to know what the symptoms are.

I don't remember what version of the kernel I used when I first created the array, but it was about a year after you...

```
/dev/md/1:

        Version : 0.90

  Creation Time : Fri Jan 26 02:03:35 2007

     Raid Level : raid5

     Array Size : 23470656 (22.38 GiB 24.03 GB)

  Used Dev Size : 7823552 (7.46 GiB 8.01 GB)

   Raid Devices : 4

  Total Devices : 4

Preferred Minor : 1

    Persistence : Superblock is persistent

    Update Time : Tue Apr 28 14:51:25 2009

          State : clean

 Active Devices : 4

Working Devices : 4

 Failed Devices : 0

  Spare Devices : 0

```

Are you using udev/device mapper? did it detect all member disks properly? all RAID personality modules loaded?

----------

## Moriah

pigeon768:

 *Quote:*   

> 
> 
> is CONFIG_MD_AUTODETECT enabled in the new kernel? I believe this is new as of 2.6.25 or something and the default is to have it disabled. All the partitions are of type 'fd' (linux raid autodetect) correct?
> 
> 

 

Yes, it is enabled in the new build, and not present in the ot\ld build:

```

ezekiel ~ # grep CONFIG_MD_AUTODETECT /boot/config-2.6.15-r1_lvm 

ezekiel ~ # 

```

```

ezekiel ~ # grep CONFIG_MD_AUTODETECT /boot/config-2.6.28-gentoo-r5

CONFIG_MD_AUTODETECT=y

ezekiel ~ # 

```

----------

## Moriah

In the course of preparing a detailed reply to eccerr0r, I found the problem.  It seems that when I did the make oldconfig and responded to all the prompts with a <CR> to take the default, somehow, somewhere, the support for RAID-5 got dropped, and only the support for RAID-1 survived.    :Embarassed: 

I did a make menuconfig to correct the problem, followed by a make && make modules_install, and now all is well.

Sorry to trouble you with this, but I would like to know if I was just careless about hitting the <CR> key, or if there is really a bug in the latest version of make oldconfig that caused the RAID-5 support to vanish.    :Confused: 

----------

## eccerr0r

Don't worry about it.  No problem is too careless to post about, that's what these forums are for...sometimes minute details are missed and someone's hint may point to the general area where that detail was missed...and results in success!

First time I tried 'make oldconfig' I really wonder why the heck anyone ever would want to do that...this seemed like a blast to the past instead of setting up a new kernel (I _hated_ the 'make config' of Linux 0.99pl12 ... oldconfig looks like the same thing) ... seems like the best is to just go ahead and 'make menuconfig' or whatever you normally do and check your options.  There are a lot of them however, it doesn't save any time to use it, but at least you have a starting point of what you had in the past that worked.

If none of the 'graphical' config utilities fit your needs, then make oldconfig pressing enter all the way down still needs to be followed by editing .config for verifying all the new options (OR OPTIONS THAT CHANGED NAME!!!)... and then another pass at make oldconfig needs to follow...

----------

## Moriah

True, but with a dozen boxes to update, my method is to generate a config for the new kernel with make oldconfig and try to build it and boot it.  If it works, then I move on to the next box.  If it fails, then revert to the previous working kernel and move on to the next box, marking the failing machine as needing a revisit.  Sometimes a pattern in the failures helps me see what the underlying problem really is, and then I can easily fix them all.

----------

