NonRaid zu (software)Raid1 SuSE 10 1: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
(Language cleanup (6/*): Der große Reboot ist immer die Rootpartition)
(Language cleanup (7/*))
Zeile 83: Zeile 83:
 
<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.
 
<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.
 
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 bootbar.
+
sda wird vorläufig nicht verändert, somit bleibt das alte LINUX nach wie vor noch erhalten und weiter bootfähig.
 
Wir erstellen ein RAID-1-Device mit einer fehlenden Komponente mit sdb2 als einziger aktive Komponente.
 
Wir erstellen ein RAID-1-Device mit einer fehlenden Komponente mit sdb2 als einziger aktive Komponente.
 
Zunächst wird die Partitions-ID von sdb2 geändert:
 
Zunächst wird die Partitions-ID von sdb2 geändert:
Zeile 311: Zeile 311:
 
  securityfs on /sys/kernel/security type securityfs (rw)  
 
  securityfs on /sys/kernel/security type securityfs (rw)  
  
soweit ok? Das System können wir hier ausgiebig auf saubere Funktion prüfen, bis jetzt ist das alte System noch voll einsatzfähig, und wir können immernoch zurück. Wenn ok<br>
+
Das System können wir hier ausgiebig auf saubere Funktion testen; bis jetzt ist das alte System 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.
Dann können wir die fehlenden Spiegelslices jetzt dazufügen.<br><br>
+
 
'''Achtung: Ab hier ist wird das alte System nicht mehr bootbar.'''
+
'''Achtung: Ab hier wird das alte System nicht mehr bootfähig.'''
  
 
  sfdisk --change-id /dev/sda 1 fd
 
  sfdisk --change-id /dev/sda 1 fd
Zeile 327: Zeile 327:
 
  mdadm /dev/md0 -a /dev/sda2
 
  mdadm /dev/md0 -a /dev/sda2
  
beobachten und verfolgen können wir das mit
+
Den Spiegelungsverlauf kann man wie folgt beobachten und verfolgen:
  
 
  automat:/proc # cat mdstat
 
  automat:/proc # cat mdstat
Zeile 351: Zeile 351:
 
  unused devices: <none>  
 
  unused devices: <none>  
  
Wir warten am besten bis alle Devices sauber online sind.<br>
+
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).
Dann kommen wir zur neu Konfiguration des Grub.<br>
 
Wir löschen jetzt den alten, jetzt überflüssigen Menüeintrag und ändern unseren ersten Eintrag von vorhin und legen noch einen zweiten an. Auch einen fallback-Eintrag legen wir an. Es sollten jetzt für jede Platte ein Menüeintrag vorhanden sein
 
  
 
  automat:/boot/grub # vi menu.lst
 
  automat:/boot/grub # vi menu.lst
Zeile 375: Zeile 373:
 
     initrd (hd1,0)/initrd  
 
     initrd (hd1,0)/initrd  
  
Als nächstes erzeugen wir noch einmal ein neues initrd, damit jetzt auch die restlichen Raiddevices beim booten erkannt werden können.
+
Nochmal wird die initrd erstellt, um auch die restlichen RAID-Devices beim Booten zu aktivieren.
  
 
  automat:/boot/grub # mkinitrd -f md
 
  automat:/boot/grub # mkinitrd -f md

Version vom 10. Februar 2007, 17:30 Uhr

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.


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 fstab und GRUBs menu.lst. 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 (/home, /data), auch /boot 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. fdisk -l 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. Wir erstellen ein RAID-1-Device mit einer fehlenden Komponente mit sdb2 als einziger aktive Komponente. Zunächst wird die Partitions-ID von sdb2 geändert:

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

Eventuell tauchen unter KDE wieder Fenster auf, die mit Abbruch zu schließen sind. Ein Blick auf fdisk -l zeigt nun, dass bei sdb2 wirklich fd als ID eingetragen ist. Danach wird das RAID-Array mit 2 Komponenten erstellt, wovon eine als fehlend markiert wird:

automat:/ # mdadm -C /dev/md0 -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:/proc # mkfs.ext3 -j /dev/md0
...
...
automat:/proc # mount /dev/md0 /mnt
automat:/proc # cd /
automat:/ # find . -mount | cpio  -pdumC65536 /mnt
64239 blocks 

Alternativ zu find/cpio kann auch rsync verwendet werden. Vorteile sind eine Statusanzeige, dass man es abbrechen und problemlos neu starten kann, und dass mit den Optionen -A (vor SUSE Linux 10.1 nicht vorhanden) und -X (vor openSUSE 10.2 nicht vorhanden) ACLs bzw. xattrs mit übertragen kann.

# rsync -APHSXavx / /mnt/

Der abschließende Slash ist für den gewünschten Effekt erforderlich. 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) 

Das Filesystem wird dann wieder ausgehangen und /boot/grub/menu.lst 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 

Zum Schluss muss noch eine neue initrd mit den Informationen aus mdadm.conf und RAID-Unterstützung erstellt werden. Werden weiter Infos benötigt, werden sie von dort gelesen.

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

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.

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 die restlichen RAID1-Devices angelegt, ohne sda zu verändern. 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 -e1.0 -l1 -n2  missing /dev/sdb1
mdadm -C /dev/md2 -e1.0 -l1 -n2  missing /dev/sdb5
mdadm -C /dev/md3 -e1.0 -l1 -n2  missing /dev/sdb3
mdadm -C /dev/md4 -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 mdadm.conf eingetragen werden. Am einfachsten, indem wir diese 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

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 /etc/fstab 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. Ist der Reboot geschafft, 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 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 root=/dev/md0 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 müssen wir nur noch auf beide Platten einen neuen MBR schreiben, der die Grub Dateien auf den jeweiligen Devices findet. 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. 

noch ein kleiner Zusatz damit wir auch eine Mail bekommen, wenn einem unserer Raids irgenwas böses widerfährt.
Wir schreiben an das Ende der mdadm.conf unsere Mailaddresse und starten im Yast den mdadmd Dienst.

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

Fertig: Ein Reboot sollte jetzt von beiden Platten sauber durchlaufen. Dann kann das Raidsystem ausgiebig getest werden.


robi