INIT:PANIC segmentation violation mit 2.4er Kernel

wum · Beitrag von **wum** » 12.01.2005 15:07:41

Ich habe sarge (bzw. upgegradete knoppix-installation) auf meinem Rechner. Seit heute fährt er plötzlich nicht mehr hoch sondern unterbricht mit der Fehlermeldung:

INIT:PANIC segmentation violation at 0x804ec92! sleeping for 30 sconds

Diese Meldung wiederholt er immer wieder und nichts passiert.
Ich habe einen 2.4er Kernel, an dem ich aber nicht rumgeschraubt habe. Hier im Forum habe zu dieser Fehlermeldung nur threads gefunden, wo Leute versucht haben auf den 2.6-er Kernel upzudaten. Habe ich aber nicht. Und leider sind in diesen threads auch keine Problemlösungen angegeben (siehe http://www.debianforum.de/forum/viewtop ... +violation und http://www.debianforum.de/forum/viewtop ... +violation).
Bin ratlos.
Kann mir jemand sagen, wie ich das Problem eingrenzen kann?

pdreker · Beitrag von **pdreker** » 12.01.2005 15:11:11

Hast Du den Speicher 'mal mit memcheck86 ueberprueft?

Patrick

wum · Beitrag von **wum** » 12.01.2005 15:16:26

nein, habe ich nicht,
wie geht denn das? gibts denn eine möglichkeit den bootprozess zu unterbrechen und noch vor den inits ein programm auszuführen?
Ich habe übrigens noch eine funktionierende Suse-partition auf dem Rechner, ich kann also auf alles zugreifen.
danke schonmal für die schnelle antwort.
wum

pdreker · Beitrag von **pdreker** » 12.01.2005 15:19:17

memtest86 laeuft von einer Diskette, oder einfach aus einem Bootmanager Eintrag. "apt-get install memtest86+" und dann 'mal in /usr/share/doc/memtest86+/* schauen...

Patrick

wum · Beitrag von **wum** » 12.01.2005 15:22:47

hmm,
also ich hab den bootmanager (grub) von suse. Ich werde mal gucken, ob ich das da eingetragen kriege.
Thanx,
wum

pdreker · Beitrag von **pdreker** » 12.01.2005 15:30:11

Code: Alles auswählen

title  memtest
root   (hd0,0)
kernel /boot/memtest86.bin

Natuerlich musst Du evtl. Pfade und das Device anpassen... "Klau" einfach die Werte vom Debian Eintrag in der Grub Config...

Patrick

wum · Beitrag von **wum** » 12.01.2005 15:58:22

Da hab ich was falsch verstanden. Ich dachte, ich könnte apt-get via bootmanager nutzen. Aber so war das wohl nicht gemeint,wäre ja auch zu schön.
Sprich, ich muss erst memtest86 installieren und erst dann machts sinn, den bootmanager auf memtest anzusetzen, richtig?
Wie kann ich denn mit apt-get das Programm memtest86 installieren, wenn ich garnicht komplett booten kann?

wum

Natas12 · Beitrag von **Natas12** » 12.01.2005 16:01:01

dann wäre die einfachste methode, mit einem anderen rechner eine CD mit memtest zu besorgen. auf der hp von memtest gibt es startfähige images, die man auf cd(rw) brennen kann. könnte ein weilchen dauern, den speicher checken zu lassen... oder aber du findest irgendwo ne olle suse-cd, da ist standardmäßig memtest auf den bootfähigen CDs...

wum · Beitrag von **wum** » 12.01.2005 16:19:23

Ich habe jetzt die suse-dvd gebootet und den memory test gestartet. Wenn ich Glück habe, kann memtest86 den Schaden gleich beheben, oder?

Da die Festplatte 120 GB gross ist, wirds wohl ne ganze Weile dauern. Ich werde dann berichten.

Bis dahin vielen Dank an pdreker und natas12 für die schnelle Hilfe.

nepos · Beitrag von **nepos** » 12.01.2005 16:35:11

memtest behebt keine Schaeden, es testet einfach deine Speicherbausteine, ob die ok sind.
Wenn da was faul ist, heisst den Speicherriegel tauschen.

Natas12 · Beitrag von **Natas12** » 12.01.2005 16:36:54

äääh - moment: memtest ist für dein RAM. wenn du also defekte RAM-bausteine findest, musst du die austauschen.

wenn du allerdings deine FESTPLATTE meinst, ist es mit einem fsck getan. das kann wiederum aus deinem laufenden suse-system geschehen... (ein fsck der platten auf denen debian liegt - die platten sollten dabei nicht gemountet sein).

gruß

natas12

wum · Beitrag von **wum** » 12.01.2005 16:57:16

Ups, danke für den Hinweis. Wenn memtest86 den RAM testet, kann es ja nicht mehr allzu lange dauern, sind 256 MB.
Allerdings frage ich mich, ob denn da das Problem liegen kann, schliesslich bootet Suse erfolgreich auf dem gleichen Rechner.

"segmentation violation" klingt auf jeden Fall nach einem hardware Problem, oder? Könnte das Problem auch in einer der init-Dateien liegen?

wum

Natas12 · Beitrag von **Natas12** » 12.01.2005 17:03:03

nun, "jain".
ich hatte mal ein notebook mit win2k und fedora drauf. d.h. win2k ließ sich prima benutzen, fedora noch nicht mal richtig installieren. fedora schmierte IMMER mit segfaults ab. dann habe ich mal memtest drüberlaufen lassen - der speicher war platt.

woran das liegt, kann ich leider auch nicht sagen. aber wie gesagt: checke dann als nächstes deine debian-partitionen. wenn du z.B. beschädigte blöcke gerade an DER stelle hast, an der die ganzen wichtigen sachen deines debian-systems herumliegen (kernel, init-skripte, etc.), dann kann das system natürlich nicht booten...

gruß

natas12

ps: memtest kann schon recht lange dauern...

wum · Beitrag von **wum** » 13.01.2005 11:10:53

Nachdem memtest gestern 3 Stunden gelaufen war und nichts gefunden hat, habe ich einfach mal den Arbeitsspeicher ausgewechselt. Da mit dem neuen Arbeitsspeicher der gleiche Fehler auftritt, kann es nicht am RAM liegen.

Was fsck betrifft: Debian führt beim booten ja automatisch einen test durch. Den schafft es auch noch -und es gibt keine Fehlermeldungen- bevor sich der bootvorgang wie oben beschrieben "aufhängt" (bzw. sich in 30s-Intervallen schlafen legt). Macht es da noch Sinn, nochmal von aussen mit fsck zu testen? Ich habe es mal von suse aus mit fsck.ext3 und der Option -f getestet, aber es gab auch hier keine Fehlermeldung (und wenn er was fände würde er doch defaultmässig anbieten das zu reparieren, oder nichte?).

Hat noch jemand ne Idee?

g-henna · Beitrag von **g-henna** » 13.01.2005 11:49:24

Hi!

Versuch mal, ob du dem Kernel beim booten ein init=/bin/sh mit übergeben kannst. Dann kannst du in eine root-Shell booten und gucken, ob du schnell wieder n anderes Kernel-Image installieren kannst.

Bye
g-henna

wum · Beitrag von **wum** » 13.01.2005 11:56:38

Muss ich das init=/bin/sh bei grub eintragen oder kann ich ihm das direkt beim boot irgendwo mitteilen?

g-henna · Beitrag von **g-henna** » 13.01.2005 11:58:50

Hi!

Ausprobieren, bei lilo könntest du es zumindest gleich ranhängen.

Bye
g-henna

wum · Beitrag von **wum** » 13.01.2005 12:04:57

Habs schon gefunden. Sorry, ich dachte der bootprompt gelte nur für suse.

Ich bin jetzt in der root-shell. Ich habe noch nie einen neuen Kernel installiert. Das sollte über apt-get gehen, oder?

wum · Beitrag von **wum** » 13.01.2005 12:34:12

Hmm,
apt-cache findet nun kernel-images 2.4.16 bis 2.4.18. Ich traue mich nicht so recht.
Ein kernel-update scheint ja nach dem was ich gelesen habe, bisweilen eine unschöne Angelegenheit zu sein.
Wenn ich nochmal den gleichen Kernel wie bisher installiere wirds ja hoffentlich unkomplizierter.

Erstmal müsste ich aber wissen:
Welchen 2.4er Kernel habe ich denn bisher?
Im Verzeichnis /boot/ habe ich mehrere Dateien mit 2.4.24. Heisst das, dass ich den 2.4.24 er Kernel hatte bisher?
Verzeihung, wenn ich mich blöd anstelle.

nepos · Beitrag von **nepos** » 13.01.2005 12:35:57

uname -a liefert dir die Kernelversion der grade laufenden Kernels.

wum · Beitrag von **wum** » 13.01.2005 12:54:18

Ich hoffe, ich kann diesen thread bald schliessen. Noch ist es aber leider nicht so weit.
Ich habe von der root-shell aus kein Zugriff auf unser lokales Netzwerk, geschweige denn kann ich neue Kernel-Quellen laden.
Ist das normal so oder liegt das an meinem gecrashten System?

g-henna · Beitrag von **g-henna** » 13.01.2005 15:08:34

Hi!

Wenn du mit init=/bin/sh bootest, hast du gar nix, per default. Musst du alles, was normalerweise der init-Prozess macht (Module laden, HDs mounten etc.) per Hand machen. Wenn du mit oben genanntem Boot-Parameter arbeitest, mounte mal deine /-Partition (z.B. in /mnt) und mach dann chroot /mnt, dann hast du auch deine ganzen Konfigdateien etc. gleich da, arbeitest quasi, als wäre die ganze Installation in /mnt.
Und... wieso findet dein apt-cache nur 2.4.16 unf 2.4.18, wenn du doch selbst n 2.4.24 laufen hast? Ja gut, aber... wenn ich mir die eigentliche Problemstellung angucke... wie kommt es denn, dass das von einem Tag auf den anderen nicht mehr ging? Hast du als root irgendwas gemacht?

INIT:PANIC segmentation violation at 0x804ec92! sleeping for 30 sconds

Ist die 0x..-Adresse da immer die gleiche? Also a) alle 30 Sekunden und b) nach jedem Reboot?

Bye
g-henna

wum · Beitrag von **wum** » 13.01.2005 16:11:05

Wenn du mit oben genanntem Boot-Parameter arbeitest, mounte mal deine /-Partition (z.B. in /mnt) und mach dann chroot /mnt, dann hast du auch deine ganzen Konfigdateien etc. gleich da, arbeitest quasi, als wäre die ganze Installation in /mnt.

Wenn ich versuche, / zu mounten, sagt er mir, dev/hda6 (das ist die richtige partition) sei bereits eingehängt. Ich habe aber auch schon Zugriff auf die gesamte Partition samt Schreibrechten. Die sources.list von apt z.B. kann ich bearbeiten.
Ich habe da auch einfach mal eine etwas ältere sarge-cd eingefügt und versucht von der den kernel 2.4.27 zu installieren. Die Installation war auch erfolgreich aber beim booten (ich habe ihn bei grub extra eingetragen) endet es mit einer kernel panic.

Mehr Hoffnung hätte ich allerdings darauf, meinen alten kernel 2.4.24 neu zu installieren.

Und... wieso findet dein apt-cache nur 2.4.16 unf 2.4.18, wenn du doch selbst n 2.4.24 laufen hast?

Den hatte ich mittels apt-cache doch noch gefunden, wegen fehlendem Netzzugang war aber kein reinstall möglich. Das wichtigst wäre jetzt also Netzzugang. Ich werde das gleich nochmal versuchen mit manueller Zuweisung von ip und gateway.

... wie kommt es denn, dass das von einem Tag auf den anderen nicht mehr ging? Hast du als root irgendwas gemacht?

Bei meiner letzten Sitzung hatte ich als user einige grössere Dateien von debian auf eine andere Partition verschoben. Experimente als root habe ich keine gemacht.

Ist die 0x..-Adresse da immer die gleiche? Also a) alle 30 Sekunden und b) nach jedem Reboot?

Ja, ist immer die gleiche. Bezeichnet die Adresse physisch ne bestimmte Stelle auf der Festplatte?

pdreker · Beitrag von **pdreker** » 13.01.2005 16:12:02

Ja, ist immer die gleiche. Bezeichnet die Adresse physisch ne bestimmte Stelle auf der Festplatte?

Eher eine Stelle im Speicher, daher die Frage nach dem memtest...

Patrick

wum · Beitrag von **wum** » 14.01.2005 21:09:38

Weiter gehts.

@patrick
Dass es sich um einen Schaden direkt am Arbeitsspeicher handelt würde ich wie gesagt deshalb ausschliessen, weil mit einem anderen Speicher der gleiche Fehler auftrat. Wenn dann müsste es also irgendwelche Hardware sein, die auf den RAM zugreift -und die nen Schaden hat, an dem sich nur debian, aber weder Suse noch Windows stören. Es bleibt rätselhaft.

Ansonsten habe ich ein paar Details, die den Fehler vielleicht weiter eingrenzen:
Ich habe via CD den Kernel 2.6.8 installiert- und wenn ich den im grub-menu auswähle tritt genau die gleiche Fehlermeldung auf (also immer wieder "INIT:PANIC segmentation violation at 0x804ec92! sleeping for 30 sconds"). Auch hier habe ich mit init=bin/sh gebootet -und es ist tatsächlich der neue Kernel. Wenn ich ihn normal zu booten versuche gibt er vorm Schlafengehen zwei vielleicht interessante Sachen aus:

Zum einen:

INIT:version 2.78-knoppix booting

Es ist wie anfangs erwähnt eine knoppix harddiskinstallation. Lässt sich dieses INIT irgendwie neu installieren/ersetzen? Wenn ich es richtig verstanden hab, sind das ne Reihe von Skripten, die die verschiedenen Prozesse starten, oder nicht? Vielleicht ist doch eines dieser Skripte "beschädigt" und nicht die hardware?

Zum anderen macht der 2.6er kernel beim booten noch einen fsck-check. Gleich zu Beginn dieses checks sagt er:

warning:process 'update' used the obsolete
bdflush system call
Fix your initscripts?

Ich dachte erst "Fix your initscripts" klingt nach einer verheissungsvollen Frage, die ich nur irgendwie mit yes beantworten müsste

. Leider scheint das aber (wie z.B hier http://www.issociate.de/board/post/2002 ... _call.html) eine Fehlermeldung zu sein, die viele beim upgrade auf den 2.6er Kernel hatten, ohne dass es grundsätzliche Probleme gab. Insofern scheint die Meldung nichts mit meinem eigentlichen Problem zu tun zu haben.

Noch irgendwelche Vorschläge, was ich tun könnte?
Ich habe noch nicht ganz aufgegeben.