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/yyyDamit 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