

 
Eine existierende HOWTO beschäftigt sich bereits mit dem Thema, allerdings ist Sie erstens auf Englisch und zweitens geht es durch neue Kerneloptionen auch eleganter als dort beschrieben.
Bitte erleichtern Sie sich Ihre Arbeit und senken Sie das Frustnieveau, indem Sie vorab noch drei Tips beherzigen:
Für dieses Verfahren wird noch eine DOS oder Win95 Partition in Verbindung mit 
dem Loadlin benötigt. Loadlin befindet sich - so das Programm nicht schon eingesetzt 
wird - auf der ersten DLD CD unter /delix/RPMS/i386/loadlin-1.6.2.i386.rpm. 
Alternativ kann man sich auch eine Bootdiskette anfertigen.
Der Hintergrund ist ganz einfach der, daß LILO mit dem RAID-Device nicht zurechtkommt und man somit nicht explizit von diesem RAID-Device booten kann. Daher behilft man sich hier entweder mit Loadlin, oder aber mit einem Mini Linux auf einer kleinen Extra-Partition. Weitere Möglichkeiten zum Booten von Linux auch von RAID-Verbunden wurden bereits im Abschnitt Möglichkeiten des Bootens von Linux behandelt.
Nichts desto trotz bleiben wir bei dem Verfahren mit Loadlin. Das Programm 
befindet sich nach erfolgreicher Installation des RPMS-Paketes unter 
/dos/loadlin/. Auf der oben genannten nötigen DOS Partition richtet 
man sich nun ein Verzeichnis wie z.B. Linux ein und kopiert die Dateien 
loadlin.bat und loadlin.exe zusammen mit dem frischen 
Kernel, in den die RAID-Parameter einkompiliert wurden, hinein.
Um sicherzugehen, daß auch wirklich nichts passiert, sollte man entweder die nötigen Treiber für den (E)IDE Kontroller oder des passenden SCSI Kontroller auch mit in den Kernel einkompiliert haben.
Die Batchdatei loadlin.bat wird nun dahingehend angepaßt, daß wir 
die Parameter für das zu bootende RAID-Device gleich mit angeben:
md=<md device no.>,<raid level>,<chunk size>,dev0,...,devn 
Die Nummer des RAID (md) Devices: »1« steht für 
/dev/md1, »2« für /dev/md2 usw.
Welches RAID Level wird verwendet: »-1« für Linear Modus, »0« für RAID-0 (Striping).
Legt die Chunk Size fest bei RAID-0 und RAID-1 fest.
Eine durch Kommata getrennte Liste von Devices,
aus denen das md Device gebildet wird, z.B. /dev/hda1,/dev/hdc1,/dev/sda1. 
Andere RAID-Modi außer Linear und RAID-0 werden im Moment nicht unterstützt. 
Gemäß der vorher beschriebenen Anleitung würde die Zeile in der linux.bat 
dann so aussehen:
c:\linux\loadlin c:\linux\zimage root=/dev/md0 md=0,0,0,0,/dev/sda6,/dev/sdb6 ro
Dies soll nur eine einzige Zeile sein; außerdem ist auch hier wieder auf die 
richtige Reihenfolge der Partitionen zu achten. Weiterhin müßen natürlich zwei 
oder mehrere Partitionen - zu entweder einem RAID-0 oder einem Linear Device 
zusammengefaßt - bereits vorliegen. Der Kernel muß die o.a. Bootoption und die 
nötigen RAID oder Linear Parameter in den Kernel einkompiliert haben; man 
beachte: Nicht als Module. Dann mountet man das RAID-Device, welches später 
die Root-Partition werden soll, nach z.B. /mnt, kopiert mittels einer 
der im Abschnitt 
Möglichkeiten zum Kopieren von Daten beschriebenen 
Methoden die benötigten Verzeichnisse auf das RAID-Device.
Speziell für die DLD 6.0, aber auch für alle anderen Distributionen sei hier 
gesagt, daß beim Booten von einem RAID-Device der oben beschriebene Befehl 
mdadd -ar vor dem ersten mount Befehl auszuführen ist. Für die DLD 
6.0 heißt das konkret, daß der Befehl bereits in das Skript 
/etc/init.d/bc.mount_root eingetragen werden muß, da dort der erste 
mount Befehl ausgeführt wird. Benutzer anderer Distributionen sind 
hier auf sich gestellt oder schauen sich zur Not die Methode mit den neueun 
RAID-Tools Version 0.9x an; siehe Abschnitt
RAID-Verbunde mit den RAID-Tools Version 0.9x erstellen.
Jetzt fehlen nur noch die passenden Einträge in /etc/fstab und 
/etc/lilo.conf, in denen man auf dem neuen RAID-Device die 
ursprüngliche Root-Partition in /dev/md0 umändert - im Moment liegen 
diese Dateien natürlich noch unter /mnt.
An dieser Stelle sollte man die obige Liste noch einmal in Ruhe durchsehen, 
sich vergewissern, daß alles stimmt, und dann die DOS oder Win95 Partition 
booten. Dort führt man nun die Batchdatei linux.bat aus.
Im Abschnitt RAID-Verbunde mit den RAID-Tools Version 0.9x erstellen wurde bereits auf die vorzügliche Eigenschaft des automatischen Erkennens von RAID-Devices durch den Kernel-Patch beim Startup des Linux-Systems hingewiesen. Dieser Umstand legt die Vermutung nahe, daß es mit dieser Hilfe noch einfacher ist, die Root-Partition als RAID-Device laufen zu lassen. Das ist auch wirklich so, allerdings gibt es auch hierbei immer noch einige Kleinigkeiten zu beachten. Generell kann man Linux entweder mittels Loadlin oder mit Hilfe von LILO booten. Je nach Bootart ist die Vorgehensweise unterschiedlich aufwendig.
Für beide Fälle braucht man jedoch erstmal ein RAID-Device. Um bei dem 
Beispiel des RAID-0 Devices mit den Partitionen /dev/sda6 und 
/dev/sdb6 zu bleiben, nehmen wir dieses Device und mounten es in 
unseren Verzeichnisbaum.
Hier muß allerdings noch einmal darauf hingewiesen werden, daß ein RAID-0 Device als Root-Partition ein denkbar schlechtes Beispiel ist. RAID-0 besitzt keinerlei Redundanz; fällt eine Festplatte aus, ist das Ganze RAID im Eimer. Für eine Root-Partition sollte man deshalb auf jeden Fall ein RAID-1 oder RAID-5 Device vorziehen. Auch das funktioniert Dank der neuen Autodetect Funktion und wird analog dem beschriebenen RAID-0 Verbund eingerichtet.
Auf das gemountete RAID-Device /dev/md0 kopiert man nun ganz simpel 
mittels einer der im Abschnitt 
Möglichkeiten zum Kopieren von Daten 
beschriebenen Methoden das komplette Root-Verzeichnis.
Danach muß auf dem RAID-Device noch die Datei /etc/fstab so angepaßt 
werden, das als Root-Partition /dev/md0 drinsteht und nicht mehr die 
originale Root-Partition (z.B. /dev/sda1).
Erstellen Sie sich eine DOS-Bootdiskette - das pure DOS von Win95 tut es 
auch - und auf dieser ein Verzeichnis Linux. Hierher kopieren Sie nun aus dem 
passenden RPM-Paket Ihrer Distribution das DOS-Tool loadlin und Ihren 
aktuellen Kernel. Manchmal befindet sich loadlin auch unkomprimiert im 
Hauptverzeichnis der Distributions-CD. Der Kernel sollte natürlich die 
RAID-Unterstützung bereits implementiert haben. Nun erstellen Sie mit Ihrem 
Lieblingseditor in dem neuen Linux Verzeichnis eine loadlin.bat. Haben 
Sie Ihren Kernel z.B. vmlinuz genannt, sollte in der Datei 
loadlin.bat etwas in dieser Art stehen: 
a:\linux\loadlin a:\linux\vmlinuz root=/dev/md0 ro vga=normal 
Die Pfade müssen natürlich angepaßt werden. Ein Reboot und das Starten von der 
Diskette mit der zusätzlichen Ausführung der linux.bat sollte Ihnen 
ein vom RAID-Device gebootetes Linux bescheren. Booten Sie generell nur über
Loadlin, so endet für Sie hier die Beschreibung.
Möchten Sie allerdings Ihr neues Root-RAID mittels LILO booten, finden Sie im Abschnitt Möglichkeiten des Bootens von Linux diverse Methoden aufgelistet und teilweise sehr genau beschrieben, mit denen Sie sich noch bis zum endgültigen Erfolg beschäftigen müßten.
Hat man sich bei einer anderen Distribution als SuSE 6.2 für einen 
Root-RAID Verbund entschieden, der im Fehlerfall auch von der zweiten 
Festplatte booten soll, muß man noch folgendes beachten: Da auch auf der 
zweiten Festplatte eine Boot-Partition benötigt wird, die zwar ebenso in der 
/etc/fstab aufgenommen wurde, aber im Fehlerfall nicht mehr 
vorhanden ist, fällt die SuSE 6.2 Distribution in einen Notfall-Modus, in dem das 
root-Paßwort eingegeben werden muß und das fragliche Dateisystem repariert 
werden soll. Dies kann Ihnen auch bei anderen Distributionen passieren.
Es wird also ein Weg benötigt, die beiden Boot-Partitionen /boot und 
/boot2 nur dann zu mounten, wenn sie tatsächlich körperlich im 
Rechner vorhanden sind. Hierbei hilft ihnen das Skript mntboot:
#!/bin/sh
 
MNTBOOTTAB=/etc/mntboottab
 
case "$1" in
  start)
    [ -f $MNTBOOTTAB ] || {
      echo "$0: *** $MNTBOOTTAB: not found" >&2
      break
    }
 
    PARTS=`cat $MNTBOOTTAB`
 
    for part in $PARTS ; do
      [ "`awk '{print $2}' /etc/fstab | grep "^$part$"`" == "" ] && {
        echo "$0: *** Partition $part: not in /etc/fstab" >&2
        continue
      }
 
      [ "`awk '{print $2}' </proc/mounts | grep "^$part$"`" != "" ] && {
        echo "$0: *** Partition $part: already mounted" >&2
        continue          
      }
 
      fsck -a $part
      [ $? -le 1 ] || {
        echo "$0: *** Partition $part: Defect? Unavailable?" >&2
        continue
      }
 
      mount $part || {
        echo "$0: *** Partition $part: cannot mount" >&2
        continue
      }
    done
 
    exit 0
    ;;
 
  *)
    echo "usage: $0 start" >&2
    exit 1
    ;;
esac            
Das Skript gehört bei SuSE Distributionen nach /sbin/init.d, bei 
vermutlich allen anderen Linux Distributionen nach 
/etc/rc.d/init.d. Auf das Skript sollte ein symbolischer Link 
/sbin/init.d/rc2.d/S02mntboot zeigen. Für alle anderen gilt es 
hier einen Link nach /etc/rc.d/rc3.d/S02mntboot zu setzen, da außer 
den SuSE Distributionen wohl alle im Runlevel 3 starten und Ihre Links dafür 
in diesem Verzeichnis haben. Das Skript prüft ein paar Nebenbedingungen für 
diejenigen Partitionen, die in /etc/mntboottab eingetragen sind 
(darin sollten /boot und /boot2 stehen) und ruft jeweils 
fsck und mount für diese Partitionen auf. Da es bei allen 
anderen Distributionen keine /etc/mntboottab gibt, gilt es hier diese 
zu erstellen oder anzupassen.
In der /etc/fstab sollten diese Partitionen mit »noauto« statt 
»defaults« eingetragen werden. Außerdem muß im sechsten Feld der Wert »0« 
stehen, da die Distribution im Backup-Fall sonst in den Notfall-Modus fällt.
Sie überlegen sich, RAID auch für Swap Partitionen einzurichten? Diese Mühe können Sie sich sparen, denn der Linux-Kernel unterstützt das RAID-Verhalten auf Swap-Partitionen quasi »von Haus aus«. Legen Sie einfach auf verschiedenen Festplatten ein paar Partitionen an, änderen Sie den Partitionstyp mittels
fdisk /dev/Ihre-Partition
und der Option »t« auf 82 und erstellen Sie das Swap Dateisystem:
mkswap /dev/Ihre-neue-Swap-Partition
Nun fügen Sie diese in die /etc/fstab ein und geben allen 
Swap-Partitionen dieselbe Priorität.
/dev/hda3 swap swap defaults,pri=1    0 0 
/dev/hdb3 swap swap defaults,pri=1    0 0 
/dev/sda4 swap swap defaults,pri=1    0 0 
Vom nächsten Startup an werden die Swap Partitionen ähnlich wie ein RAID-0 Device behandelt, da die Lese- und Schreibzugriffe ab jetzt gleichmäßig über die Swap-Partitionen verteilt werden.
Will man aus irgendwelchen Gründen zwei Swap-Partitionen höher priorisieren 
als eine Dritte, so kann man das auch über den Parameter »pri=« ändern, 
wobei die Priorität einen Wert zwischen »0« und »32767« annehmen kann. Ein höherer 
Wert entspricht einer höheren Priorität. Je höher die Priorität desto eher 
wird die Swap-Partition beschrieben. Bei der folgenden Konfiguration würde 
also /dev/hda3 wesentlich stärker als Swap-Partition genutzt werden 
als /dev/hdb3. 
/dev/hda3 swap swap defaults,pri=5    0 0 
/dev/hdb3 swap swap defaults,pri=1    0 0 
Erstellt man die Swap-Partition auf einem vorhandenen RAID-1 Verbund, 
formatiert sie dann mittels mkswap /dev/mdx und trägt sie als 
Swap-Partition in die /etc/fstab ein, so hat man zwar keinen, oder 
nur einen kleinen lesenden Geschwindigkeitsvorteil, jedoch den großen, nicht 
zu unterschätzenden Vorteil, daß man bei einem Festplattendefekt nach dem 
Ausschalten des Rechners und dem Austausch der defekten Festplatte, ohne 
weitere manuelle Eingriffe wieder ein vollständig funktionierendes System hat. 
Der einzige Wermutstropfen betrifft hierbei die Freunde des Hot Plugging. 
Erfahrungsgemäß verkraftet Linux das Hot Plugging eines dermaßen gestalteten 
RAID-1 Verbundes nur, wenn vorher die Swap-Partitionen mittels swapoff -a 
abgeschaltet wurden.
Als Warnung sei hier aber noch der schlimmste Fall genannt, über den man sich Gedanken machen sollte: Hat man die Swap-Partition auf einen RAID-1 Verbund gelegt und zusätzlich dafür eine Spare-Disk reserviert, so würde diese Spare-Disk natürlich bei einem Festplattendefekt sofort eingearbeitet werden. Das ist zwar erwünscht und auch so gedacht, jedoch funktioniert das Resynchronisieren dieses RAID-1 Verbundes mit einer aktiven Swap-Partition nicht. Die Software-RAID Treiber nutzen beim Resynchronisieren den Puffer-Cache, die Swap-Partition aber nicht. Das Ergebnis ist eine defekte Swap-Partition.
Als Lösung bleibt nur die Möglichkeit, keine Spare-Disks zu benutzen und nach 
einem Festplattenausfall swapoff -a per Hand auszuführen, die defekte 
Festplatte auszutauschen und nach dem Erstellen der Partitionen und des 
Swap-Dateisystems mit swapon -a wieder zu aktivieren.
Ein Problem bleibt dennoch: Gesetzt den Fall der Linux-Rechner würde aufgrund eines Stromausfalls nicht sauber heruntergefahren worden sein, so werden die RAID-Verbunde beim nächsten Startup automatisch resynchronisiert. Dies erfolgt mit einem automatischen »ge-nice-ten« Aufruf des entsprechenden RAID-Daemons im Hintergrund bereits zu Anfang der Bootprozedur. Im weiteren Bootverlauf werden aber irgendwann die Swap-Partitionen aktiviert und treffen auf ein nicht synchronisiertes RAID. Das Aktivieren der Swap-Partitionen muß also verzögert werden, bis die Resynchronisation abgeschlossen ist.
Wie unter Linux üblich läßt sich auch dieses Problem mit einem Skript lösen. 
Der Gedanke dabei ist, den Befehl swapon -a durch ein Skript zu ersetzen, 
welches die Pseudodatei /proc/mdstat nach der Zeichenfolge 
resync= durchsucht und im Falle des Verschwindens dieser Zeichenfolge 
die Swap-Partitionen aktiviert. Im folgenden finden Sie ein Beispiel abgedruckt:
#!/bin/sh
#
RAIDDEVS=`grep swap /etc/fstab | grep /dev/md|cut -f1|cut -d/ -f3`
for raiddev in $RAIDDEVS
do
#  echo "testing $raiddev"
    while grep $raiddev /proc/mdstat | grep -q "resync="
    do
#     echo "`date`: $raiddev resyncing" >> /var/log/raidswap-status
      sleep 20
     done
     /sbin/swapon /dev/$raiddev
done
exit 0


