rechner rebootet beim löschen von mozilla sourcen

[[EisTea]]

Hallo Leute!
~~~~~~~~

Ich weiß nicht mehr weiter: Nachdem einer fehlschlagenden compilation eines 0.9.8er Mozillas wollte ich die sourcen wieder löschen (/tmp/mozilla). Mein Rechner rebootet jedoch jedesmal dabei! Ich habe schon mal versucht mit root im rl1 den ordner zu löschen, mit dem gleichen Ergebnis: Die sourcen sind nach dem reebot noch da. Auch ein start von der SuSE rescue-disk half nicht. Ich habe versucht die unterordner einzeln zu löschen, aber mein rechner sürtzt immer bei anderen ordnern ab :-(

Rechner:
SuSE Linux 7.3 mit KDE3 und 2.4.16-4GB Kernel
PII, 256MB Ram (125MB Swap)
/tmp ist auf der gleichen Partition wie /

EisTea

[melody lee]

Hast Du mal probiert, nicht von der Rettungs-CD zu starten sondern, ein Rettungssystem zu booten (nicht von der Platte), /tmp zu mounten und es dann zu löschen? Also mit dem "rm", das auf dem Rettungs-Sytem ist?

[[EisTea]]

Hallo!
Ja, habe ich. Sorry für meine ungenaue Vormulierung.

[oracle2025]

das kann doch gar nicht sein, oder?

[[EisTea]]

Doch, ist es aber! Ich habe auch früher schon mal den Mozilla compiliert, und da hat es beim löschen der sourcen nicht solche probs gegeben.

Hoffentlich kann ich wenigstens die Platte formatieren, ohne dass ... ;-)

EisTea

[Zaphod-B]

Moin,
sowas ähnliches hatte ich mit SuSE 7.3 auch schon mal.
Beim booten hat die Kiste beim mounten von /home jedesmal neu gebootet.
Das war erst durch Neuformatierung der Festplatte wieder hinzukriegen.
Ich glaub, dass es an reiserfs lag.
Ist bis heute aber nicht mehr aufgetreten.


Greetings Zaphod-B

[LKH]

Hi,

sowas hatte ich derletzt bei einem Kunden mit einer MDK 8.x. Wir haben dann das Rettungssystem von SuSE gestartet, die Platte gechecked (mit fsck.reiserfs), was ziemlich viele Fehler korrigierte (so hatte ich das Tool noch nie arbeiten sehen).

Danach lief wieder alle wunderbar und das böse Verzeichnis konnte gelöscht werden.

Also erst mal so probieren und viel Erfolg,

[[EisTea]]

Danke, dass hat funktioniert! :-) Allerdings brach der fscheck immer ab, wenn er das sourcen ferzeichnis checken wollte. ich habe einfach mal "blind" den tree rebuilded. danacg lief der check anstandslos durch, und nach einem neustart konnte ich den ordner löschen!

Weiß jmd. ob sowas öfter passiert, bzw. woran sowas liegt? Vielleicht sollte man dem reiserfs team/project dann mal diesen bug melden, falls es sich hierbei nicht um einen nicht behebbaren "zufallsfehler" handelt? - Ihr merkt sicher schon, was filesysteme angeht, bin ich nicht gerade der profi.

MFG EisTea