[UPDATE] Files gehen kaputt
[UPDATE] Files gehen kaputt
Hallo.
Ich habe ein Riesenproblem. Habe vor einiger Zeit ein Daily-Build von Debian mit Kernel 2.6.6 installiert. Boot-Partition als ext2 und der Rest alles ReiserFS 3.6. Der Rechner dient als Fileserver, wo meist RAR-Dateien bewegt und auch gepackt werden. Beim Uploaden gehen bereits Dateien kaputt. Kommt eine Datei richtig an und wird dann gepackt (wie gesagt alles mit RAR) , passiert es oft aber auch nicht immer, dass nach dem Packen das Archiv defekt ist. Nun meine Frage: ist dieses Problem bereits bekannt? Unter SuSE mit 2.4er Kernel lief noch alles 1A. Verträgt sich RAR mit dem neuen Kernel nicht? Hat Debian ein allgemeines Problem mit ReiserFS? Weiss jemand einen Rat? Vielen Dank!
Debian n00b
P.S.: Achja ein Hardwarefehler auf der Platte kann ich auch ausschliessen da ich insg. 4 Platten in dem Rechner hab und dieses Problem überall auftritt.
Ich habe ein Riesenproblem. Habe vor einiger Zeit ein Daily-Build von Debian mit Kernel 2.6.6 installiert. Boot-Partition als ext2 und der Rest alles ReiserFS 3.6. Der Rechner dient als Fileserver, wo meist RAR-Dateien bewegt und auch gepackt werden. Beim Uploaden gehen bereits Dateien kaputt. Kommt eine Datei richtig an und wird dann gepackt (wie gesagt alles mit RAR) , passiert es oft aber auch nicht immer, dass nach dem Packen das Archiv defekt ist. Nun meine Frage: ist dieses Problem bereits bekannt? Unter SuSE mit 2.4er Kernel lief noch alles 1A. Verträgt sich RAR mit dem neuen Kernel nicht? Hat Debian ein allgemeines Problem mit ReiserFS? Weiss jemand einen Rat? Vielen Dank!
Debian n00b
P.S.: Achja ein Hardwarefehler auf der Platte kann ich auch ausschliessen da ich insg. 4 Platten in dem Rechner hab und dieses Problem überall auftritt.
Zuletzt geändert von n00b am 18.07.2004 11:29:03, insgesamt 1-mal geändert.
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
Nur so sicherheitshalber: RAM 'mal gestestet? -> memtest86+ mindestens 6 Stunden laufen lassen. FS Korruption kann auch durch kippende Speicherbits an der richtigen (oder falschen) Stelle erzeugt werden...
Patrick
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
-
- Beiträge: 644
- Registriert: 16.12.2003 15:44:51
Als Ergänzung zu memtest86 kann ich diesen Artikel (Vorsicht SuSE-Link ) empfehlen.
Bei mir war vor ca. 2 Jahren der Arbeitsspeicher hinüber und memtest86 fand egal mit welchen Optionen null Fehler. Dann bin ich auf obiges Script gestoßen als ich nach Möglichkeiten suchte die Hardware zu testen und stellte fest, dass etwas nicht stimmt. Testweise neuen Speicher reingehauen und siehe da Problem beseitigt
greetz
mastermind
Bei mir war vor ca. 2 Jahren der Arbeitsspeicher hinüber und memtest86 fand egal mit welchen Optionen null Fehler. Dann bin ich auf obiges Script gestoßen als ich nach Möglichkeiten suchte die Hardware zu testen und stellte fest, dass etwas nicht stimmt. Testweise neuen Speicher reingehauen und siehe da Problem beseitigt
greetz
mastermind
Also memtest86+ hat nach 4,5 Stunden keinen einzigen Fehler gefunden. Werde jetzt noch dieses Script testen aber es ist mir ein wenig unklar wie das unter Debian funktionieren soll. Es gibt weder das Verzeichnis "/usr/src/linux" noch die Datei ".config", die für dieses Script benötigt werden. Mit dem Original-Script auf der http://www.bitwizard.nl/sig11 kann ich erst recht nichts anfangen weil er da ein "bzImage" Image zum Testen kompilieren möchte, das ebenfalls nicht vorhanden ist. Gibt das Script eigentlich nur fehlerhafte Logfiles aus oder kann man denn irgendwie definitiv feststellen was nun defekt ist? Kann natürlich auch das Mainboard oder die CPU sein wenn es sich tatsächlich um einen Hardware-Fehler handelt. Besten Dank für die Tipps.
Debian n00b
Debian n00b
-
- Beiträge: 644
- Registriert: 16.12.2003 15:44:51
/usr/src/linux ist in der Regel ein Symlink auf das Verzeichnis des aktuellen Kernels. Als root folgendes ausführen:
Danach kopierst Du deine Kernelconfig aus /boot (z.B.: config-2.4.18-bf2.4) in das Verzeichnis /usr/src/linux und benennst die kopierte Datei in .config um. Der "." vor dem "config" bedeutet, dass es eine versteckte Datei ist und Du sie im Dateibrowser mit den Standardeinstellungen nicht siehst. Als root:
Danach sollte das Script laufen, vorausgesetzt Du hast die entsprechenden Entwicklerwerkzeuge und die Kernelquellen installiert. Eventuell musst Du vor dem Anlegen des Symlinks und der Datei noch die Kernelquellen installieren, falls diese nicht vorhanden sind.
Du kannst nur feststellen ob das System insgesamt stabil ist oder nicht. Wenn die Logfilgröße unterschiedlich ist stimmt etwas nicht und Du kannst dann per try and error oder mit anderen Hilfsmitteln versuchen den Fehler zu lokalisieren. Sollte die Logfilegröße immer gleich sein, dann kannst Du höchstwahrscheinlich davon ausgehen, dass mit der Hardware alles in Ordnung ist. Somit hättest Du eine große Fehlerquelle weniger und kannst bei rar, Netzwerkeinstellungen, reiserfs oder sonstwo weitersuchen.
greetz
mastermind
Code: Alles auswählen
ln -s /usr/src/Name_des_aktuellen_Kernelverzeichnisses /usr/src/linux
Code: Alles auswählen
cp /boot/config-2.4.18-bf2.4(<=Beispielname) /usr/src/linux/.config
Du kannst nur feststellen ob das System insgesamt stabil ist oder nicht. Wenn die Logfilgröße unterschiedlich ist stimmt etwas nicht und Du kannst dann per try and error oder mit anderen Hilfsmitteln versuchen den Fehler zu lokalisieren. Sollte die Logfilegröße immer gleich sein, dann kannst Du höchstwahrscheinlich davon ausgehen, dass mit der Hardware alles in Ordnung ist. Somit hättest Du eine große Fehlerquelle weniger und kannst bei rar, Netzwerkeinstellungen, reiserfs oder sonstwo weitersuchen.
greetz
mastermind
@cordovan
Ja, die ganzen Punkte bin ich schon durchgegangen. Zuerst dachte ich es liegt am gemischten ReiserFS (3.5 und 3.6), das ich von der SuSE Distribution in die Debian Installation übernommen habe. Komplettes System neu installiert, alle Platten neu partitioniert und alle mit ReiserFS 3.6 (bis auf die Boot, die ist ext2) formatiert. Dann sicherheitshalber die Netzwerkkarte ausgetauscht, wobei es eigentlich nichts damit zu tun haben kann weil eben auch Files kaputt gehen, die man lokal auf der Platte packt. Also nicht nur die Archive, die reinkommen, sondern auch die, die gepackt werden. Wie bereits geschrieben, alles mit RAR. Von Tag zu Tag wird es immer wahrscheinlicher, dass RAR ein Problem mit dem 2.6er Kernel hat weil es diese Schwierigkeiten unter SuSE mit dem 2.4er nicht gab. Ich kann mir auch schwer vorstellen, dass Debian an sich ein Problem mit dem FS hat oder mit RAR oder was weiss ich. Ich muss aber alle Möglichkeiten ausschliessen um endlich sicher zu sein, was nun letztendlich das Problem ist. Das macht mich langsam wahnsinnig.
Debian n00b
Ja, die ganzen Punkte bin ich schon durchgegangen. Zuerst dachte ich es liegt am gemischten ReiserFS (3.5 und 3.6), das ich von der SuSE Distribution in die Debian Installation übernommen habe. Komplettes System neu installiert, alle Platten neu partitioniert und alle mit ReiserFS 3.6 (bis auf die Boot, die ist ext2) formatiert. Dann sicherheitshalber die Netzwerkkarte ausgetauscht, wobei es eigentlich nichts damit zu tun haben kann weil eben auch Files kaputt gehen, die man lokal auf der Platte packt. Also nicht nur die Archive, die reinkommen, sondern auch die, die gepackt werden. Wie bereits geschrieben, alles mit RAR. Von Tag zu Tag wird es immer wahrscheinlicher, dass RAR ein Problem mit dem 2.6er Kernel hat weil es diese Schwierigkeiten unter SuSE mit dem 2.4er nicht gab. Ich kann mir auch schwer vorstellen, dass Debian an sich ein Problem mit dem FS hat oder mit RAR oder was weiss ich. Ich muss aber alle Möglichkeiten ausschliessen um endlich sicher zu sein, was nun letztendlich das Problem ist. Das macht mich langsam wahnsinnig.
Debian n00b
*************************************************************
STATUS:
Nachdem ich die letzten Tage damit verbracht habe alles mögliche durchzutesten, habe ich feststellen müssen, dass der Kernel 2.6.6, der Grund allen Übels gewesen ist.
Ich habe das empfohlene Script verwendet um anhand der Logfiles festzustellen ob mit der Hardware irgendwas nicht stimmt. Tatsächlich hat es mir sporadisch "fehlerhafte" Logfiles ausgespuckt. Der nächste Schritt war natürlich den Speicher austauschen. Nachdem ich aber alle Möglichkeiten durchgegangen bin und die Wahscheinlichkeit, dass 2 Speichermodule defekt waren, sehr gering gewesen ist, habe ich mich dazu entschlossen das Kernel-Image 2.4.26 aufzuspielen.
An dieser Stelle sollte ich noch erwähnen, dass es sich um einen Dual-Intel 1GHz Rechner handelt und der Kernel 2.6.6 war ohne SMP installiert worden, also nur eine CPU genutzt.
Ob das jetzt der Grund für die Fehler war oder ob der Kernel an sich mit der Hardware nicht richtig funktioniert oder auch sensibler auf Unstimmigkeiten in der Hardware reagiert, kann mir vielleicht einer von euch sagen. Ich weiss es nicht
Tatsache ist jedoch, dass ich das Testscript nun seit 16 Stunden laufen habe und alle Logfiles in ordnung (=gleich) sind. Die Files an sich gehen auch nicht mehr kaputt aber ganz sicher kann ich mir erst in einigen Tagen sein.
Ich danke euch für die nützlichen Tipps!
Debian n00b
*************************************************************
STATUS:
Nachdem ich die letzten Tage damit verbracht habe alles mögliche durchzutesten, habe ich feststellen müssen, dass der Kernel 2.6.6, der Grund allen Übels gewesen ist.
Ich habe das empfohlene Script verwendet um anhand der Logfiles festzustellen ob mit der Hardware irgendwas nicht stimmt. Tatsächlich hat es mir sporadisch "fehlerhafte" Logfiles ausgespuckt. Der nächste Schritt war natürlich den Speicher austauschen. Nachdem ich aber alle Möglichkeiten durchgegangen bin und die Wahscheinlichkeit, dass 2 Speichermodule defekt waren, sehr gering gewesen ist, habe ich mich dazu entschlossen das Kernel-Image 2.4.26 aufzuspielen.
An dieser Stelle sollte ich noch erwähnen, dass es sich um einen Dual-Intel 1GHz Rechner handelt und der Kernel 2.6.6 war ohne SMP installiert worden, also nur eine CPU genutzt.
Ob das jetzt der Grund für die Fehler war oder ob der Kernel an sich mit der Hardware nicht richtig funktioniert oder auch sensibler auf Unstimmigkeiten in der Hardware reagiert, kann mir vielleicht einer von euch sagen. Ich weiss es nicht
Tatsache ist jedoch, dass ich das Testscript nun seit 16 Stunden laufen habe und alle Logfiles in ordnung (=gleich) sind. Die Files an sich gehen auch nicht mehr kaputt aber ganz sicher kann ich mir erst in einigen Tagen sein.
Ich danke euch für die nützlichen Tipps!
Debian n00b
*************************************************************