Am Tuesday 02 June 2009 13:12:56 schrieb Manfred Kreisl:
Manfred Kreisl schrieb:
Wenn --grow nicht mehr geht, weil nicht aktiv( oder nicht gestartet, was auch immer), und ein Notsystem aktiv ist, würde ich es riskieren, das Array mit mdadm neu anzulegen, nicht mit yast, und neu zu befüllen. Und nicht vergessen /etc/mdadm.conf zu editieren, denn da sollte die UUID drinstehen.
Sind dann nicht alle Daten futsch? Ich hab das auch schon als Tip irgendwo gelesen, aber das möchte ich doch wirklich als allerletzten Versuch machen. Ok, das werd' ich auch mal in meiner Test-VM probieren, die hab ich glücklicherweise aufm meinem Win-XP System noch
Also, das hab ich grad mal in der Test-VM probiert. Hab einfach mal in KNOPPIX 6.1 ein # mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/hda3 /dev/hdb3 missing gemacht und oh Wunder oh Wunder das LVM lässt sich noch starten. Allerdings das OS bootet nicht mehr, liegt wohl daran dass sich die ID's geändert haben und die in der initrd nicht mehr passen. Seltsam ist auch noch, dass ich wenn ich # mdadm --examine --scan --config=partitions aufrufe ich zweimal das ARRAY /dev/md1 gelistet bekomme mit zwei verschiedenen UUIDs Die ganze Sache verwirrt mich mehr und mehr
Gruß Manfred
Hallo Manfred, Ich denke (hoffe), dass die Daten auf dem Array erst dann weg sind, wenn Du ein neues Dateisystem oder ein neues LVM anlegst. Dann könntest Du nach Erzeugung des Arrays das LVM vielleicht starten, Da Du die Daten auf einem Notsystem verfügbar hast (habe ich doch hoffentlich richtig verstanden), dann kannst Du die Daten ja auch zurückkopieren, wenn es schief geht. Ich habe meinen Kernel so konfiguriert, dass ich keine initrd brauche, ich glaube aber nicht, dass die beim Booten Probleme macht, sondern die /boot/grub/menu.lst oder die Einträge in der /etc/fstab. Ich mounte meine Dateisysteme hier via Label, da habe ich es in der Hand, ob es geht oder nicht (wenn ich das Erstellen des Labels vergesse, kann man aber mit e2label nachholen). Hier meine Zeilen aus der menu.lst: title Emil -- openSUSE 11.0 - 2.6.29.4 root (hd0,1) kernel /boot/vmlinuz-2.6.29.4-emil root=/dev/md0 resume=/dev/sda1 \ splash=none showopts noinitrd vga=0x346 Und hier aus der /etc/fstab: LABEL=root / ext2 acl,user_xattr 1 1 LABEL=usr /usr ext3 acl,user_xattr 1 2 LABEL=var /var ext3 acl,user_xattr 1 2 LABEL=opt /opt ext3 acl,user_xattr 1 2 LABEL=srv /srv ext3 acl,user_xattr 1 2 LABEL=tmp /tmp ext2 acl,user_xattr 0 2 Man könnte fast sagen, um eine Operation am offenen Herzen kommst Du vielleicht nicht mehr herum. Mit --config=partitions ignoriert er die Konfigurationsdatei und schaut in /proc/partitions nach, welche Geräte er scannen soll. Vermutlich findet er da 2 RAID-Superblöcke, einen alten und einen neuen. Ich hatte eine Zeit lang ein RAID-1 auf meinen externen Backup-Platten. Da externe Platten und deren Bedienung aber unsicher sind (mal legen diese sich zur falschen Zeit schlafen, mal vergesse ich, eine einzuschalten), bin ich wieder zur Spiegelung via rsync zurückgekehrt. Ein Scan mit mdadm hat mir das Array aber immer noch angezeigt. Ich habe dann ganz. ganz scharf gerechnet und mit dd die alten RAID-Superblöcke gelöscht. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org