Quelltext der Seite NonRaid zu (software)Raid1 SuSE 10 1

Oftmals entscheidet man sich nicht schon bei der Installation dazu, auf ein Software-RAID zu installieren, um z.B. erst ein neues System zu testen bevor das alte entfernet wird. Eine Neuinstallation ist auch nicht immer wünschenswert, wenn bereits Arbeit in das neue System geflossen ist.

Ein schon laufendes System später auf RAID-1 umzustellen ist duchaus möglich, benötigt aber eine Menge Handarbeit. Eine andere Möglichkeit ist, über ein komplettes System-Backup zu gehen, man läuft aber dennoch Gefahr, in die Konfigurationsfallen zu tappen.

Leider ist es so, dass die meisten HOWTOs zu diesem Thema wegen irgendwelcher Kleinigkeiten, Versionsänderungen an diversen Programmen oder Scripten, oder Suse-Spezialitäten nicht auf einem SuSE 10.1 und SCSI-Devices funktionieren, desshalb habe ich mal meine Erfahrungen zu einem HOWTO zusammengestellt.


{{UnderConstruction}}
'''eben diese Kleinigkeiten haben  wieder einmal dazu geführt, das das Howto in der Version oS 10.3 bei meinen Tests kläglich versagte und wieder einmal eine Überarbeitung dieses Artikels und ausführliche Test notwendig geworden sind. Also bitte noch etwas Geduld, dann klapps auch (hoffendlich) wieder mit 10.3 ''' [[Benutzer:Robi|Robi]] 19:24, 27. Feb. 2008 (CET)




'''Warnung:''' Jedes Linuxsystem ist anders konfiguriert, es müssen also evtl. einige Optionen innerhalb der Befehle an jedes System angepasst werden statt dass sie direkt abgetippt werden können.
Es ist erforderlich, einige Erfahrungen im Umgang als root auf einer Shell unter Linux allgemein zu haben, sowie mit <code>fstab</code> und GRUBs <code>menu.lst</code>. Erfahrungen mit mdadm können keinesfalls schaden.

Die bestehende Konfiguration:
 automat:/proc # fdisk -l
 
 Disk /dev/sda: 36.7 GB, 36703932928 bytes
 64 heads, 32 sectors/track, 35003 cylinders
 Units = cylinders of 2048 * 512 = 1048576 bytes
 
    Device Boot  Start    End    Blocks  Id  System
 /dev/sda1   *       1     65     66544  83  Linux
 /dev/sda2          66   5186   5243904  83  Linux
 /dev/sda3        5187  25667  20972544  83  Linux
 /dev/sda4       25668  35003   9560064   f  W95 Ext'd (LBA)
 /dev/sda5       25668  27716   2098160  82  Linux swap / Solaris
 /dev/sda6       27717  35003   7461872  83  Linux 
 
 Disk /dev/sdb: 36.7 GB, 36703932928 bytes
 64 heads, 32 sectors/track, 35003 cylinders
 Units = cylinders of 2048 * 512 = 1048576 bytes
 
    Device Boot  Start    End    Blocks  Id  System
 /dev/sdb1           1  35003  35843056  83  Linux 
 
 
 automat:/proc # cat /etc/fstab
 /dev/sda2  /              ext3    acl,user_xattr    1 1
 /dev/sda5  swap           swap    pri=42            0 0
 /dev/sda1  /boot          ext2    acl,user_xattr    1 2
 /dev/sda3  /home          ext3    acl,user_xattr    1 2
 /dev/sda6  /data          ext2    auto,ro           1 2
 devpts     /dev/pts       devpts  mode=0620,gid=5   0 0
 proc       /proc          proc    defaults          0 0
 usbfs      /proc/bus/usb  usbfs   noauto            0 0
 sysfs      /sys           sysfs   noauto            0 0
 /dev/fd0   /media/floppy  auto    noauto,user,sync  0 0


Es gibt also zwei gleiche Platten, wovon sdb derzeit nicht in Benutzung ist. Vorhanden sind auch mehrere Linux-Filesysteme (<code>/home</code>, <code>/data</code>), auch <code>/boot</code> ist ein separates Filesystem. Das Howto ist so geschrieben, dass es egal ist, ob die Daten separat (wie hier) oder alles auf einer (Root)partition ist.
Zuerst klonen wir die gesamte Partionstabelle von sda nach sdb:

 automat:/proc # sfdisk -d /dev/sda  > /tmp/sda.txt
 automat:/proc # sfdisk /dev/sdb < /tmp/sda.txt
 Checking that no-one is using this disk right now ...
 OK
 
 Disk /dev/sdb: 35003 cylinders, 64 heads, 32 sectors/track
 Old situation:
 Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0
 
    Device Boot Start     End  #cyls    #blocks  Id  System
 /dev/sdb1          0+  35002  35003-  35843056  83  Linux
 /dev/sdb2          0       -      0          0   0  Empty
 /dev/sdb3          0       -      0          0   0  Empty
 /dev/sdb4          0       -      0          0   0  Empty
 New situation:
 Units = sectors of 512 bytes, counting from 0
 
    Device Boot    Start       End  #sectors  Id  System
 /dev/sdb1   *        32    133119    133088  83  Linux
 /dev/sdb2        133120  10620927  10487808  83  Linux
 /dev/sdb3      10620928  52566015  41945088  83  Linux
 /dev/sdb4      52566016  71686143  19120128   f  W95 Ext'd (LBA)
 /dev/sdb5      52566048  56762367    4196320  82  Linux swap / Solaris
 /dev/sdb6      56762400  71686143   14923744  83  Linux
 Successfully wrote the new partition table
 
 Re-reading the partition table ...
 
 If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
 to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
 (See fdisk(8).)

Wer KDE offen hat: dort gehen eventuell ein paar Fenster auf, dass neue Devices gefunden wurden. Diese sind mit "Abbrechen" zu schließen.
<code>fdisk -l</code> zeigt nun, dass alle Partitionen auf sda und sdb gleich sind. Da sdb z.Zt. nicht in Benutzung ist, wird kein Neustart benötigt.
Wir beginnen zunächst damit das Root-Filesystem auf einem RAID-Device aufzubauen und dieses zum Laufen zu bekommen.
sda wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootfähig.

{{Box Hinweis||
bei openSuse 10.3 sollten wir an dieser Stelle unbedingt einmal überprüfen ob das Initscript '''boot.md''' beim Booten gestartet wird, ansonsten sollten wir das jetzt hier entsprechend einrichten, bevor uns der Rechner bei einem Reboot ohne konfigurierte Raid-Device hängen bleibt.
}}

Zum Testen ob das Script '''boot.md''' beim Start ausgeführt wird reicht folgender Befehl
 ls /etc/init.d/boot.d/*boot.md 
kommt hier als Antwort 
 ls: cannot access /etc/init.d/boot.d/*boot.md: No such file or directory
dann ist folgender Befehl auszuführen damit das Script dann in Zukunft wirklich beim Booten nach Raiddevices sucht und diese startet. 
 insserv /etc/init.d/boot.md


So jetzt wird es ernst und zuerst erstellen wir ein RAID-1-Device für unser zukünftig gespiegeltes Rootfilesystem mit einer fehlenden Komponente mit sdb2 als einziger aktive Komponente.
Zunächst wird die Partitions-ID von sdb2 geändert: ''(das ist zwar nicht zwingend erforderlich, da es unter Linux von keinerlei Programm wirklich ausgewertet wird, aber es erleichtert uns später den Überblick zu bewaren, was schon konfiguriert ist und was noch nicht)''

 automat:/proc # sfdisk --change-id /dev/sdb 2 fd
 Done
 automat:/proc # sfdisk -R /dev/sdb


Eventuell (insbesondere nachdem die Platte vorher mit Nullen überschrieben worden ist) könnte hier eine Fehlermeldung in der Art "DOS kompatibilitäsproblem" kommen.<br>
In diesem Fall die Option --force probieren, weitere Infos gibt es auch in einem [[Partitionstabelle sichern und wiederherstellen|eigene Howto]] zu diesem Thema. Wenn wir die komplette Platte spiegeln sollte jedenfalls unser Ziel auch eine identische Partitionstabelle auf beiden Platten sein.
 
Eventuell tauchen unter KDE jetzt wieder Fenster auf, die mit Abbruch zu schließen sind.
Ein Blick auf <code>fdisk -l</code> zeigt nun, dass bei sdb2 wirklich <code>fd</code> als ID eingetragen ist.
Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird:

 automat:/ # mdadm -C /dev/md0 -b internal -e 1.0 -l1 -n2 missing /dev/sdb2
 mdadm: /dev/sdb2 appears to be part of a raid array:
     level=raid1 devices=2 ctime=Sat Aug 19 21:27:47 2006
 Continue creating array? y
 mdadm: array /dev/md0 started.

Die Nachfrage nach "appears to be part of a raid array" kann daraus resultieren, wenn die Partition bereits einen MDRAID-Superblock enthielt (z.B. von vorhergehenden Tests mit mdadm). Den Erfolg können wir wie folgt überprüfen:

 automat:/proc # cat /proc/mdstat
 Personalities : [raid1]
 md0 : active raid1 sdb2[1]
       5243840 blocks [2/1] [_U]
      
 unused devices: <none>

und/oder

 automat:/proc # mdadm -D /dev/md0
 /dev/md0:
         Version : 01.00.03
   Creation Time : Sat Aug 19 21:27:47 2006
      Raid Level : raid1
      Array Size : 5243840 (5.00 GiB 5.37 GB)
     Device Size : 5243840 (5.00 GiB 5.37 GB)
    Raid Devices : 2
   Total Devices : 1
 Preferred Minor : 0
     Persistence : Superblock is persistent
 
     Update Time : Sat Aug 19 21:27:47 2006
           State : clean, degraded
  Active Devices : 1
 Working Devices : 1
  Failed Devices : 0
   Spare Devices : 0
 
            UUID : edf2a03f:8371ba02:b75cfbef:b1415c61
          Events : 0.1
 
 Number  Major  Minor  RaidDevice State
    0      0       0       0      removed
    1      8      18       1      active sync  /dev/sdb2 

Wir tragen jetzt unser konfiguriertes RAID-Device in die mdadm.conf ein. Es ist erforderlich, eine DEVICES-Zeile in mdadm.conf einzufügen (sofern dies noch nicht geschehen ist), damit mdadm beim Booten die dort gelisteten Blockgeräte überhaupt für das Aktivieren von Arrays in Betracht zieht. Sollte es also noch keinen passenden DEVICES-Eintrag geben, ist dieser hinzuzufügen:

 automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf

Der folgende Befehl scannt nun die /dev/md*-Geräte durch und trägt ihre Eigenschaften in mdadm.conf ein:

 automat:/ # mdadm --detail --scan >> /etc/mdadm.conf
 automat:/ # cat /etc/mdadm.conf
 DEVICE /dev/sd[a-z][0-9]
 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=edf2a03f:8371ba02:b75cfbef:b1415c61

Nächster Punkt ist, das Filesystem auf /dev/md0 anzulegen, temporär zu mounten und die originalen Dateien dorthin zu kopieren.

 automat:/ # mkfs.ext3 -j /dev/md0
 ...
 ...
 automat:/ # mount /dev/md0 /mnt
 automat:/ # rsync -AHPSXavx / /mnt/

Der abschließende Slash bei <code>/mnt/</code> ist für das gewünschten Ziel-Layout unbedingt erforderlich.

Vorteil von rsync gegenüber anderen Programmen ist ACLs (<code>-A</code>) und Xattrs (<code>-X</code>) übertragen werden -- dies ist insbesondere bei Samba-Systemen wichtig. (Die Option <code>-A</code> ist vor SUSE Linux 10.1 nicht vorhanden; die Option <code>-X</code> nicht vor openSUSE 10.2.) rsync bietet darüber hinaus eine Statusanzeige und kann abgebrochene Transfers wieder aufnehmen. Sollte der Transfer allgemein länger dauern, so empfiehlt es sich nach Abschluss nochmals rsync laufen zu lassen, um Dateien, die während des 1. Versuchs geändert wurden, auch noch zu übertragen. Man ruft hierzu rsync mit gleichen Parametern und zusätzlich <code>--delete-during</code> (sollte die Option nicht bekannt sein, ist auf <code>--delete</code> auszuweichen) aufzurufen.

Jetzt ändern wir auf dem "neuem" Rootfilesystem die fstab 

 automat:/ # cd /mnt/etc
 automat:/mnt/etc # vi fstab
 /dev/sda2  /  ext3  acl,user_xattr  1 1  (dieses ist der alte Zeile)
 /dev/md0   /  ext3  acl,user_xattr  1 1  (das ist geänderte Zeile) 

{{Box Hinweis||
bei openSuse 10.3 und wahrscheinlich nachfolgenden Versionen wird per default in der fstab nicht über den Deviceknoten direkt, sondern über die Disk-by-Id angesprochen. Dieser Link verweist dann seinerseits auf den Geräteknoten. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen könnte.
}}
erste Zeile auskommentiert ist das Orginal und 2 Zeile der neue Eintrag für das Raid 
<pre>
#/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 /                    ext3       acl,user_xattr        1 1
/dev/md0 /                    ext3       acl,user_xattr        1 1
</pre>



Das Filesystem wird dann wieder ausgehangen und <code>/boot/grub/menu.lst</code> angepasst: 

 automat:/mnt/etc # cd /
 automat:/ # umount /mnt
 automat:/ # cd /boot/grub
 automat:/boot/grub # vi menu.lst

Ein neuer Eintrag auf Basis des alten wird eingefügt, ändern aber das root= Argument so, dass nun md0 als neues Root-Filesystem dienen soll. Der normale Booteintrag sollte zunächst beibehalten werden:

 #(normaler Booteintrag bleibt stehen)
 ###Don't change this comment - YaST2 identifier: Original name: linux###
 title SUSE Linux 10.1
     root (hd0,0)
     kernel /vmlinuz root=/dev/sda2 vga=0x314 acpi=off resume=/dev/sda5 splash=silent  showopts
     initrd /initrd
 #(nachfolgender Booteintrag kommt neu hinzu)
 #--------- RAID----------#
 title SUSE RAID 10.1
     root (hd0,0)
     kernel /vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/sda5 splash=silent  showopts
     initrd /initrd 
{{Box Hinweis||
bei openSuse 10.3 hier ebenfals das Problem mit der Disk-by-ID. Hier ein Beispiel wie diese Änderung dann unter 10.3 prinzipell aussehen müsste.
}}
<pre>
###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/disk/by-id/scsi-SSEAGATE_ST336704LC_3CD27AAG00002206F766-part2 vga=0x317 \
acpi=off   resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.17-0.1-default

###Don't change this comment - YaST2 identifier: Original name: RAID###
title RAID 10.3 - 2.6.22.17-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.17-0.1-default root=/dev/md0 vga=0x317 acpi=off resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.17-0.1-default
</pre>



Zum Schluss muss noch eine neue '''initrd''' mit den Informationen aus mdadm.conf und RAID-Unterstützung erstellt werden. Werden weiter Infos über das System benötigt, werden sie von den Scripten von initrd selbst gesucht.

 automat:/ # mkinitrd -f md -d /dev/md0 

Bei Erfolg sollte am Ende irgend etwas von einer Blockanzahl stehen. Eine Warnung unter 10.3
 WARNING: GRUB::GrubPath2UnixPath: Path /boot/grub/menu.lst in UNIX form, not modifying it
kann erst einmal ignoriert werden, sie kommt scheinbar wieder wegen der bevorzugten DISK-by-ID Einstellung von 10.3 die wir hier nicht strikt befolgt haben.


'''1. Teil fertig.''' wir können rebooten und testen, ob der neu angelegte Menüeintrag in GRUB funktioniert und das RAID1-Rootdevice sauber bootet.
Sollte das nicht funktionieren, so kann man mittels originalem Booteintrag ohne RAID das alte System booten. Wir booten also nach wie vor jetzt noch von der orginalen Platte und aus dem darauf befindlichen /boot-Verzeichnis. Die einzige Änderung, wir binden als Rootdevice unser eben erstelltes halbes Raid1 ein.

-----



Ist das System wieder oben, prüfen wir ob alles entsprechend funktioniert hat.

 automat:~ # mount
 /dev/md0 on / type ext3 (rw,acl,user_xattr)
 proc on /proc type proc (rw)
 sysfs on /sys type sysfs (rw)
 debugfs on /sys/kernel/debug type debugfs (rw)
 udev on /dev type tmpfs (rw)
 devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
 /dev/sda1 on /boot type ext2 (rw,acl,user_xattr)
 /dev/sda3 on /home type ext3 (rw,acl,user_xattr)
 /dev/sda6 on /data type ext2 (ro)
 securityfs on /sys/kernel/security type securityfs (rw)
 
 automat:~ # cat /proc/mdstat
 Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
 md0 : active raid1 sdb2[1]
       5243840 blocks [2/1] [_U]
      
 unused devices: <none>

Das war der schwierige Teil der Arbeit, ab hier wird es einfacher.
Nach gleicher Prozedur werden jetz die restlichen RAID1-Devices angelegt, ohne sda zu verändern. Hier müssen wir jetzt allerdings besonders gut aufpassen, dass wir nichts durcheinander bringen, am besten man schreibt sich vorher auf, welches alte Device auf welchem Mountpoint welche Raid-Nummer bekommen soll. 
  
Wir ändern als nächstes alle anderen Partitions-IDs auf sdb:

 sfdisk --change-id /dev/sdb 1 fd
 sfdisk --change-id /dev/sdb 3 fd
 sfdisk --change-id /dev/sdb 5 fd
 sfdisk --change-id /dev/sdb 6 fd

Als nächstes legen wir die restlichen neuen RAID-Device mit auch jeweils einer fehlenden Komponente an:

 mdadm -C /dev/md1 -b internal -e1.0 -l1 -n2  missing /dev/sdb1
 mdadm -C /dev/md2 -b internal -e1.0 -l1 -n2  missing /dev/sdb5
 mdadm -C /dev/md3 -b internal -e1.0 -l1 -n2  missing /dev/sdb3
 mdadm -C /dev/md4 -b internal -e1.0 -l1 -n2  missing /dev/sdb6
 
 automat:~ # cat /proc/mdstat
 Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
 md4 : active raid1 sdb6[1]
       7461760 blocks [2/1] [_U]
      
 md3 : active raid1 sdb3[1]
       20972480 blocks [2/1] [_U]
      
 md2 : active raid1 sdb5[1]
       2098048 blocks [2/1] [_U]
      
 md1 : active raid1 sdb1[1]
       66432 blocks [2/1] [_U]
      
 md0 : active raid1 sdb2[1]
       5243840 blocks [2/1] [_U]
      
 unused devices: <none>

Danach müssen die neuen RAID-Devices in der <code>mdadm.conf</code> eingetragen werden. Am einfachsten, indem wir diese noch einmal ganz neu erstellen lassen (DEVICE-Zeile vorher wieder einfügen):

 automat:/ # echo "DEVICE /dev/sd[a-z][0-9]" > /etc/mdadm.conf
 automat:/ # mdadm --detail --scan >> /etc/mdadm.conf

jetzt können wir die Filesysteme auf den neuen Devices anlegen und die Daten dorthin kopieren, ''der Zettel hilft hier ;-)''

 mkswap /dev/md2
 mkfs.ext2 /dev/md1
 mkfs.ext3 -j /dev/md3
 mkfs.ext2 /dev/md4
 
 automat:/ # mount /dev/md1 /mnt
 automat:/ # cd /boot
 automat:/boot # find . -mount | cpio -pdumC65536 /mnt
 349 blocks
 automat:/boot # umount /mnt
 automat:/boot # mount /dev/md3 /mnt
 automat:/boot # cd /home
 automat:/home # find . -mount | cpio -pdumC65536 /mnt
 53011 blocks
 automat:/home # umount /mnt
 automat:/home # mount /dev/md4 /mnt
 automat:/home # cd /data
 automat:/data # find . -mount | cpio -pdumC65536 /mnt
 52731 blocks  

Natürlich ist jetzt noch die <code>/etc/fstab</code> anzupassen:

 automat:/data # cat /etc/fstab
 /dev/md0  /      ext3  acl,user_xattr  1 1
 /dev/md2  swap   swap  pri=42          0 0
 /dev/md1  /boot  ext2  acl,user_xattr  1 2
 /dev/md3  /home  ext3  acl,user_xattr  1 2
 /dev/md4  /data  ext2  auto,ro         1 2
 .....

'''2. Teil fertig:''' An dieser Stelle startet man nochmal neu, um auch die restlichen RAID-Devices im System zu verwenden. Wir booten aber nach wie vor noch von der alten Platte und aus dem darauf befindlichem /boot. Nur verwenden wir jetzt alle neue Raiddevices.

---
Ist der Reboot sauber durchgelaufen, prüfen wir nochmals:

 automat:~ # swapon -s
 Filename  Type       Size    Used Priority
 /dev/md2  partition  2098040 0    42
 automat:~ # mount
 /dev/md0 on / type ext3 (rw,acl,user_xattr)
 proc on /proc type proc (rw)
 sysfs on /sys type sysfs (rw)
 debugfs on /sys/kernel/debug type debugfs (rw)
 udev on /dev type tmpfs (rw)
 devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
 /dev/md1 on /boot type ext2 (rw,acl,user_xattr)
 /dev/md3 on /home type ext3 (rw,acl,user_xattr)
 /dev/md4 on /data type ext2 (ro)
 securityfs on /sys/kernel/security type securityfs (rw) 

Das System können wir hier ausgiebig auf saubere Funktion testen; bis jetzt ist das alte System immer noch voll einsatzfähig und wir können immernoch zurück. Wenn alles in Ordnung ist, dann können die fehlenden Spiegelkomponenten nun hinzugefügt werden.

'''Achtung: Ab hier wird das alte System nicht mehr bootfähig.'''

 sfdisk --change-id /dev/sda 1 fd
 sfdisk --change-id /dev/sda 2 fd
 sfdisk --change-id /dev/sda 3 fd
 sfdisk --change-id /dev/sda 5 fd
 sfdisk --change-id /dev/sda 6 fd
 
 mdadm /dev/md4 -a /dev/sda6
 mdadm /dev/md3 -a /dev/sda3
 mdadm /dev/md2 -a /dev/sda5
 mdadm /dev/md1 -a /dev/sda1
 mdadm /dev/md0 -a /dev/sda2

Den Spiegelungsverlauf kann man wie folgt beobachten und verfolgen:

 automat:/proc # cat mdstat
 Personalities : [raid1] [raid0] [raid5] [raid4] [linear]
 md1 : active raid1 sda1[0] sdb1[1]
       66432 blocks [2/2] [UU]
      
 md3 : active raid1 sda3[0] sdb3[1]
       20972480 blocks [2/1] [_U]
       [==>..................]  recovery = 11.4% (2395776/20972480) finish=8.6min speed=35734K/sec
      
 md4 : active raid1 sda6[0] sdb6[1]
       7461760 blocks [2/2] [UU]
      
 md2 : active raid1 sda5[0] sdb5[1]
       2098048 blocks [2/1] [_U]
         resync=DELAYED
      
 md0 : active raid1 sda2[2] sdb2[1]
       5243840 blocks [2/1] [_U]
         resync=DELAYED
      
 unused devices: <none> 

Man wartet ab, bis alle Devices synchronisiert sind. (Ein Neustart ist hier überhaupt nicht empfehlenswert, wenn auch technisch möglich, da nach der Synchro von md1 die GRUB-Daten evtl. nicht mehr passen.) Danach löscht man also den alten, jetzt überflüssigen Menüeintrag. Der neue mit <code>root=/dev/md0</code> wird dupliziert, sodass man von beiden Platten booten kann (man merke: bis der Kernel fertig geladen ist gibt es das Konzept von RAID nicht, d.h. GRUB kann die Platten nur einzeln sehen).

 automat:/boot/grub # vi menu.lst
 # Modified by YaST2. Last modification on Sun Aug 13 16:40:57 CEST 2006
 color white/blue black/light-gray
 default 0
 fallback 1
 timeout 8
 gfxmenu (hd0,0)/message
 
 #--------- RAID----------#
 title SUSE RAID 10.1 1-Platte
     root (hd0,0)
     kernel (hd0,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent  showopts
     initrd (hd0,0)/initrd
 
 #--------- RAID----------#
 title SUSE RAID 10.1 2-Platte
     root (hd1,0)
     kernel (hd1,0)/vmlinuz root=/dev/md0 vga=0x314 acpi=off resume=/dev/md2 splash=silent  showopts
     initrd (hd1,0)/initrd 

Nochmal wird die initrd erstellt, um auch die restlichen RAID-Devices beim Booten zu aktivieren.

 automat:/boot/grub # mkinitrd -f md

Jetzt muss nur noch auf beiden Platten ein neuer MBR geschreiben werden, die jeweils den Stage1 und Stage1.5/Stage2-Loader von GRUB enthalten. Dazu starten wir die GRUB-Shell:

 automat:/boot/grub # grub
 
 grub> root (hd1,0)
  Filesystem type is ext2fs, partition type 0xfd
 
 grub> setup (hd1)
  Checking if "/boot/grub/stage1" exists... yes
  Checking if "/boot/grub/stage2" exists... yes
  Checking if "/boot/grub/e2fs_stage1_5" exists... yes
  Running "embed /boot/grub/e2fs_stage1_5 (hd1)"...  15 sectors are embedded.
 succeeded
  Running "install /boot/grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/boot/grub/stage2
 /boot/grub/menu.lst"... succeeded
 Done.
 
 grub> root (hd0,0)
  Filesystem type is ext2fs, partition type 0xfd
 
 grub> setup (hd0)
  Checking if "/boot/grub/stage1" exists... yes
  Checking if "/boot/grub/stage2" exists... yes
  Checking if "/boot/grub/e2fs_stage1_5" exists... yes
  Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
 succeeded
  Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2
 /boot/grub/menu.lst"... succeeded
 Done. 

Ein kleiner Zusatz noch, damit wir auch eine Mail bekommen, wenn eine Komponente in den RAID-Arrays auf fehlerhaft ("''faulty''") geht: an das Ende der <code>mdadm.conf</code> fügen wir unsere Mailaddresse ein und starten in YaST den ''mdadmd''-Dienst.

 echo "MAILADDR root@localhost" >> /etc/mdadm.conf

'''Fertig:''' Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen.
Dann kann das RAID-System ausgiebig getest werden.


robi




[[Category:Partitionen]]