Gruesse!
* Werner Detter <[EMAIL PROTECTED]> schrieb am [09.01.05 16:32]:
> > Markierung des Quell-Devices als failed-disk *nur* vor dem
> > Synchronisieren, danach muss diese Partition auch als raid-disk
> > definiert sein.
>
> klar, nur dann ist alles unwiderruflich (wenn etwas schief gegangen ist)
> auf der ersten platte verloren, daher meine idee
> das system auf der zweiten platte auch bootbar zu machen um das setup
> auf der zweiten platte zu testen (lilo in den mbr
> der zweiten platte schreiben und dann versuchen das system auf der zweiten
> platte zu booten).
Aber das w�rde doch nur Sinn machen, wenn du dir (hardware-seitig)
irgendwie nicht sicher sein k�nntest, das die zweite Platte booten
kann. Entscheidend und wichtiger ist doch der Test, ob das Raid die
zweite, gespiegelte Platte nach einem Ausfall der ersten genauso
bootet.
Wenn du wirklich die zweite Platte nach dem h�ndischen Kopieren booten
willst, m��test du IMHO:
$2.HD/ -> /mnt/newroot
$2.HD/boot -> /mnt/newroot/boot
mounten. Dann mu�t du die /mnt/newroot/fstab anpassen auf sdb. Genauso
die /mnt/newroot/lilo.conf: boot=/dev/sdb, root=/dev/sdbXXX
Daher d�rfte auch dein lilo Problem aus der ersten Mail kommen. Der
boot Eintrag mu� immer auf ein pysikalisches Device (bei dir sda
und/oder sdb) lauten. Der root Eintrag beim asynchonen Test auf
/dev/sdbXXX, beim Raid-Test auf /dev/mdXXX. Sp�ter, bei aktivem Raid
�ber beide Platten bietet dir lilo mit dem Parameter -x die M�glichkeit
MBRs auf alle beteiligten Platten zu legen.
Dann lilo -r /mnt/newroot
Beim Booten mu�t du dann BIOS bzw. Controller-seitig sicherstellen, da�
von der zweiten statt von der ersten Platte gebootet wird.
Diese �nderungen mu�t du auch nachher wieder r�ckg�ngig machen, weil im
Raid definitiv auch die lilo.conf bzw. die ftab identisch sein m�ssen.
Aber wie gesagt, hierbei ist RAID vollkommen aus dem Spiel. Und es w�re
IMHO wichtiger zu testen, ob das Raid nach einem Ausfall wirklich
"umschaltet".
> > Da hast du (Software-)Raid nicht ganz verstanden. Dieses "Kopieren"
> > macht das Raid, wenn es denn aktiv ist,
> das ist genau der punkt, bei mir ist es _noch_ nicht aktiv. das initiale
> setup von raid beinhaltet das kopieren der daten auf die zweite platte.
> ich m�chte die funktionalit�t vor dem liveschalten des raid1 testen, d.h.
> sicherstellen, dass das system auch von der zweiten platte bootet.
Wenn die Platte nicht defekt ist wird sie, entsprechend gespiegelt, das
tun. So wie du das vorhast zu testen w�re zwei asynchrone Systeme
einzel zu testen (unterscheidliche fstab, lilo wegen sd[a|b]. Du willst
aber eigentlich: Ausfall 1.Platte+kein MBR -> MBR auf zweiter Platte
springt ein -> Raid merkt 1.Platte defekt -> 2.Platte wird wie erste
behandelt.
Wie gesagt, im Howto Abschnitt 7.4.2 wird dein Fall eigentlich genau
beschrieben. Und solange deine erste Platte als failed eingetragen ist
wird die vom Raid auch nicht angefa�t.
> > dein Raid ist nicht aktiv. Von 2 "DISKS [2/1] ist nur eine als gut
> > markiert, die andere als ausgefallen [U_]. Du hast also kein Raid-1.
> i know, das ist so gewollt. solange ich nicht weiss ob das system von der
> zweiten platte bootet, kann ich das raid nicht scharf schalten.
Diesen Test beschreibt Abschnitt 7.4.2 ja gerade. Die
Quell-Partition(en) bleiben, als failed markiert, unangetastet. Aber es
wird als Raid-Verbund (eben mit einer defekten Platte) gebootet.
Dazu k�nnte ich bei Bedarf auch noch ausf�hrlicher werden.
>
> weitere ideen
>
> vielen dank und schoene gruesse,
> werner
Gru�
Gerhard
