problem bei fsck

[krip48]

Ich habe im single mode fsck ausgeführt und bekomme immer bei dem mountpoint /usr folgende meldung.

Free BLK Count(s) wrong in SuperBLK
SLAVAGE?

Ist meine HDD defekt? Kann ich den fehler irgend wie beheben?

 

[Kamikaze]

Hast du schon mal mit 'y' geantwortet?

 

[krip48]

Ja hab ich aber leider ohne erfolg. Die meldung kommt immer wieder!

 

[Kamikaze]

Du könntest versuchen den Schreibcache abzuschalten. Wenn das nicht hilft hast du wirklich ein Problem.

In die /boot/loader.conf folgendes eintragen:
hw.ata.wc=0

 

[krip48]

Werd ich mal testen. Was ist wenn das auch nichts hilft? Neue Platte kaufen?

 

[Kamikaze]

Die SMART-Daten auslesen ist nicht verkehrt. Eventuell auch ein Backup machen und eine Schreibtest durchführen. Die üblichen Schreibtests vernichten alle Daten auf der Platte. Deshalb ist das Backup wichtig.

 

[krip48]

hast du vielleicht ne anleitung für SMART-Daten auslesen? hab so was noch nicht gemacht!!!

 

[Kamikaze]

Die kann man sich meistens im BIOS anzeigen lassen. Oder von sysutils/smartmontools.

 

[krip48]

Sorry, hast du vielleicht noch ein tip wegen backup über netzwerk. hab sonst keine andere möglichkeit ein backup zu machen. Platte zu klein und ist ein laptop ohne brenner.

 

[Yamagi]

dump -La0 -f - /mountpunkt | gzip | ssh user@ziel dd of=/pfad/zu/backup.dump

 

[krip48]

Danke schön. Wenn ich mein system zerschossen habe. Wie bekomme ich das backup wieder eingespielt? sorry hab aber noch nie so eine situation gehabt.

 

[Kamikaze]

Du könntest ein dump in eine ssh-Verbindung pipen.

Edit: zu langsam

Du kannst restore ganz ähnlich verwenden. Du müsstest die Platte von einer FreeBSD Boot-CD neu partitionieren und kannst dann auch gleich über ssh das restore durchführen.

 

[krip48]

mmmm!!! danke. hätte ich auch selber drauf kommen können. na dann werd ich mich mal ran setzen. melde mich wenn das durch hab. vielen dank schon mal für eure schnellen antworten...

 

[Kamikaze]

Probier das restore über ssh lieber schon mal aus. Du kannst dir ein kleines Image mit

# dd bs=1m count=1024 < /dev/zero > test.image

anlegen und es mit

# mdconfig -f test.image

einbinden. Mit

# newfs /dev/md0

legst du darin ein Dateisystem an. Auf das kannst du dann mal Probeweiser dein restore loslassen (nimm einen kleinen Dump wie /var oder /tmp) und es danach mounten.

# mount /dev/md0 mountpunkt

Wenn das alles richtig aussieht weißt du, dass du den Prozess durchführen kannst.

Nach der Wiederherstellung des Systems solltest du im vollständig gemounteten Zustand noch ein:

# chmod 0777 /tmp

durchführen.

 

[mapet]

sollte man /tmp nicht mit sticky bit versehen?

Bei Verzeichnissen

Das Sticky-Bit ermöglicht das Anlegen von gemeinsam genutzten Verzeichnissen.

Hat ein Verzeichnis beispielsweise für alle Benutzerklassen alle Dateirechte gesetzt (777/rwxrwxrwx), dann kann jeder Benutzer in dieses Verzeichnis schreiben, aber auch jede Datei darin löschen. Durch Setzen des Sticky-Bits wird es (zusätzlich zum Eigentümer des Verzeichnisses und dem Superuser) nur dem Eigentümer einer Datei erlaubt, diese zu bearbeiten oder zu löschen. Verwendung findet das Sticky-Bit zum Beispiel bei /tmp.

das wäre dann "chmod 1777 /tmp"

 

[Kamikaze]

Stimmt natürlich.

 

[krip48]

Habe meine HDD einmal mit dem tool im Bios testen lassen und einmal mit "smartmontool".

#smartctl --test=long /dev/ad0

es wurden keine fehler gefunden. Nach einem "fsck" im single-mode ist alles wieder OK. Hab mir ein backup angelegt aber das braucht ich nicht neu einspielen.