On Tue, 19 Jul 2005, Dirk Salva wrote:
Davon redete ich ja. Und: ja, Du mußt der initrd ja die UUID des RAID
bekanntmachen. Aus einem nicht nachvollziehbaren Grund hat das bei
mir nicht auf Anhieb geklappt, wir haben Stunden damit zugebracht,
das ans Rennen zu kriegen. Irgendwann gings auf einmal, und es
stellte sich raus, dass es tatsächlich nur daran lag, daß die initrd
das raid nicht kannte. Einmal gemacht, hat das auch zwei
Kernel-upgrade (Debian-Kernel) problemlos überlebt.
Ich habe mich heute nochmal drangesetzt und jetzt scheint es mit der
initrd zu laufen. Eigentlich wäre mir eine Lösung mit einem statischen
Kernel aber lieber gewesen. Das wiederum scheint möglich zu sein, wenn
man anstelle von grub lilo einsetzt. Sehe ich das richtig?
Unter Lilo gibts gem. der mdadm-doku einen Paramter namens:
raid-extra-boot=/dev/xxx,/dev/yyy
Damit ist eine initrd dann wohl überfluessig, solange die raid-module fest
in den Kernel eincompiliert sind.
Frage: Gibt es auch eine Möglichkeit bei grub auf eine intird zu
verzichten? Sprich: Kann Grub dem Kernel mitteilen, welche
Raid-Partionionen er direkt nach dem Booten zusammenbauen soll?
Daß muß jeder selbst wissen. Die Debian-Kernel haben ganz klar den
Vorteil, das ich mir mal ein oder zwei Systeme zusammengestellt habe,
die ich dann im Gros per copy (z.B. mit mc) auf eine neue HDD eines
anderen Rechner bringe. "Klone-light" sozusagen. Dann noch finetuning
bzgl. einiger Hardwaredinge, und das wars. Spart ne Menge Zeit gg.
jedesmal neu aufsetzen, User einrichten, UIDs anpassen usw.usf..
Wo ist der Unterschied zu einem statischen Kernel? Wenn das System auf
eine neue Hardware umzieht, muss ich ggf. den Kernel austausche. Aber den
Rest kann ich doch genauso umziehen. Oder meinst du etwas anderes?
Gruß,
Jörn