Hallo Liste, nach langer Abwesenheit ( Umzugsstress, Rechnerprobleme, enorme Emailprobleme, ich fuerchte diese Liste hat einige Mailbox quota überschritten emails abbekommen, sorry dafuer, ich hatte wirklich dies erklärende ( wenn auch nicht entschuldigende ) (nicht nur techiche) Probleme ) ist mir gestern/heute etwas saudummes was meine sofortige Rückkehr erzwungen hat passiert. Ich wollte gestern auf meinem "server" Rechner Kernel 2.4.16 ( vorher 2.2.14 ) installieren, weil ich freeswan auf 2.2.14 nicht zum laufen bekomme. Das besondere an dem Rechner ist dass er auf Software Raid basis läuft, d.h. das / auf einem raid 5 aus 3 SCSI platten , und /boot auf einem raid 1 aus 2 dieser PLatten liegt. Leider hat der 2.4.16 enorme Probleme mit meinem Dawiecontroll SCSI controller, und so stürzt das gesamte System immer nach 1 minute ab. Normalerweise habe ich dann immer den alten Kernel gebootet, kräftig filesstemgecheckt, passt wider. Leider habe ich heute morgen schlaftrunken den Rechner angemacht, vergessen dass der default kernel 2.4.16 ist, den rechner stehen lassen, 10 minuten später gemerkt da geht was nicht, rechner reagiert nicht, ausgeschaltet, alten Kernel gebootet. KERNEL PANIC. Er läd zwar den kernel noch, erkennt auch die metadisks /dev/md1 (boot) dann sagt er aber /dev/md1 not clean , reconstructing - and so on _ einige meldungen wegelassen :_ EXT2 unable to read superblock isofs_read_super - bread failed KERNEL PANIC VFS unable too mount root fs. Meine Frage. Wie soll ich jetzt vorgehen? Das System hatte wie gesagt Kernel 2.2.14, allerdings mit den raidtools patchen, es verwedete die neueren raidtools, nicht die die im 2.2.13 SUSE Kernel schon mit drin sind. Ich kann mit meinem SUSE 6.3 CD´s booten, der SCSI controller laesst sich auch laden, ich komme also an die disks dran. Dann wird es aber schon schwierig. Ich muesste ja praktisch die beiden metadisks von extern wieder aufsetzen und dann fschk drüberlaufen lassen. Die Frage ist blos wie. Der Rettungssystemkernel von 6.3 kann mit metadisks nichts anfangen. Haben die neueren SUSE retteungsystemkernels die raidsachen schon mit drin? Kernel 2.4.16 hatte das ja, da musste ich nicht nachpatchen, konnte einfach mit einem entsprechend kompilierten kernel booten. Vielleicht erkennt ja ein Susekernel meinen SCSI Controller, dann muesste ich blos noch die metadisks wieder aufsetzten? Der Rechner läuft schon über ein Jahr, und ich muss gestehen dass mir die raid sachen ein bischen aus dem Kopf geflogen sind. Ich habe natuerlich keine /etc/metadisk.conf ( oder wie das teil heisst ) mehr, die Partitionierung von den platten war aber simpel, auf den ersten beiden Platten 3 Partitionen 1 mal fuer boot, dann swap, rest fuer / . Auf der dritten nur 2 Partitionen, swap und / . ( /boot ( md1) war ja ein raid 1 ) die Partitionen sind aber auf allen Platten an den selben cylindergrenzen. Kann ich eine metadisk aufsetzen ohne sie gleich zu beschreiben, sonst wären die Daten ja gleich im Eimer ( so eine Art read only konfiguration ). Wie bekomme ich ein System gebootet, was mit metadisks etwas anfangen kann? Glaubt iHr das geht mit einer SUSE CD, wenn nein, was dann? Was muss ich sonst noch beachten? Ich bin sicher dass ich noch einen Möglichkeit vergessen habe. vielen Dank für jegliche Hilfe im vorraus mit freundlicher gruessen timo proescholdt -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Hallo Liste, leider hat sich keiner von Euch meiner erbarmt, ( softraid bootet nicht mehr ) ich habe mich natuerlich parallel selbst auf den Hosenboden gesetzt und habe mein Problem hoffentlich ( das raid syncronisiert gerade ) geloest. Das dachte ich zu dem Zeitpunkt noch, und wollte gerade ein Summary meiner Erfahrungen an die Liste posten ( vielleicht hat ja jemand was davon , dachte ich mir ). Ich habe es zwar geschafft das raid wieder "aufzusetzen", leider kann ich das filesystem darauf nicht mehr mounten. Was ich gemacht habe ist von CD ( suse 7.3 ) gebootet, eine neue /etc/raidtab ( aus dem kopf meine alte ) geschrieben, mkraid --really-force /dev/md0 das raid neu aufgesetzt, dieser Vorgang erzeugt kein neues Filesystem auf der metadisk, sondern schreibt nur die raidsuperblocks neu, das hat auch soweit geklappt. Nachdem das raid neu syncronisiert hat, habe ich versucht das filesystem zu mounten. Das haut leider gar nicht hin. Ich bekomme folgende Fehlermeldung.
mount -t ext2 /dev/md0 /mnt/test2 [ -o ro ]
wrong filesystem, bad option , bad superblock /dev/md0 und im errorlog auf der fehlerkonsole EXT2-fs: fragsize 268435456 != blocksize 4096 ( not supported yet ) raid5: switching cache buffer size, 4096 -> 1024
e2fsck /dev/md0
filesystem has unsupported read-only features while trying to open /dev/md0, The superblock could not be read or does not describe a correct ext2 filesystem .... weiter mit standart fehlermeldung von e2fsck ( falls wirklich ein ext2 filesystem auf dem device ist, dann bitte mit -b xxxx einen alternativen Superblock angeben) ... ein dumpe2fs gibt mir aber
dumpe2fs /dev/md0
Filesystem volume name: <none> Last mounted on: Þ/t7mOÞ9Þ/t7 Filesystem UUID: adfdb2e1-f5c4-4ad3-9780-d753e90a4502 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: filetype sparse_super large_file btree_dir FEATURE_R4 FEATURE_R8 FEATURE_R9 FEATURE_R10 FEATURE_R12 FEATURE_R13 FEATURE_R14 FEATURE_R16 FEATURE_R18 FEATURE_R20 FEATURE_R21 FEATURE_R25 FEATURE_R26 FEATURE_R27 FEATURE_R28 FEATURE_R29 Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1005988 Block count: 2080502 Reserved block count: 931765662 Free blocks: 970210951 Free inodes: 931437248 First block: 0 Block size: 4096 Fragment size: 268435456 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 15752 Inode blocks per group: 493 Last mount time: Mon Dec 17 01:28:49 2001 Last write time: Mon Dec 17 01:22:00 2001 Mount count: 1 Maximum mount count: 20 Last checked: Sun Dec 16 20:45:56 2001 Check interval: 15552000 (6 months) Next check after: Fri Jun 14 20:45:56 2002 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 ext2fs_read_bb_inodeA Attempt to read block from filesystem resulted in short read Am ende zwar eine Fehlermeldung, aber immerhin kann ich sehen dass der resync die Daten darauf nicht komplett zerstoert hat, da ich z.B.: sehe wann das Filesystem zuletzt gecheckt wurde Last checked: Sun Dec 16 20:45:56 2001 das war noch vor dem Crash. Das heisst fuer mich dass meine Daten noch mehr oder weniger auf den Platten drauf sein muessten. Blos wie komme ich wieder dran? ext2 legt doch Kopien des Superblocks alle ?? Sektoren/Blocks an. Wenn ich wuesste wo das ist, koennte ich das als Argument fuer e2fsck verwenden. Ich muss gestehen dass ich hier nicht mehr weiterkomme. Vielleicht kann mir ja wenigstens jemand sagen ob meine Annahme das die Daten noch auf der metadisk draufseien koennten richtig oder falsch ist. Woher nimmt dumpe2fs seine infos? Nur aus den ersten Sektoren, oder ist die Tatsache dass ich obigen Output bekomme gleichbedeutend damit das wirklich ein filesystem auf dem device existiert? Kann mir jemand mehr zu den Fehlermeldungen ext2fs_read_bb_inodeA Attempt to read block from filesystem resulted in short read EXT2-fs: fragsize 268435456 != blocksize 4096 ( not supported yet ) sagen? Super wäre natürlich ein Tipp, wie das Device ( falls noch möglich ) wieder zu mounten ist. vielen herzlichen Dank fuer jede Hilfe, timo proescholdt -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
participants (1)
-
timo proescholdt