RAID migration from 2.4 -> 2.6

At the moment I'm stumped, so I wonder if someone might be able
to give me a hand.

First, my RAID setup: I have a pair of Adaptec 7899 controllers
with five 9GB SCSI disks on each.  The first disks on each controller
are allocated in a RAID 1 configuration for boot, swap, /usr, etc.,
while the next three disks on each controller are allocated in
a RAID 5 configuration to our running services and data.  The last
disk on each controller is designated as a spare disk for each RAID.

These RAIDs work well with 2.4.  I've got them configured
for autodetect, so the system brings them up at startup in 2.4.

Now I'm trying to migrate to 2.6.7, and autodetection basically
ignores all my SCSI disks.  I get three lines:

  Autodetecting RAID arrays:
    ..  autodetecting
  Done.

when I try to boot 2.6.7.  (Additional note: all SCSI controllers
and disks are discovered just fine, although I am using the new
Adaptec driver in 2.6.)

In the course of googling/reading to fix this problem, I've
come up with several possibilities:

  1) My 2.4 setup uses devfs.  (Don't ask why, it just does.)
     Naturally, I'm ok moving to udev in 2.6; I had a brief thought
     that perhaps the long devfs pathnames were somehow encoded
     into the persistent superblock of each RAID array, but I
     don't think that's the case - I think the major/minor numbers
     of the disk partitions are stored directly.  (Someone
     correct me if I'm wrong?)

  2) After taking a look at
       http://cgi.cse.unsw.edu.au/~neilb/SoftRaid/01084411399
     I'm not even sure if 2.6 will do autodetection of my 2.4 RAID
     arrays?  Or is this only for RAID arrays created under 2.6?

  3) (related to 2) my 2.4 setup does not uses initrd at all.  The boot
     process basically consists of the boot loader loading the kernel
     and the kernel running /sbin/init.  I rely on the kernel autodetection
     assembling the RAID arrays before init is ever run (as / is on
     /dev/md10).

Any suggestions here?  I'd rather not have to backup filesystems and
start from scratch to get my RAID arrays going.

Thanks,
-Bob

On Thursday 12 August 2004 17:29, you wrote:

At the moment I'm stumped, so I wonder if someone might be able
to give me a hand.

First, my RAID setup: I have a pair of Adaptec 7899 controllers
with five 9GB SCSI disks on each.  The first disks on each controller
are allocated in a RAID 1 configuration for boot, swap, /usr, etc.,
while the next three disks on each controller are allocated in
a RAID 5 configuration to our running services and data.  The last
disk on each controller is designated as a spare disk for each RAID.

These RAIDs work well with 2.4.  I've got them configured
for autodetect, so the system brings them up at startup in 2.4.

Now I'm trying to migrate to 2.6.7, and autodetection basically
ignores all my SCSI disks.  I get three lines:

Does those partions have the FD type flag (linux raid autodetect)? With some 
2.4.X kernel versions it worked without it, but I think with 2.6.X you really 
need to mark the partitions with this partition type.

Hope it helps,
	Bernd

PS: Sometimes I forget to set this flag and then have the same problem ;)

As a follow-up, I tried using md=10,/dev/sda1,/dev/sdf1 as a kernel
parameter.  Still no luck:

Loading md10: /dev/sda1
could not lock sda1
md_import_device returned -6
could not lock sdf1
md_import_device returned -6
bug in file drivers/md/md.c, line 1513.

But apparently this error is misleading (-6 == ENXIO, no such device).
I traced the code all the way back to do_open in fs/block_dev.c
which is where it appears to be coming from.

I'm not sure why the devices can't be found: the Adaptec driver appears
to go through its initialization routines just fine and find all the
disks.

Anyone have any ideas here?

-Bob

At the moment I'm stumped, so I wonder if someone might be able
to give me a hand.

First, my RAID setup: I have a pair of Adaptec 7899 controllers
with five 9GB SCSI disks on each.  The first disks on each controller
are allocated in a RAID 1 configuration for boot, swap, /usr, etc.,
while the next three disks on each controller are allocated in
a RAID 5 configuration to our running services and data.  The last
disk on each controller is designated as a spare disk for each RAID.

These RAIDs work well with 2.4.  I've got them configured
for autodetect, so the system brings them up at startup in 2.4.

Now I'm trying to migrate to 2.6.7, and autodetection basically
ignores all my SCSI disks.  I get three lines:

  Autodetecting RAID arrays:
    ..  autodetecting
  Done.

when I try to boot 2.6.7.  (Additional note: all SCSI controllers
and disks are discovered just fine, although I am using the new
Adaptec driver in 2.6.)

Bob Glamm wrote:
[]

I'm not sure why the devices can't be found: the Adaptec driver appears
to go through its initialization routines just fine and find all the
disks.

How about sd_mod (scsi disk module)?  Is it loaded (or compiled into the
kernel) together with the adaptec driver?  Does the kernel prints a line
like
  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 >
(partition layout) for all your disks?

/mjt

quoted

I'm not sure why the devices can't be found: the Adaptec driver appears
to go through its initialization routines just fine and find all the
disks.

How about sd_mod (scsi disk module)?  Is it loaded (or compiled into the
kernel) together with the adaptec driver?  Does the kernel prints a line
like
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 >
(partition layout) for all your disks?

I cannot (at the moment) say anything about the partition line
being printed out, but:

  * legacy /proc/scsi/ support
  * SCSI disk support
  * SCSI tape support
  * SCSI CDROM support
  * SCSI generic support
  * Verbose SCSI error reporting
  * SCSI logging facility
  SCSI Transport Attributes --> * SPI
  SCSI low-level drivers --> AIC7xxx Fast -> U160 support (new driver)
                         --> Adaptec AIC79xx U320 support

are all compiled into the kernel.

I wonder if it's possible there's a collision between the AIC79xx
and AIC7xxx driver.  I suppose I could try eliminating the AIC79xx driver
(as I have a pair of 7899's and a 7892 in these systems, no 79xx..)

-Bob