Waiting for devcie /dev/md0 to appear

[robi1a]

Hallo
Ich habe 3 SATA-Platten im meinem SUSE-Server. Das Root-Filesystem ist auf einer Partition (/dev/sdc1) drauf und ich möchte jetzt das Root-Filesystem auf ein Raid1 Array mit 2 Platten umbauen. (Ich habe das schon mehmals gemacht).
Mit folgender Anleitung:
1.) Auf 2. Platte eine Partition (/dev/sda1) des Type fd (Raid) definiert.
2.) Raid1 Array /dev/md0 (2 Platten) mit dieser Partition /dev/sda1 und MISSING angelegt
3.) ext3 Filesystem auf /dev/md0
4.) mit tar die ganze Root (/dev/sdc1) auf /dev/md0 kopiert
5.) mit grup neuen MBR geschrieben der auf die /boot/grub/menu.lst auf /dev/md0 (genau genommen auf /dev/sda1) zeigt.
6.) neue initrd erzeugt, die das raid1 Module enthält.

Wenn ich von /dev/sdc1 (alte Root) boot gibt es überhaupt kein Problem.
Boote ich von der neuen /dev/md0 (besser /dev/sda1) sieht der Ablauf schon komplett anders auf. Wohl gemerkt, es ist das selbe System! Beim Kernel Init kommen folgende Meldungen:
FATAL: Module ext3 not found
FATAL: Module ahci not found
Diese beiden Module sind direkt in den Kernel einkompiliert. Warum werden diese nicht gefunden bzw. initialisiert? Das raid1 Module wird zwar initialisiert, findet aber keine Partition. Zuletzt kommt dann noch
Waiting for device /dev/md0 to appear .....
Aber md0 "appeared" nicht. Kann ja auch nicht, ist ja der SATA Driver (ahci) und Filesystemdriver nicht aktiv. Wie schon gesagt, der selbe Kernel und die selbe initrd funktionieren wenn ich von /dev/sdc1 boote!!!

Mir sind jetzt die Ideen ausgegangen. Hat wer von Euch eine Idee oder einen Tipp?

[boo]

Nehm mal an du hast noch den legacy grub.
Wie schaut der entry vom Grub auf sda aus den du bootest? (Taste "e")

Edit: aber vielleicht geht das unter Susi Linux nur mitm Wastl? *feix*

[robi1a]

Das ist der Entry der funktioniert (dev/sdc1):

title Desktop -- openSUSE 11.2 - 2.6.31.14-0.4
    root (hd1,0)
    kernel /boot/vmlinuz-2.6.31.14-0.4-desktop root=/dev/disk/by-id/ata-STM31000528AS_9VP1M330-part1 resume=/dev/disk/by-id/ata-STM31000528AS_9VP1M20G-part2 splash=silent quiet showopts vga=0x314
    initrd /boot/initrd-2.6.31.14-0.4-desktop

Und dieser funktioniert nicht:

title Desktop -- openSUSE 11.2 - 2.6.31.14-0.4 (md0)
    root (hd0,0)
    kernel /boot/vmlinuz-2.6.31.14-0.4-desktop  root=/dev/md0  resume=/dev/disk/by-id/ata-STM31000528AS_9VP1M20G-part2 splash=silent  quiet showopts vga=0x314
    initrd /boot/initrd-2.6.31.14-0.4-desktop

[colossus]

Booten von md-Arrays funktioniert nur dann, wenn das fragliche Array auto-assembly kann - und das gibt es nur mit Superblock in Version 0.90 (nicht davor, nicht danach). Hast du so einen?

Ist dein RAID1 jetzt eigentlich schon mal up und clean gewesen, oder ist es degraded (weil die zweite Haelfte des Mirrors fehlt)? Auf dem neuen (md-)rootfs sollte sich zumindest das initramfs von der "alten" Installation auf der Einzelplatte unterscheiden, wenn ich deinen (mich leider etwas verwirrenden) ersten Post richtig verstanden habe. Das koennte auch die von dir beobachteten Unterschiede im Startvorgang von den beiden Volumes erklaeren.

[boo]

Welche module sind im initrd image? (sudo zcat initrd.img-2.6.32-5 |cpio -it)
Kannst du das md0 mounten wenn du von hd1 gebootet hast?

Edit: mir ist aufgefallen, dass du oben
1. schreibst einen neuen initrd gemacht zu haben
2. sagst dass auf beiden Platten derselbe initrd ist und
3. der name des initrds gleich geblieben ist?

Womit baust du den initrd, mit Yast?

[robi1a]

Hallo
Habe es gelöst. Habe 100000x mal drüber geschaut. Habe in der /etc/fstab nicht /dev/md0 als / stehen gehabt, sondern die "alte /dev/sdc1" Partition. Da gibt es einen bekannten Bug, dass dann die inird nicht korrekt generiert wird.

Lösung:
1.) /etc/fstab richtig gestellt
2.) mkinitrd
3.) boot von md0 funktioniert