Seuftz... ich hab eine Bootpartition die auf einem RAID 1 liegt, verteilt ueber drei Platten. Das Problem bei GRUB ist es nicht, ihn in den Bootrecord einzuspielen, denn der wuerde sich einfach in den Bootrecord der einzelnen Partitionen reinschreiben, sondern eben das reinschreiben mit beruecksichtigung der Reihenfolge der einzelnen Platten und Partitionen.
Zum bessern Verständnis vielleicht eine Beschreibung zu lilo: wenn ich in ein Software RAID 1 unter Linux mit LILO bootable mache, dann schreibt lilo in jeden Bootsektor die entsprechenden Infos so rein, als handele es sich um eine einzelne Platte. Da lilo die Blocks der Platte abspeichert speichert er natuerlich auf z.B. sda1 die Blocks wo der Kernel auf sda1 liegt im Bootrekord von sda1, Das glaiche bei sdb1 und sdc1. Faellt nun sda aus, so kann lilo gleich von sdb booten da er saemltiche Bootinformationen ja im Bootrecord speziell fuer sdb bereitstellt.
Wie offensichtlich funktioniert das nicht bei einem anderen Software RAID als RAID 1, denn dann koennte der Kernel ueber mehrere Platten verteilt liegen und weder lilo noch Grub haben RAID-Treiber eingebaut.
Bei Grub ist das Problem, dass er nicht Blocks, sondern das Filesystem liest, Was grundsaetzlich weniger ein Problem waere, sondern die zugehörige Notation. Da Grub vom Filesystem liest, ist er vielleicht noch in der Lage, bei einem Ausfall von z.B. sdb1 dies im STAGE1 zu kompensieren, indem er sich in jeden Bootrekord der beteiligten Partitionen schreibt, aber in der menu.lst stehen ja genaue Informationen zu den anzusprechenden Platten drin. Faellt also sda aus so kann es sein, dass bei (hd0,1) kein Kernel mehr liegt und er deswegen nicht gefunden wird. Dies kann z.B. vorkommen wenn ich sda1, sdb2 und sdc3 als RAID verwenden wuerde, was jedoch bei lilo funktioniert.
Weder Grub noch Lilo werden jemals in der Lage sein, von etwas anderem als RAID1 zu booten, denn die einzubauende unterstützung von Software Raid duerfte jeden Rahmen sprengen.
Das sicherste ist es, /boot mit lilo auf ein RAID 1 zu legen und gegebenfalls, wenn man z.B. XEN benoetigt, ueber Chainload ein Grub zu "booten"..
Zum bessern Verständnis vielleicht eine Beschreibung zu lilo: wenn ich in ein Software RAID 1 unter Linux mit LILO bootable mache, dann schreibt lilo in jeden Bootsektor die entsprechenden Infos so rein, als handele es sich um eine einzelne Platte. Da lilo die Blocks der Platte abspeichert speichert er natuerlich auf z.B. sda1 die Blocks wo der Kernel auf sda1 liegt im Bootrekord von sda1, Das glaiche bei sdb1 und sdc1. Faellt nun sda aus, so kann lilo gleich von sdb booten da er saemltiche Bootinformationen ja im Bootrecord speziell fuer sdb bereitstellt.
Wie offensichtlich funktioniert das nicht bei einem anderen Software RAID als RAID 1, denn dann koennte der Kernel ueber mehrere Platten verteilt liegen und weder lilo noch Grub haben RAID-Treiber eingebaut.
Bei Grub ist das Problem, dass er nicht Blocks, sondern das Filesystem liest, Was grundsaetzlich weniger ein Problem waere, sondern die zugehörige Notation. Da Grub vom Filesystem liest, ist er vielleicht noch in der Lage, bei einem Ausfall von z.B. sdb1 dies im STAGE1 zu kompensieren, indem er sich in jeden Bootrekord der beteiligten Partitionen schreibt, aber in der menu.lst stehen ja genaue Informationen zu den anzusprechenden Platten drin. Faellt also sda aus so kann es sein, dass bei (hd0,1) kein Kernel mehr liegt und er deswegen nicht gefunden wird. Dies kann z.B. vorkommen wenn ich sda1, sdb2 und sdc3 als RAID verwenden wuerde, was jedoch bei lilo funktioniert.
Weder Grub noch Lilo werden jemals in der Lage sein, von etwas anderem als RAID1 zu booten, denn die einzubauende unterstützung von Software Raid duerfte jeden Rahmen sprengen.
Das sicherste ist es, /boot mit lilo auf ein RAID 1 zu legen und gegebenfalls, wenn man z.B. XEN benoetigt, ueber Chainload ein Grub zu "booten"..
gruss,
die mad