Re: lost+found LFS? Was: root: keine Berechtigung
Hallo Rainer,
Am Friday 22 November 2002 17:18 schrieb Rainer Ellinger:
> Gerhard Gaussling schrieb:
> > ich habe den check gemacht, und tatsächlich war ein rebuild-tree
> > fällig, der mir dann leider das ganze System zerschossen hat.
> > Das Dateisystem ist jetzt nicht mehr korrupt, dafür die Dateien.
>
> Sind da wichtige Daten drauf? Rettung um jeden Preis?
Nö, nur ein ~+/- halbes Jahr sporadische "Bastelarbeit" an der
Debiankonfiguration. Aber Wiederholung soll ja üben.
> Die Daten sind nämlich zu 95% noch richtig vorhanden. Er hat die
> Daten selbst nicht durcheinander gewirbelt, sondern nur in der
> Verwaltung falsch verkettet. Ein richtiger Datenverlust entsteht
> dabei nur, wenn reiserfsck versehentlich neue Metainformationen an
> Stellen ablegt, wo eigentlich Daten waren. Das trifft meistens nur
> einige wenige Prozent.
Wie erklären sich dann soviele sig11 z.B. less: Segmentation fault,
oder falscher ELF header?
Ich habe sowieso den Verdacht, dass der Check alte gelöschte
Programmversionen zu neuem Leben erweckt hat, und die aktuelle
sarge-version munter in den Inodes-verzeichnissen unter lost+found
versteckt hat, was eventuell wegen falscher Linkung gegen libc den ein
oder anderen Speicherzugriffsfehler erklären könnte.
Auch habe ich mein komplettes Home Verzeichnis unter lost+found
gefunden, obwohl es intakt auf einer anderen partition lag. Ich denke
dass ich damals beim Plattenumzug das Homeverzeichnis auf die jetztige
Homepartition kopiert hatte, und es von der root-partition löschte.
Anders kann man sich sowas ja nicht erklären.
Ich hatte reiserfs beim Kauf der neuen Festplatte eingerichtet (nur
deshalb habe ich überhaupt ein Backup. Ich sollte diese "Strategie" mal
überdenken). Das war Anfang September mit woody, was für eine
Kernelversion damals unter woody installiert war weiß ich nicht mehr.
Könnte aber sein, dass reiserfs "damals" noch größere bugs enthielt.
> Sofern die Partition früher _nicht_ mit "notail" gemountet wurde,ist
> dies bei der Datenrettung ein guter Einstiegspunkt.
> [...]
>
> Aber das nur als Hintergrundinformation. Du kommst an dieser Stelle
> auch mit dem grössten Enthusiasmus nicht weiter. Herz-Op mit dem
> Taschenmesser ist auch für den Experten eine Geschichte mit
> ungewissem Ausgang. Ich hatte mal so einen ReiserFS-Fall, da wären
> knapp ein Mannjahr Arbeit verloren gegangen. Bei so etwas lohnt sich
> der Aufwand, wenn man vier Wochen später die Daten wieder hat. Kostet
> dann aber auch einen 4-stelligen Euro-Betrag.
Na, dann werde ich mal davon Abstand nehmen, und nur bei Bedarf mit
find in dem lost+found Backup nachschlagen.
> Wenn Du selber Versuche unternehmen möchtest ist Grundvoraussetzung,
> eine freie Platte zu haben, auf die man eine 1:1 Kopie ziehen kann.
> Dann werden Rettungsversuche nur an der Kopie vorgenommen. Es kann
> viele misslungene Durchläufe benötigen, bis klar ist, wie eine
> erfolgreiche Rettung ablaufen muss. Anders gesagt, ohne immer wieder
> neue 1:1 Kopie kann man es kaum schaffen.
Nein Danke. Hört sich doch nicht so verlockend an.
> Mich würde interessieren, wie Du reiserfsck verwendet hast. Welche
> Version? Mit welchen Optionen? Ich vermute, das ReiserFS wurde schon
> mit einer deutlich älteren und noch fehlerbehafteten Kernelversion
> angelegt wurde, und dort die Ursache für das Problem gelegt wurde.
reiserfsck statisch gelinkt aus den neuesten sourcen von
www.namesys.com selbst kompiliert.
Die ungemountete partition vom Rettungssystem dann mit
reiserfsck -V
reiserfsck --check
reiserfsck --fix-fixable
reiserfsck --rebuild-tree -S
gecheckt. Nach eineinhalb Stunden war dann die Katastrophe da.
Ein einfaches cp -av /etc /home und cp -av /var/lib/dpkg /home usw.
hätte mir wohl die jetztige Situation erspart. Der Aufruf von
reiserfsck --rebuild-tree legt einem das ja auch eindringlich nah.
> Andere Möglichkeiten wären ein zu sorgloser Umgang (manche Leute
> denken einfach "ich habe ja Journalling - zack, Reset-Taste") oder
> Hardware-Probleme.
Ich werde mal mit memtest86 testen, da fallen dann ja, soweit ich mich
erinnere auch defekte Festplattenkabel auf.
> > Ich habe das komplette Installationssystem eingebüßt.
>
> Wenn's nur das ist, dann beginne von vorne oder mit dem letzten
> Backup.
Ich habe jetzt von vorne Angefangen, und bediene mich dem was in
/home/old/etc noch zu gebrauchen ist.
> Wichtig wäre, mit aktuellen reiserprogs und aktuellem Kernel
> (möglichst 2.4.19) das System anzulegen, um nicht direkt mit dem
> Risiko alter Bugs im FS zu starten. Es kann sinnvoll sein, dazu eine
> kleine ca. 100 MB grosse Installation mit den aktuellen Tools
> einzurichten, nur um das endgültige System damit aufsetzten zu
> können.
Ich bin jetzt wieder bei ext3
> > debian:~# ls /lost+found | wc -w
> > 21869
>
> Um das näher zu beurteilen kannst Du Dir mit "find /lost+found |
> xargs file" (ggf. auch mit anschliessendem Umleiten in eine Datei
> oder weiterem sort) einen Überblick/Eindruck verschaffen, welche Art
> Dateien es getroffen hat.
> Ist es weitgehend nur ein Typ (z.B. News, Mail, MP3, etc.) kannst Du
> davon ausgehen, dass nur ein Verzeichnis(-baum) mit dieser Art von
> Dateien betroffen ist. Geht es kunterbunt durch alles, insbesondere
> mit vielen Systemdateien, macht es gar keinen Sinn mehr zu
> restaurieren.
Das dachte ich mir dann auch...
> > Es hagelt Meldungen wie Exec Format error, No such file oder beim
> > Start fsck .reiserfs for device /dev/hda7 exited with signal 11
>
> Ganz schlecht. Bist Du sicher, dass Deine Hardware ok ist? Wenn Du
> neu aufsetzt, erst mal memtest86 und einen Kernel kompilieren. Gibt
> es dabei Probleme, könnte es auch die Ursache für die FS-Korruption
> gewesen sein.
Ganz sicher bin ich da nicht. Merkwürdig auch, dass sich meine Databox
jetzt nicht mehr wie vorher ansprechen lässt. Setserial kann scheinbar
den sereiellen Port nicht mehr entsprechend konfigurieren. Das Modem
reagiert nicht auf seinen Initstring, wenn es mit Baud=115200
angesprochen wird, was früher problemlos ging.
> > Leider habe ich nur ein etwa 1-2 Monate altes Backup z.B. von /etc
> > oder /var .
>
> Es bestätigt sich immer wieder, dass man wohl nur so lernt, das Wort
> "Backup" zu verstehen und konsequent zu handhaben.
Ich hatte gerade mal alles so beisammen, wie ich es mir vorstellte, und
war kurz davor mich mit dem Thema Backup zu beschäftigen...
> [...]
> Es ist eine Erfahrung aus der ReiserFS-ML, dass eine grosse Zahl der
> FS-Korruptionen ihre Ursache in der Hardware hatten. ReiserFS ist im
> Gegensatz zu den anderen Dateisystem äusserst CPU-lastig, und zeigt
> so schneller Symptome, als andere FS.
>
Auf meinem PentiumIII 667Mhz erschien mir reiserfs auch langsamer zu
sein als ext3, was eventuell auf so eine Überlastung hindeuten könnte.
Bei einem Monitorausfall habe ich allerdings auch die Resettaste
gedrückt, da ich mich scheinbar vertippt hatte, jedenfalls schien mir
das System zu hängen.
ciao
gerhard
Reply to: