Device name conflict

[fmouse]

I'm in a situation where I have to upgrade from Linux kernel 2.6.23 to 2.6.36. Between these kernel versions the CONFIG_IDE kernel support has gone away, udev has evolved, and /dev/hdNx devices have become /dev/sdNx. I have a couple of RAID-1 arrays defined with RAID autodetect as follows:

$ cat /proc/mdstat
Personalities : [raid1] 
md1 : active raid1 sdc1[0] sdd1[1]
      36146112 blocks [2/2] [UU]
      
md0 : active raid1 sdb1[1] sda1[0]
      117218176 blocks [2/2] [UU]

The RAID devices are on SATA drives.

I also have a PATA drive, designated /dev/hda, which has a /dev/hda1 partition which is used elsewhere on the box. When bringing up the new kernel, all the /dev/hda partitions become /dev/sda partitions, so there's a name conflict with /dev/sda1. The result is shown in this log excerpt:

Mar 24 12:18:53 [kernel] [    1.229464] md: Autodetecting RAID arrays.
Mar 24 12:18:53 [kernel] [    1.281388] md: Scanned 2 and added 2 devices.
Mar 24 12:18:53 [kernel] [    1.281566] md: autorun ...
Mar 24 12:18:53 [kernel] [    1.281739] md: considering sdc1 ...
Mar 24 12:18:53 [kernel] [    1.281918] md:  adding sdc1 ...
Mar 24 12:18:53 [kernel] [    1.282096] md:  adding sdb1 ...
Mar 24 12:18:53 [kernel] [    1.282273] md: created md0
Mar 24 12:18:53 [kernel] [    1.282453] md: bind<sdb1>
Mar 24 12:18:53 [kernel] [    1.282639] md: bind<sdc1>
Mar 24 12:18:53 [kernel] [    1.282826] md: running: <sdc1><sdb1>
Mar 24 12:18:53 [kernel] [    1.283219] md: personality for level 1 is not loaded!
Mar 24 12:18:53 [kernel] [    1.283401] md: do_md_run() returned -22
Mar 24 12:18:53 [kernel] [    1.283581] md: md0 still in use.
Mar 24 12:18:53 [kernel] [    1.283756] md: ... autorun DONE.

The RAID layout which the kernel is trying to build is quite fubar! I assume that a return of -22 from do_md_run() indicates that the RAID subsystem is smart enough to not even try to build a RAID array thusly, and not corrupt my data.

Here's what I'm thinking of trying, but I wanted to run it past some other eyes before I do it and possibly screw up the data on the drives.

If I turn off raid autodetect in the kernel config and enable RAID1, then I assume the RAID system falls back on /etc/mdadm.conf. Can I use UUIDs in DEVICE and ARRAY lines in mdamd.conf to spec the array components, e.g.

DEVICE UUID=xxxxxxxx.... UUID=yyyyyyy.... UUID=pppppp.... UUID=qqqqqq....
ARRAY /dev/md0 devices=UUID=xxxxxxx.....,UUID=yyyyyyy.....
ARRAY /dev/md1 devices=UUID=pppppp.....,UUID=qqqqqq.....

The only references I can find to using UUIDs in mdadm.conf deal with assigning UUIDs to arrays, not to the devices that constitute arrays.

Will this work? If not, is there some other way to address this problem?

[wwalker]

Fmouse,

It seems to me that sdb1, sdc1 is correct for md0 and sdd1, sde1 would be correct for md1, since sda has been inserted (used to be hda).

The problem appears to be that the initrd that was built doesn't have RAID personality modules built in.

Wayne

[fmouse]

There is no initrd on this box. It boots directly into the real kernel.

[fmouse]

One of the questions here is, if RAID autodetect is active in the kernel, does /etc/mdadm.conf actually get read, or does the kernel just pick up the drives from the 0.90 superblock and forge ahead? In other words, if I spec arrays with a UUID in /etc/mdadm.conf will it make any difference?

[wwalker]

One of the questions here is, if RAID autodetect is active in the kernel, does /etc/mdadm.conf actually get read, or does the kernel just pick up the drives from the 0.90 superblock and forge ahead? In other words, if I spec arrays with a UUID in /etc/mdadm.conf will it make any difference?

I think that /etc/mdadm.conf is ignored.

I also think that you may have built the kernel with raid1.ko. It needs to be built into the kernel, not as a module if you are not using initrd.

Wayne

[fmouse]

Wayne, all the RAID stuff is built into the kernel. That's not the problem. The fact that there are md lines in the kernel log indicates that that subsystem is active during boot-up, and it makes an attempt to sort out the RAID drives, but falls short.

[wwalker]

Wayne, all the RAID stuff is built into the kernel. That's not the problem. The fact that there are md lines in the kernel log indicates that that subsystem is active during boot-up, and it makes an attempt to sort out the RAID drives, but falls short.

[ 3.409531] md: md0 stopped.
[ 3.410431] md: bind<sdc2>
[ 3.410806] md: bind<sdb2>
[ 3.414090] md: raid1 personality registered for level 1
[ 3.414743] md/raid1:md0: active with 2 out of 2 mirrors
[ 3.415013] md0: detected capacity change from 0 to 524275712

md: refers to the autodetect in the kernel.

md/raid1: refers to the raid1 kernel module which is separate from the parent module.

It looks like you built the auto detect into the kernel but did not build the separate raidX personality modules into the kernel.

Wayne

[wwalker]

[ 3.409531] md: md0 stopped.
[ 3.410431] md: bind<sdc2>
[ 3.410806] md: bind<sdb2>
[ 3.414090] md: raid1 personality registered for level 1
[ 3.414743] md/raid1:md0: active with 2 out of 2 mirrors
[ 3.415013] md0: detected capacity change from 0 to 524275712

md: refers to the autodetect in the kernel.

md/raid1: refers to the raid1 kernel module which is separate from the parent module.

It looks like you built the auto detect into the kernel but did not build the separate raidX personality modules into the kernel.

Wayne

the default kernel setup is to build raid auto detect into the kernel, but to _not_ build in the RAID personalities (from stock make menuconfig):

<*> RAID support [*] Autodetect RAID arrays during kernel boot
<M> Linear (append) mode
<M> RAID-0 (striping) mode
<M> RAID-1 (mirroring) mode
<M> RAID-10 (mirrored striping) mode
<M> RAID-4/RAID-5/RAID-6 mode

[fmouse]

Bingo!!

Thank you, Wayne! I thought I had my new kernel config done exactly the way the old one was done. In fact, I did not have RAID-1 mode set in the new kernel config, which I did indeed have set in the old one. I'll rebuild the kernel with this set and take another run it it. This may be the key to the kingdom.