Skip to contentSkip to conversation

heavy problem with raid initialisation

DISCUSSION Guillaume Rousse 2 participants 5 messages Feb 10, 2006 – Apr 12, 2006 MD RAID

lore
Share & tools
lore
#0 lore raw

Hello.

I'm using software raid with mdadm 1.7.0 on a mandrake linux 10.1, but I'm facing heavy initialisation troubles. The first array /dev/md0 is automatically created and launched at startup (though mdadm -As in init scripts), but not the second array /dev/md1.

mdadm --examine --scan --config=partitions creates the second array as /dev/.tmp.md1, which I can then assemble using an explicit mdadm -A /dev/sda2 /dev/sdb2 command, but this is unpractical and failproof :/

Here is my /etc/mdadm.conf:
DEVICE /dev/sda* /dev/sdb*
MAILADDR root
ARRAY /dev/md1 level=raid1 num-devices=2
UUID=e5e9302c:1844139b:d30d31e0:6f8477c3
devices=/dev/sda2,/dev/sdb2
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=99375e60:af2e538e:59f01931:f86b50f4
devices=/dev/sda1,/dev/sdb1

And here is content of /proc/mdstat once the second array is running:

Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]

      78123968 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]

      78123968 blocks [2/2] [UU]

unused devices: <none>

I've had a look at google, I found some report of similar troubles, some of them potentially linked with udev. I found some excerpts of mdadm code that show than this specific /dev/.tmp syntax use is volontary, but I found no explanation for it.

Any help appreciated.

#1 lore raw
Quoted 11 lines · Guillaume Rousse

Hello.

I'm using software raid with mdadm 1.7.0 on a mandrake linux 10.1, but I'm facing heavy initialisation troubles. The first array /dev/md0 is automatically created and launched at startup (though mdadm -As in init scripts), but not the second array /dev/md1.

mdadm --examine --scan --config=partitions creates the second array as /dev/.tmp.md1, which I can then assemble using an explicit mdadm -A /dev/sda2 /dev/sdb2 command, but this is unpractical and failproof :/

i think this issue was squashed in a newer version of mdadm can you try rebuilding the current cooker rpm on 10.1 and try again. i don't have a 10.1 laying around to test atm.

L.

Signature · 6 lines
Luca Berra -- [email protected]
       Communication Media & Services S.r.l.
/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \
#2 lore raw
Quoted 8 lines · Luca Berra
Quoted 7 lines · Guillaume Rousse

Hello.

I'm using software raid with mdadm 1.7.0 on a mandrake linux 10.1, but I'm facing heavy initialisation troubles. The first array /dev/md0 is automatically created and launched at startup (though mdadm -As in init scripts), but not the second array /dev/md1.

Quoted 8 lines
Quoted 4 lines

mdadm --examine --scan --config=partitions creates the second array as /dev/.tmp.md1, which I can then assemble using an explicit mdadm -A /dev/sda2 /dev/sdb2 command, but this is unpractical and failproof :/

i think this issue was squashed in a newer version of mdadm can you try rebuilding the current cooker rpm on 10.1 and try again. i don't have a 10.1 laying around to test atm.

I updated mdadm to 2.3.1, but the array is still seen as /dev/.tmp.md1. Putting this instead of /dev/md1 in /etc/mdadm.conf fix the issue, but it is quite inelegant :/

#3 lore raw
Quoted 14 lines · Guillaume Rousse
Quoted 13 lines · Luca Berra
Quoted 11 lines · Guillaume Rousse

Hello.

I'm using software raid with mdadm 1.7.0 on a mandrake linux 10.1, but I'm facing heavy initialisation troubles. The first array /dev/md0 is automatically created and launched at startup (though mdadm -As in init scripts), but not the second array /dev/md1.

mdadm --examine --scan --config=partitions creates the second array as /dev/.tmp.md1, which I can then assemble using an explicit mdadm -A /dev/sda2 /dev/sdb2 command, but this is unpractical and failproof :/

Quoted 6 lines
Quoted 3 lines

i think this issue was squashed in a newer version of mdadm can you try rebuilding the current cooker rpm on 10.1 and try again. i don't have a 10.1 laying around to test atm.

I updated mdadm to 2.3.1, but the array is still seen as /dev/.tmp.md1. Putting this instead of /dev/md1 in /etc/mdadm.conf fix the issue, but it is quite inelegant :/

mmmm
try adding auto=yes to your array lines in mdadm.conf or invoke mdadm -As -a

is /dev on udev ?

L.

Signature · 6 lines
Luca Berra -- [email protected]
       Communication Media & Services S.r.l.
/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \
#4 lore raw

For sake of list archive completness :)

Quoted 7 lines · Luca Berra
Quoted 3 lines

I updated mdadm to 2.3.1, but the array is still seen as /dev/.tmp.md1. Putting this instead of /dev/md1 in /etc/mdadm.conf fix the issue, but it is quite inelegant :/

mmmm
try adding auto=yes to your array lines in mdadm.conf or invoke mdadm -As -a

auto=yes solved the issue, thanks.

Quoted 1 line

is /dev on udev ?

Yes