Partition zerschossen, fsck reparierte nicht alles

Fusselbär

Makefile Voyeur
Hallo,

über Weihnachten habe ich mir auf eine neue größere Festplatte
ein frisches FreeBSD 5.3 aufgesetzt.

Aktualisiert auf FreeBSD 5.3-STABLE i386
Xorg 6.8.1, KDE, (alles schön selbst kompiliert)
UT 2004 mit zusätzlichen Maps aktuellstem Patch installiert,
und noch den üblichen für nötig gehalten "Kram" installiert.

Alles lief Wunderbar! :D

Vor zwei Tagen habe ich morgens im Browser (Opera)
eine Seite "zurückgeblättert",
und das ganze System ist eingefroren.
*Warum passiert sowas immer vor dem ersten Kaffee?* :ugly:

(Den Abend vorher hatte ich noch ein Update gemacht,
vielleicht hat es da ja ein "schlechtes Bit erwischt".)


Ich habe ein bißchen gewartet um dem System Zeit zu geben,
dann Alt + F4, aber das beendete das Programm auch nicht.
Noch ein bißchen Zeit gegeben,
Strg + Alt + Backspace probiert,
aber das beendete den X Server auch nicht.

Mit Strg + Alt + F4 versucht auf meine 4. Konsole zu kommen,
aber auch das klappte nicht.

So habe ich mich äußerst ungern dazu entschließen müssen,
den Reset Schalter zu benutzen.

Das hat dann leider meine Partition "/usr" gründlich zerschossen. ;'(

In den Singleuser Modus gebootet und "fsck -y" laufen lassen.

Das sagte mir dann,
das der Superblock von "ad0s1f" (mein "/usr")
zerschossen sei.

Dann habe ich mit "/sbin/newfs -N /dev/ad0s1f"
nach alternativen Superblöcken gesucht.
160 war der erste gefundene Superblock.

Ich habe dann mit "fsck -b 160 /dev/ad0s1f"
dem fsck gesagt,
wo es einen alternativen Superblock finden kann.

"fsck" hat dann geschaltet und gewaltet,
einiges umgebaut,
und jetzt ist aus meinem Verzeichnis "local" unter "/usr"
eine Datei geworden.

Nun habe ich gesucht,
aber konnt leider bisher noch keine Möglichkeit finden,
dem Betriebsystem Bescheid zu geben,
das das Verzeichnis "local unter "/usr"
ein Verzeichnis ist, und keine Datei.

Die Manpage zu chmod und dessen Verwandschaft habe ich gelesen,
konnte aber leider nichts finden,
was mein Problem gelöst hat.

Auch meiner Suche über Google ist leider kein Erfolg gegönnt gewesen. ;'(

Und jetzt muß ich mich ganz kräftig schämen,
das ich mein schönes FreeBSD kaputtgekriegt habe. :ugly:

Hat vielleicht irgend jemand einen Tip für mich,
wie ich das wieder reparieren kann?

Gruß, Fusselbär
 
J

juedan

Guest
Hallo Fusselbär,

Du kannst jetzt eins versuchen:
Schau mal im Ordner lost+found nach, wo der genau liegt, weiß ich jetzt auch nicht, weil der bei mir noch in Erscheinung trat.
Dort müßtest etwas finden.

Viele Grüße

Jürgen
 

Fusselbär

Makefile Voyeur
Hallo,

ja, das Verzeichnis "lost+found" gibt es nach dem fsck
auf meiner "/usr" Partition.

Aber irgendwie kann ich mit den #(irgendeine 8-stellige Zahl)
nicht wirklich was Anfangen.

Es sind in diesem Verzeichnis 2796 Elemente.
Diese alle einzeln von Hand auseinander
zu pusemuckeln erscheint mir doch ein bißchen herbe. :apaul:

Diese FreeBSD Installation ist futsch,
nach dem allerersten Crash mit fsck. ;'(



Was ich im Augenblick gerade versuche:

Ich habe noch meine alte Platte mit einem installiertem FreeBSD.
Allerdings nicht richtig aufgelösten Paket Abhängigkeiten.
Es läuft aber noch!

Da habe ich jetzt mal die Partition hineingemountet.
Das Verzeichnis "usr/local" aus der halbkaputten,
aber ansonsten noch funktionierenden Installation
mit den nicht richtig aufgelösten Abhängigkeiten,
packe ich gerade mit tar.

Die betreffende Datei, die mal ein Verzeichnis war,
habe ich verschoben und umbenannt
Danach will ich das tar Archiv in die gemountete
"/mnt/baustelle/usr/local"
entpacken.

Mal sehen, ob das soweit funktioniert,
das die Weihnachtsdinstallation für´s erste schon mal wieder läuft.

Weil komplett neuinstallieren,
darauf habe ich keine Lust.
Verbringe irgendwie ohnehin schon zu viel Zeit am Computer. :ugly:
Mal wieder Inkline Skates an den Füßen
und frische Luft um die Nase wäre doch auch mal ganz nett. :)

Gruß, Fusselbär
 

odo

Member
Hi,

mir ist gestern was ähnliches passiert, da bei dem Rechner (FreeBSD 5.4) apm nicht sauber funktionierte (es gab beim power off immer einen kernel trap), wollte ich mal den kerneldump aktivieren.

Als dumbdev in der rc.conf hab ich dann dummerweise die /usr Partition angegeben (/dev/ad0s1f)... Diese hat dann irgendwie den superblock 32 (oder war's 23??) zugeordnet bekommen und fsck findet den richtigen nicht, so dass ich den wohl irgendwie per Hand rausfinden muss.

Wenn mir jmd. sagen könnte ob man damit erfolg hat und wenn ja, wo man den superblock finden kann.
Oder kann ich da auch ein restore anwenden, da er den Kernel (192MB) dann auch munter nach /usr gedumpt hat, und dann ist alles wieder i.o.??

Bin ein wenig verzweifelt.
 

Fusselbär

Makefile Voyeur
Hallo,

da muß ich wohl mal so eine Art Epilog schreiben:

Eine meiner gemounteten Festplatten ist langsam kaputtgegangen,
und hat die Zerstörungen verursacht.
Seitdem eine neue Festplattte als Ersatz aingebaut ist,
läuft FreeBSD wieder wunderbar.
Keine weiterten Zerstörungen am Filesystem.

Die kaputte Festplatte hatte sich schlußendlich komplett festgefressen.
Leider hatten selbst Überprüfungen mit dem Festplattenherstellertool
keine Ergebnisse gebracht,
bis es endlich soweit war,
und die Festplatte die typischen Schlaggeräusche von sich gab,
als die Leseköpfe hin und her schlugen. :ugly:
Wer das einmal gehört hat,
wird das Geräusch wohl nicht mehr so schnell vergessen.

Gegen eine kaputte Festplatte im System die dort Terror erbreitet,
ist wohl selbst fsck machtlos.


Gruß, Fusselbär
 

odo

Member
Ich denke nicht, dass die Platte kaputt ist, da der Fehler direkt nach dem missglueckten kerneldump aufgetreten ist.

Du meintest, du haettest fsck die blockgroesse des kaputten slices uebergeben s.o.)... Muss da der erste Block angegeben werden oder die gesamte Laenge und wie hast du den (bzw. die) rausgefunden??

Gruesse!
 

Fusselbär

Makefile Voyeur
Hallo,

schaue mal man fsck_ffs an,
es gibt mehrere Superblöcke,


Habe hier nur noch so eine auf einen Zettel geschmierte Notiz:
Wo gibt es noch alternative Superblöcke,
wenn das Orginal kaputt ist?

$/sbin/newfs -N /dev/betroffene_Partition # (bei mir war´s ads1f)
Aber ohne Garantie!
Weiter Informationen sollte man newfs geben,
bitte vorher durchlesen!

Den neuen "Ersatzsuperblock" gibt man nach meinem Notizzettel so an:
fsck_ffs -b "Blockzahl" /dev/betroffene_Partition

Bitte wirklich vorher die Manuals lesen,
meine zwar, das hat so funktioniert,
aber ohne Garantie.

Viel Glück. :)


Gruß, Fusselbär
 

odo

Member
Erstmal besten Dank für die Antworten.
Ich bin jetzt ein Stückchen weiter (oder auch nicht). Da alles nicht so wirklich geklappt hat mit newfs und den alternativen super-blocks hab ich in meiner Verzweiflung ein tunfs -A gemacht, was der Partition wohl einen neuen sb zuordnet... Fazit war, dass ein fsck zumindest versucht hat zu reparieren (was vorher nicht möglich war) .

Doch scheitert fsck mit der Fehlermeldung "cannot alloc ca. 2.6GB for inoinfo".
Kann man da noch was machen? Irgendwelche Reperaturtools oder so?

MfG

der Odo
 

r2d2

Well-Known Member
Ich wühl den beitrag hier mal wieder hoch!

Habe ein ähnliches Problem mit meinem 2ten Rechner.Meine /home partition!

Im single user modus bringt leider ein fsck nichts, das ganze endet mit

** /dev/twed0s1g (NOWRITE)
** Last Mounted on /home
** Phase 1 - Check Blocks and Sizes
fsck_ufs: cannot alloc 409753576 bytes for inoinfo

Hatte Probleme mit dem Sound und musste den resetschalter benutzen, das ganze 4 mal :ugly:

nun sieht das ganze so aus:

 

Yamagi

Possessed With Psi Powers
Teammitglied
Wenn man das System während eines fsck-Laufes (background oder normal) resetet, tritt AIFAIK genau das auf, was Softupdates verhindern sollen. Das Dateisystem gerät in einen nicht definierten Zwischenzustand, den fsck nur teilweise beheben kann. Ein Datenverlust ist also höchstwahrscheinlich. Machen kann man da AFAIK nicht mehr viel, außer Diskeditor (dafür muss man schon krank sein ;)) oder gewaltsam mounten und runterkopieren...
 

Fusselbär

Makefile Voyeur
testdisk, letzte Rettung wenn sonst nix mehr geht?

Hallo r2d2,

ein Freund hatte neulich sich das erste mal mit Linux beschäftigt,
und hatte ausgerechnet eine etwas ältere problematische Version
(ganz früher 2.6er Linux Kernel) erwischt,
die bei ihm zusammen mit seinem Bios, (die LBA Geschichte)
das Windows XP (jaja, Dualboot, nur eine Festplatte) nicht mehr booten ließ.

Der Reparaturpatch klappte auch nicht mehr,
es waren vorher schon andere freundliche Helfer mit fixmbr dran gewesen.

Nach der langen Vorgeschichte:
womit sich dann doch noch was retten ließ, war testdisk. (sogar alles) :)
testdisk gibts es auch für andere Systeme:
BeOS, BSD, Linux, Netware, Solaris i386 disklabel und Windows.

Mir ist allerdings dabei der Angstscheiß gelaufen. :ugly:
Durfte es aber später direkt nochmal, nach dem zusammenführen
von zwei Windows Versionen, benutzen.
Da war wohl dann Partition Magic ein kleines Mißgeschick unterlaufen. :apaul:
Aber ich habe immer ganz schön gezittert mit dem testdisk.
Wenn ich mich richtig erinnere,
hat mir diese Anleitung zu testdisk ziemlich geholfen.
Mache aber trotzdem besser vorher ein Backup.
Das kann mit testdisk gutgehen, muß aber nicht.
(war aber bisher von den Ergebnissen sehr angetan)

Aber mit diesem "(NOWRITE)", :confused:
ist ganz sicher die fstab noch in Ordnung?
Läßt sich in der fstab nicht auch irgendwie das schreiben verbieten?

Auf jeden Fall mal, viel Glück mit Deiner /home Partition.


Gruß, Fusselbär
 

dissent

Well-Known Member
hm, jetzt dachte ich mensch da hat ja jemand genau das gleiche Problem wir ich (usv gestestet akku put, 2 partitionen bzw. superblöcke im arsch) da find ich jetzt genau meine lösung. aber so richtig trau ich dem hier nich ;)
 

r2d2

Well-Known Member
Oh Fusselbär, du hast mir ja nen Tipp gegeben. :rolleyes:

Jedenfalls hab ich mich dann für ne neuinstallation entschieden, das rumgefummle dauerte mir dann doch zu lange! Hab den kürzeren weg genommen und hoffe das mir sowas nicht mehr passiert! wenigstens konnte ich ja noch meine Daten retten!

MfG
 
Oben