SUSE 11 - Yast killt RAID1 ?

Anfangs glaubte ich noch an einen Hardwaredefekt, nach dem dritten Rechner nun aber nicht mehr.... kurze Erklärung:

Ich hab hier drei unterschiedliche Server die seit laaaanger Zeit perfekt mit SuSE 9.x und 10.x liefen. Das Basis-Setup sieht jeweils so aus (SATA Platten):

/dev/sda1 -> SWAP
/dev/sda2 -> RAID
/dev/sda3 -> RAID
/dev/sdb1 -> SWAP
/dev/sdb2 -> RAID
/dev/sdb3 -> RAID
/dev/md0 -> sda2/sdb2 (RAID 1)
/dev/md1 -> sda3/sdb3 (RAID 1)

Setup mit Minimalinstallation durchgeführt - System startet wie gewohnt, wie es sein soll. Danach macht man mittels Yast ein Online-update und will neu starten.... Pustkuchen:

zwischen "Grub Error 2", "Invalid Partitiontable" und "No Operating System" alles schon gesehen. Ok, GRUB mittels Rescue-System jeweils neu afgebracht und erneuter Versuch.... Pustekuchen die 2te:

/dev/md0 kann nicht gemountet werden - auch nicht manuell. Das Filesystem wird nicht erkannt, fsck.ext3 weigert sich ebenfalls.

Der langen Rede kurzer Sinn: Das Array ist irgendwie zerschossen worden.

Lösung:
md0 stoppen, neu mit nur sda2 bauen, Daten sichern (alles fehlerfrei, obwohl fsck meckert, dass entweder SUperblock oder Partitiontable im A...h wären)....
md0 eliminieren und von Hand neu bauen, Daten zurückspielen...

So long.... nur was zum Geier macht denn der Yast bei seinen Updates hier bitte falsch? Wie gesagt.... auf 3 Systemen reproduzierbar... unterschiedliche Hardware, selbes "Minimalsetup", und definitiv KEIN Hardwaredefekt. Lief vorher und rennt jetzt mit "von Hand gebautem" RAID1...

Any ideas?

fstab?
menu.lst?
device.map?

CHL schrieb:

So long.... nur was zum Geier macht denn der Yast bei seinen Updates hier bitte falsch? Wie gesagt.... auf 3 Systemen reproduzierbar... unterschiedliche Hardware, selbes "Minimalsetup", und definitiv KEIN Hardwaredefekt. Lief vorher und rennt jetzt mit "von Hand gebautem" RAID1...

Any ideas?

Zum Vergrößern anklicken....

schau mal hier http://wiki.linux-club.de/opensuse/SuSE_und_Grub#YaST_und_sein_Verst.C3.A4ndnis_von_GRUB

robi

nein... leider nicht hilfreich. mit dem GRUB ist alles in Ordnung.... fstab, menu.lst, etc. sind hier ebenfalls fehl am Platz, da dies nichts mit dem Problem zu tun hat - leider.

Ich hab hier gerade alles nochmal reproduziert und zeig Euch was im Rescue passiert:
---
Rescue:~ # cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb3[0] sda3[1]
214965628 blocks super 1.0 [2/2] [UU]
bitmap: 0/411 pages [0KB], 256KB chunk

md0 : inactive sda2[1]
16779820 blocks super 1.0
---
Rescue:~ # mount /dev/md0 /mnt/
mount: you must specify the filesystem type
Rescue:~ # mount /dev/sda2 /mnt/
mount: unknown filesystem type 'linux_raid_member'
Rescue:~ # mount -t ext3 /dev/sda2 /mnt/
mount: /dev/sda2 already mounted or /mnt/ busy
Rescue:~ # mount -t ext3 /dev/sdb2 /mnt/
Rescue:~ # dir /mnt/
total 4498772
drwxr-xr-x 2 root root 4096 Sep 23 10:22 bin
drwxr-xr-x 3 root root 4096 Sep 23 11:59 boot
drwxr-xr-x 5 root root 4096 Sep 23 10:19 dev
drwxr-xr-x 74 root root 4096 Sep 23 12:31 etc
drwxr-xr-x 3 root root 4096 Sep 23 10:25 home
drwxr-xr-x 13 root root 4096 Sep 23 12:21 lib
drwx------ 2 root root 16384 Sep 23 10:17 lost+found
drwxr-xr-x 2 root root 4096 Jun 6 20:23 media
drwxr-xr-x 2 root root 4096 Jun 6 20:23 mnt
drwxr-xr-x 3 root root 4096 Jun 10 12:35 opt
drwxr-xr-x 3 root root 4096 Sep 23 10:19 proc
drwx------ 7 root root 4096 Sep 23 12:29 root
drwxr-xr-x 3 root root 12288 Sep 23 12:02 sbin
drwxr-xr-x 4 root root 4096 Jun 10 12:09 srv
-rw-r--r-- 1 root root 0 Sep 23 12:31 success
-rw-r--r-- 1 root root 4602134528 Sep 23 11:46 suse11.iso
drwxr-xr-x 3 root root 4096 Sep 23 10:19 sys
drwxrwxrwt 4 root root 4096 Sep 23 12:31 tmp
drwxr-xr-x 12 root root 4096 Jun 10 12:36 usr
drwxr-xr-x 14 root root 4096 Jun 10 12:35 var
drwxr-xr-x 2 root root 4096 Sep 23 10:19 vmware
Rescue:~ #
---
somit alles auf der zweiten platte vorhanden und lesbar.

jetzt bau ich das raid von hand auf und voilla... nur WAS hat yast hier veranstaltet? bei dem anderne rechner heute hat fsck noch gemeldet, dass entweder superblock oder partitiontable defekt sein, da es abweichungen bei den fileystemgrößen gab.

CHLs Aussage grob: "SL 11.0 kann alte mdx-Raids im Raid-Level 1 nicht richtig verarbeiten" kann ich bestätigen.

Bei Raid 1 kannst du aber auch eine bekannte Partition des Arrays als z.B. ext3 read-only mounten (falls das Raid1 ext3 war) und die Daten sichern, und danach das Array neu aufbauen. - sei es nun mit YAST oder von Hand. - oder habe ich Deine Ausführungen nicht richtig verstanden und Du hast das so ähnlich gemacht?

Wer einen guten Bugreport schreiben kann und ein ähnliches Problem hat soll dies tun, ich selbst traue es mir nicht zu (mangels kaputtem Raid).

danke - einfacher und besser hätte ich es nicht sagen können. ich werde, sofern ich zeit finde, das ganze heute nochmal rekonstruieren und versuchen der Sache Schritt für Schritt auf die Spur zu kommen.

Was mir aufgefallen ist: Das Problem tritt anscheinend nur auf, wenn man eine bestehende Partitionierung beibehält und lediglich neu formatiert. Wenn man das Setup mit einer völlig jungfräulichen Platte macht klappt alles wie gewohnt. Aber so wirklich schlau bin ich immer noch nicht geworden...