# SOLVED: migrating software mdadm raid -> libata

## eccerr0r

I think it's about time I moved my RAID to libata.

However I've had trouble getting the system to autodetect...

Right now my server is using legacy ATA drivers on four IDE ports (4x120GB HDD's), /dev/hda, /dev/hdc, /dev/hde, and /dev/hdg.

The partitions look like (all same for the 4 disks, showing hda for simplicity)

hda1 - BOOT RAID1 (4 way, all 4 are marked for boot)

hda2 - ROOT RAID5 (4 disk)

hda3 - Storage RAID5 LVM (4 disk)

hda4 - Temp-Scratch RAID5 LVM (4 disk) -- This is the sacrificial partition in case I end up getting 120G disks that are slightly smaller, I can dump this partition and still swap in that disk to keep the other more important partitions going.

The theory is that since the computer will check the disks for boot sectors, if one disk goes belly up, it will check another disk for boot.  Since all 4 disks look the same, it should boot the same.

Anyway, I'm counting on /dev/hda2 to use kernel based autodetect to allow rootfs to mount.

When I boot the new kernel I think I see all my hard disks detect.  However it fails to find the root RAID  :Sad: 

The excerpt of my MD setup looks like this:

```
CONFIG_MD=y

CONFIG_BLK_DEV_MD=y

CONFIG_MD_AUTODETECT=y

CONFIG_MD_LINEAR=m

CONFIG_MD_RAID0=m

CONFIG_MD_RAID1=y

CONFIG_MD_RAID10=m

CONFIG_MD_RAID456=y

CONFIG_MD_RAID6_PQ=y

# CONFIG_ASYNC_RAID6_TEST is not set

CONFIG_MD_MULTIPATH=m

CONFIG_MD_FAULTY=m

CONFIG_BLK_DEV_DM=y

# CONFIG_DM_DEBUG is not set

CONFIG_DM_CRYPT=y

CONFIG_DM_SNAPSHOT=m

CONFIG_DM_MIRROR=m

# CONFIG_DM_LOG_USERSPACE is not set

CONFIG_DM_ZERO=m

CONFIG_DM_MULTIPATH=m

# CONFIG_DM_MULTIPATH_QL is not set

# CONFIG_DM_MULTIPATH_ST is not set

CONFIG_DM_DELAY=m

```

I'm fearing that md is looking for the old /dev/hdX devices for some reason, but obviously the major/minor numbers of the four disks have now changed due to libata.

Anyone seen this issue before?

I'll have to setup serial console to capture the errors as it scrolls by... I wish it didn't simply panic at the end when it can't find root... well, it's more of that shift-pgup scrollback doesn't work anymore after panics...

[Solution?]

Turns out that it was no problem after all... a 2.6.34-r6 kernel finally autodetects and boots the raid.  Perhaps an old .config was lying around? very strange...  Serial console wins the day.

----------

## cyrillic

 *eccerr0r wrote:*   

> I'm fearing that md is looking for the old /dev/hdX devices for some reason, but obviously the major/minor numbers of the four disks have now changed due to libata. 

 

This should not be a problem.

It is more likely that one of your controllers is not detected due to not having the right libata drivers installed.

----------

## eccerr0r

The weird thing is - the four disks are detected...

Perhaps there's a delay needed before scanning md volumes now?  I'm not sure... it did not appear to detect the md volume... hmm.  that reminds me, should go and test this with serial console soon.  Now where's a machine with a serial port...

[UPDATE]

Hmm...

on a lead here. Seems that the actual partition table of each disk is not being detected... but I have standard partition tables compiled into the kernel... odd.

[Update 2]

Finally got it working.  Not sure why the old kernel config would not detect partitions.  Now it's detecting partitions and setting up properly.

----------

