Hilfe - ständiger Systemcrash - Festplattenfehler?
Liebe ListenleserInnen, jetzt wende ich ich - nachdem ich in den letzten Tagen schon Hilfe bekommen habe, nochmal an Euch. Nachdem ich nun mehrfach mein System neu installiert habe, bin ich mit meinem Latein am Ende, wo der Fehler liegen könnte. Nach jeder Installation und viel Schreib- und Lesezugriffen auf die Platte (Rückspielen von Backups) verabschiedete sich mein System bisher auf Nimmerwiedersehen. (IBM-Drivefittness meldet aber keine Fehler). (System: Suse 8.0) Symptomatik ist folgende: Installation verläuft problemlos. Beim Kopieren von Daten oder einfach unmotiviert hängt sich der Rechner auf und nach einem Reboot sind ein oder mehrere Dateisysteme beschädigt - meist so, daß sie durch ein e2fsck nicht wiederhergestellt werden konnten (einmal habe ich es auch mit Reiserfs versucht -gleiches Ergebnis) Das gleiche System - Suse 8.0 in der selben Konfiguration lief jetzt einige Wochen problemlos (vom IDE-Kernelbug abgesehen, den ich aber diesmal ausschließen kann - hatte zweite Platte nicht gemountet). (Davor lief 7.1 1 1/2 Jahre wunderbar). Beim letzten Crash folgendes: Beim Erstellen eines Verzeichnisses (mit dem mc) die Fehlermeldung "segmentation fault". Danach reagiert kein xterm mehr. (Programme unter x lassen sich noch beenden, der Windowmanager auch - aber dann schwarzer Bildschirm, auch kein Zugriff auf eine Textkonsole mehr). Reboot: Fehler beim Start: "fsck.ext3 /dev/hdb9 failed (status 0x8) Run manually" Und nur noch single-user-Mode # e2fsck /dev/hdb9 # can't find external journal (hdb9 - datenpartition, fürs System nicht wichtig - aus fstab (mittels rescue-system) gelöscht, reboot) jetzt bleibt er beim Booten hängen letzte Meldungen: "EXT3-fs error (device ide0(3,77): ext3_free.blocks Freeing blocks not in datazone - block=2147666600233, count 6" und noch ähnliche Meldungen... "Assertion failure in journal_revoke() at revoke.c:330: ....." und so weiter "invalid operand 000 CPU 0 EIP: 0010:[<c1994f25>] Not tainted EFLAGS: 00010286 eax: 00000c4 ebx:" und so weiter - keine Ahnung, ob jemand mit den Meldungen was anfangen kann... letzte Zeile: "etc/init.d/boot.d/S09boot.ldconfig: line 81: 128 segmentation fault /sbin/ldconfig -x 2 > /dev/null" mit rescue System Platten gecheckt: hdb5 hat Fehler, die sich nicht fixen lassen. bei hdb9 findet e2fsck journal gar nicht. Ich tippte ja schon am Anfang auf eine defekte Festplatte, aber so richtige Fehler habe ich bisher nicht gefunden. (Außer drei badblocks, die aber nach Aufspielen eines neuen Filesystems nicht mehr da waren.) Habe zwischenzeitlich zweimal die Platte komplett neuparittioniert. Das letzte Mal auf Anraten eines Händlers vorher lowlevel (schreibt nullen auf die Platte) geplättet. Kein Effekt. IBM-Drive-Fittness meldet eine integre Platte. Hat jemand eine Idee, woran es noch liegen kann? Wirklich kaputte Platte oder evtl. Softwareproblem (was mich wundern würde, da das gleiche System ja schonmal darauf lief...). Welche Hardware könnte sonst noch verantwortlich sein? Festplattencontroller? Wie checkt man das? Speicher ist laut memtest ok. Windows auf einer anderen Platte funktioniert übrigens (so (in)stabil wie sonst auch.). (Da ich die zweite Platte für eine Backuppartition verwende, kann ich nicht probehalber Linux auf die erste Platte spielen.) Danke schon mal für Eure Ideen. grüße carsten
Am Dienstag, 3. Dezember 2002 03:54 schrieb Carsten Ungewitter:
(Da ich die zweite Platte für eine Backuppartition verwende, kann ich nicht probehalber Linux auf die erste Platte spielen.)
Du hast mehr als eine IDE-Platte im Rechner? Die Kernel von SuSE 8.0 und 8.1 haben bekanntermassen Probleme mit mehr als eineer IDE-Platte. Mit nem Kernelupdate aus Mantels Verzeichnis sollte das Problem beheben. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de
At 16:23 03.12.02, you wrote:
Am Dienstag, 3. Dezember 2002 03:54 schrieb Carsten Ungewitter:
(Da ich die zweite Platte für eine Backuppartition verwende, kann ich nicht probehalber Linux auf die erste Platte spielen.)
Du hast mehr als eine IDE-Platte im Rechner? Die Kernel von SuSE 8.0 und 8.1 haben bekanntermassen Probleme mit mehr als eineer IDE-Platte. Mit nem Kernelupdate aus Mantels Verzeichnis sollte das Problem beheben.
Hallo Manfred, Das ist ja richtig, daß ich das Problem auch schon mal hatte... ;-) und das auch mit dem genannten Kernel gelöst habe, aber diesmal liegt es meines Wissens (sicher ??) nicht daran. Ich hatte die zweite Platte ja gar nicht gemountet. (wie ich in der Mail übrigens geschrieben habe...) Oder kann das Problem auch bei ungemounteter Platte auftreten? Das System lief aber wie gesagt bereits einige Wochen stabil - auch mit dem alten Kernel bei ungemounteter Platte - bis ich den Mantel-Kernel verwendet habe. So weit bin ich diesmal noch gar nicht gekommen, das Kernelupdate nach der Installation einzuspielen. Oder meinst Du ich sollte es mal bei ausgehängter Platte versuchen?? grüße carsten
Am Dienstag, 3. Dezember 2002 17:25 schrieb Carsten Ungewitter:
Das ist ja richtig, daß ich das Problem auch schon mal hatte... ;-) und das auch mit dem genannten Kernel gelöst habe, aber diesmal liegt es meines Wissens (sicher ??) nicht daran. Ich hatte die zweite Platte ja gar nicht gemountet. (wie ich in der Mail übrigens geschrieben habe...)
Naja, so kleine Details überliest man schnell in ner langen Mail.
Oder kann das Problem auch bei ungemounteter Platte auftreten? Das System lief aber wie gesagt bereits einige Wochen stabil - auch mit dem alten Kernel bei ungemounteter Platte - bis ich den Mantel-Kernel verwendet habe.
Ich muß sagen, mir fehlen die praktischen Erfahrungen. Als langjähriger ausschliesslich SCSI-User hab ich zwar mittlerweile auch eine IDE-Platte im Rechner (wegen der Lautstärke, SCSI-Platten sind mittlerweile ja lauter Servertriebwerke...). Aber eben nur eine.
So weit bin ich diesmal noch gar nicht gekommen, das Kernelupdate nach der Installation einzuspielen.
Oder meinst Du ich sollte es mal bei ausgehängter Platte versuchen??
Probiers mal, sollte nichts dabei verloren sein. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de
Hallo, On Tue, 03 Dec 2002, Carsten Ungewitter wrote:
"invalid operand 000 CPU 0 EIP: 0010:[<c1994f25>] Not tainted EFLAGS: 00010286 eax: 00000c4 ebx:"
Jag mal den kompletten Oops durch ksymoops. Was verwendest du als fs? ext2 oder ext3? Welche e2fsprogs? Welche glibc? Ansonsten: Die vielen Segfaults deuten evtl. auf ein Speicherproblem hin.. Achso: Schonmal den Rechner aufgehabt seitdem? Sitzen die Kabel? Sind irgendwelche Bauteile durchgeschmort? -dnh -- Linux is not a desktop OS for people whose VCRs are still flashing "12:00". -- Paul Tomblin
Am Mittwoch, 4. Dezember 2002 21:32 schrieb David Haller:
Hallo,
Hallo, und dank Dir David, ich hab's gelöst, wenn man das so nennen kann. Die Platte war wirklich kaputt. NAchdem ich Manfreds Tipp gefolgt bin (Danke!) und sie zum Testen eines Controller-Defekts an die verschiedenen Controller mal als Master, mal als Slave gehängt hatte, stellte sich raus, daß sie vom Bios nur als Slave und nicht als Master erkannt wurde. An anderen Rechnern reproduzierbar. Seltsames Phänomen. Aber deutet wirklich auf eine kaputte Platte hin. Was schon länger war: die HD-LED leuchtete ständig. Dem maß ich aber - irrtümlicherweise - wenig Bedeutung bei. Neue Platte eingebaut: jetzt läuft wieder alles.
On Tue, 03 Dec 2002, Carsten Ungewitter wrote:
"invalid operand 000 CPU 0 EIP: 0010:[<c1994f25>] Not tainted EFLAGS: 00010286 eax: 00000c4 ebx:"
Jag mal den kompletten Oops durch ksymoops.
Nur so aus Interesse: was bedeutet das? Was ist ksymoops?
Was verwendest du als fs? ext2 oder ext3? Welche e2fsprogs? Welche
ich hatte zuletzt ext3 versucht.
glibc?
2.2.5 grüße carsten
Hi Carsten, *Carsten Ungewitter schrieb:
Am Mittwoch, 4. Dezember 2002 21:32 schrieb David Haller:
Slave gehängt hatte, stellte sich raus, daß sie vom Bios nur als Slave und nicht als Master erkannt wurde. An anderen Rechnern reproduzierbar.
Seltsames Phänomen. Aber deutet wirklich auf eine kaputte Platte hin. Was schon länger war: die HD-LED leuchtete ständig. Dem maß ich aber - irrtümlicherweise - wenig Bedeutung bei.
Frage nur zur Sicherheit: Du hast die Festplatte aber schon als Master gejumpert, nicht Slave und nicht CableSelect??? CU Ede
Am Donnerstag, 5. Dezember 2002 10:56 schrieb Edgar Kuchelmeister:
Hi Carsten,
*Carsten Ungewitter schrieb:
Am Mittwoch, 4. Dezember 2002 21:32 schrieb David Haller:
Slave gehängt hatte, stellte sich raus, daß sie vom Bios nur als Slave und nicht als Master erkannt wurde. An anderen Rechnern reproduzierbar.
Seltsames Phänomen. Aber deutet wirklich auf eine kaputte Platte hin. Was schon länger war: die HD-LED leuchtete ständig. Dem maß ich aber - irrtümlicherweise - wenig Bedeutung bei.
Frage nur zur Sicherheit: Du hast die Festplatte aber schon als Master gejumpert, nicht Slave und nicht CableSelect???
jaja, alles durchprobiert. auch beim Händler gewesen. gleiches Phänomen. lustigerweise wird sie als Master erkannt, wenn noch ein Slave dran ist, aber nicht als einziges Laufwerk. Sachen gibts... grüße carsten
Hallo, On Thu, 05 Dec 2002, Carsten Ungewitter wrote:
Am Mittwoch, 4. Dezember 2002 21:32 schrieb David Haller: ich hab's gelöst, wenn man das so nennen kann. Die Platte war wirklich kaputt.
Also HW-Schaden. Haette mich auch gewundert wenn nicht ;) Wenn du so "unmotiviert" mit Oopses und Segfaults von allerlei "Basis"-Programmen zugekleistert wirst ist's eigentlich immer die HW, die sich verabschiedet (hat)...
NAchdem ich Manfreds Tipp gefolgt bin (Danke!) und sie zum Testen eines Controller-Defekts an die verschiedenen Controller mal als Master, mal als Slave gehängt hatte, stellte sich raus, daß sie vom Bios nur als Slave und nicht als Master erkannt wurde. An anderen Rechnern reproduzierbar.
Seltsames Phänomen. Aber deutet wirklich auf eine kaputte Platte hin. Was schon länger war: die HD-LED leuchtete ständig. Dem maß ich aber - irrtümlicherweise - wenig Bedeutung bei.
Hm. Mein Tipp: Die Elektronik der HD hat sich (teilweise) verabschiedet. Zumal du ja per fsck/badblocks/Drive Fitness Test ja keine Defekte auf dem Medium selbst gefunden hast...
Neue Platte eingebaut: jetzt läuft wieder alles.
Glueckwunsch. Moege sie laenger halten und zuverlaessig sein :)
On Tue, 03 Dec 2002, Carsten Ungewitter wrote:
"invalid operand 000 CPU 0 EIP: 0010:[<c1994f25>] Not tainted EFLAGS: 00010286 eax: 00000c4 ebx:"
Jag mal den kompletten Oops durch ksymoops.
Nur so aus Interesse: was bedeutet das? Was ist ksymoops?
Also, ein "Kernel-Oops" ist das, was der Kernel bei einem "panic" ausspuckt. Ein "panic" wird ausgeloest, wenn du a) ihn absichtlich und per Hand mittels echo 1 >/proc/sys/kernel/panic herbeifuehrst ;) oder b) ein "gravierender" Fehler im Kernelcode auftritt, beliebt ist z.B. der "Oops", wenn das root-fs nicht gemountet werden kann weil der Support dafuer als Modul kompiliert wurde und nicht in die initrd eingebaut wurde *eg* AFAIR gibt's ebenfalls einen "Oops", wenn der kernel eine Null-pointer dereferenzieren soll, je nach "Quelle" laeuft der kernel aber weiter. So. Das, was der Kernel also als "Oops" ausspuckt ist "kryptisch", da es ein mehr oder weniger "roher" Dump ist. Wenn's ein Anwendung ist, die den Oops ausloest bekommst du i.d.R. noch lesbar den Namen und die Pid des Prozesses im Oops, falls der Kernel selber stolpert aber naturgemaess nicht. Jagt man den "Oops-Code" nun durch ksymoops, so werden die (binaeren) Daten darin uebersetzt, so dass z.B. Adressen durch die Namen von Funktionen ersetzt werden, was es wesentlich leichter macht, das Problem zu diagnostizieren. Aus man 8 ksymoops: ==== DESCRIPTION ksymoops extracts kernel Oops reports from the Oops.file and uses various sources of symbol information to convert the addresses and code to meaningful text. ==== Siehe auch /usr/src/linux/Documentation/oops-tracing.txt. Kurz: einen "Oops" sollte man nicht "roh", sondern nach der "Behandlung" mit ksymoops mailen. Hier und ganz besonders auf der lkml. Siehe o.g. Quellen wie und warum. -dnh -- It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. -- Edsger Wybe Dijkstra
participants (4)
-
Carsten Ungewitter -
David Haller -
Gamundia.Dentalprodukte＠t-online.de -
Manfred Tremmel