Fehlende Partitionen in dev nach mdadm-Assemble (Raid) und Reboot

Hi Leute,

Gleich vorweg: Ich bin kein Linux-Spezi. Wäre ich zwar gerne, aber ich würde hier nicht fragen, wenn ich nicht mit meinem Latein am Ende wäre ;)

Ich habe auf einem XenServer 6.1 ein Raid5 aus 3 neuen WD-2TB-Red-Platten aufgebaut, um es als SR einzubinden. Ich habe das Raid nach folgender Anleitung angelegt: http://seetricks.blogspot.de/2012/02/xenserver-mit-software-raid-einric ...
Es lief auch alles, bis zum ersten Reboot vom Xen. /dev/md0 war nicht mehr vorhanden, was an sich ja noch nicht sehr problematisch ist.
mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 gibt aber folgendes zurück:

mdadm: cannot open device /dev/sdd1: No such file or directorymdadm: /dev/sdd1 has no superblock - assembly aborted/dev/sdd1 gibt es tatsächlich nicht (dev/sdb1 und /dev/sdc1 aber schon!), die Partition existiert aber:[root@srvxen01 ~]# fdisk -lDisk /dev/sdb: 2000.3 GB, 2000398934016 bytes256 heads, 63 sectors/track, 242251 cylindersUnits = cylinders of 16128 * 512 = 8257536 bytes Device Boot Start End Blocks Id System/dev/sdb1 1 242252 1953514583+ ee EFI GPTDisk /dev/sdc: 2000.3 GB, 2000398934016 bytes256 heads, 63 sectors/track, 242251 cylindersUnits = cylinders of 16128 * 512 = 8257536 bytes Device Boot Start End Blocks Id System/dev/sdc1 1 242252 1953514583+ ee EFI GPTDisk /dev/sdd: 2000.3 GB, 2000398934016 bytes256 heads, 63 sectors/track, 242251 cylindersUnits = cylinders of 16128 * 512 = 8257536 bytes Device Boot Start End Blocks Id System/dev/sdd1 1 242252 1953514583+ ee EFI GPT

Da alle Platten am gleichen Controller hängen, hat es mich ein wenig gewundert, das sich eine Platte anders verhält. Wenn ich richtig verstanden habe, ist udev dafür verantwortlich die /dev-Dateien zu erstellen und komischerweise startet mdadm vor udev, was meiner Meinung nach nicht einleuchtend ist. Das Array ist nicht einmal im Degraded-Mode gestartet. Der Inhalt meiner /etc/mdadm.conf:
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=2cc7a336:45ac81b7:ad53e141:2b350313
Ich habe mir dann einfach gedacht, ich mache es wie festr in diesem Thread http://www.linuxquestions.org/questions/linux-newbie-8/missing-partitio ... und baue die Partion auf /dev/sdd neu.

Nach einem mdadm --misc --zero-superblock /dev/sdd habe ich Xen rebootet und wollte das Raid erstmal mit 2 Platten starten. Und nun das:
[root@srvxen01 ~]# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 --forcemdadm: cannot open device /dev/sdc1: No such file or directorymdadm: /dev/sdc1 has no superblock - assembly aborted[root@srvxen01 ~]# ls -l /dev/sd*brw-r----- 1 root disk 8, 0 Apr 1 21:10 /dev/sdabrw-r----- 1 root disk 8, 1 Apr 1 21:11 /dev/sda1brw-r----- 1 root disk 8, 2 Apr 1 21:10 /dev/sda2brw-r----- 1 root disk 8, 3 Apr 1 21:11 /dev/sda3brw-r----- 1 root disk 8, 16 Apr 1 21:10 /dev/sdbbrw-r----- 1 root disk 8, 17 Apr 1 21:10 /dev/sdb1brw-r----- 1 root disk 8, 32 Apr 1 21:10 /dev/sdcbrw-r----- 1 root disk 8, 48 Apr 1 21:10 /dev/sddbrw-r----- 1 root disk 8, 49 Apr 1 21:10 /dev/sdd1

Jetzt fehlt /dev/sdc1! Meine Vermutung ist das mdadm beim Versuch beim Booten das Raid zusammenzubauen udev in die Quere kommt. Das bestätigt zumindest mein Test Xen mit leerer mdadm.conf zu booten:
[root@srvxen01 ~]# ls -l /dev/sd*brw-r----- 1 root disk 8, 0 Apr 1 21:59 /dev/sdabrw-r----- 1 root disk 8, 1 Apr 1 21:59 /dev/sda1brw-r----- 1 root disk 8, 2 Apr 1 21:59 /dev/sda2brw-r----- 1 root disk 8, 3 Apr 1 21:59 /dev/sda3brw-r----- 1 root disk 8, 16 Apr 1 21:59 /dev/sdbbrw-r----- 1 root disk 8, 17 Apr 1 21:59 /dev/sdb1brw-r----- 1 root disk 8, 32 Apr 1 21:59 /dev/sdcbrw-r----- 1 root disk 8, 33 Apr 1 21:59 /dev/sdc1brw-r----- 1 root disk 8, 48 Apr 1 21:59 /dev/sddbrw-r----- 1 root disk 8, 49 Apr 1 21:59 /dev/sdd1
Siehe da. Alle Platten da.
Aber das ist nur gefährliches Halbwissen ;)

Ich habe gerade etwas voreilig folgendes getan:
[root@srvxen01 ~]# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 --forcemdadm: /dev/md0 has been started with 2 drives (out of 3).[root@srvxen01 ~]# mdadm --add /dev/md0 /dev/sdd1mdadm: added /dev/sdd1
Das erübrigt meine Frage, ob man den Superblock rekonstruieren kann, jetzt fängt er schon mit dem Rebuild an, obwohl die Daten ja die selben sein werden... (Nur aus Neugier: Hätte man den Superblock per Hand rekonstruieren können?)

Ich werde ja beim nächsten Neustart das selbe Problem haben, wenn ich mein Raid nicht jedes mal per Hand zusammenbauen will. Gibt es eine verständliche Lösung für das Problem?

Gruß
Fischerman

parted list