e2fsck für alle Laufwerke

[itari]

sooo ... nun hab ich es ein paar Stunden getestet und es scheint gut zu laufen: der Plattentest beim Booten.

Achtung wichtiger Hinweis: Dieser Hack ist nicht ganz ungefährlich, daher Datensicherung vorher und Mut sammeln; es kann sein, dass man neu installieren muss, wenn wirklich gravierende Fehler erkannt und beseitigt werden!!! Alles geschieht wieder auf eigene Kappe!!!!

Hintergrundgedanken für den Hack: In der Start-Phase ist noch nicht viel los auf der DS, relativ wenig Prozesse, keine Server usw. In dieser Phase ist das /volume1 ... noch nicht gemountet und man kann das /(root)-Volume auf read-only setzen. read-only ist eine hinreichende Bedingung für den fsck-Lauf. Die Meldungen werden ins /tmp-Verzeichnis (steht im als RAM-Disk zur Verfügung) geschrieben.

Die folgenden Zeilen muss man in die /etc/rc aufnehmen (bei mir nach der Zeile 49: mount -t tmpfs /tmp /tmp).

mount -o remount,ro /
date >/tmp/boot.log
echo -e "e2fsck -pf /dev/md0 \c" >>/tmp/boot.log
/sbin/e2fsck -pf /dev/md0 2>&1 >>/tmp/boot.log
echo -e "e2fsck -nv /dev/md0 \c" >>/tmp/boot.log
/sbin/e2fsck -nv /dev/md0 2>&1 >>/tmp/boot.log
echo -e "e2fsck -p /dev/md2 \c" >>/tmp/boot.log
/sbin/e2fsck -p /dev/md2 2>&1 >>/tmp/boot.log
echo -e "e2fsck -nv /dev/md2 \c" >>/tmp/boot.log
/sbin/e2fsck -nv /dev/md2 2>&1 >>/tmp/boot.log
#
mount -o remount,rw /

md1 wird nicht untersucht, weil swap-device. md0 wird immer gecheckt. md2 wird nur gecheckt, wenn ein Fehler vorlag. Allerdings dauert es dann schon eine Weile (bei mir so ca. 30 Minuten für 500GB-Raid), bis der Check durch ist und das System weiter macht. Man kann ja am Anfang diese Checks mit #-zeichen auskommentieren und sie erstmal übergehen, um zu sehen, wie es überhaupt geht.

Nachdem das System fertig ist, kann man die Protokoll-Datei /tmp/boot.log anschauen und sehen, was alles so gemacht wurde.

Die Ergebnisse in dieser Datei sind der Wirklichkeit am nächsten. Spätere Live-e2fsck -nv Prüfungen zeigen meist Fehler an, die nicht unbegdingt welche sein müssen, weil das ext3-Protokoll nicht mit in die Prüfung einbezogen wird. Sind also sozusagen unvollendete Transaktionen.

Falls Plattenfehler vorlagen, die mit Dateirekonstruktionen nur bedingt gerade gebogen werden konnten, findet man Restfragmente in den entsprechenden lost+found-Verzeichnissen.

 

[jahlives]

@itari
Ich habe das mal bei meiner alten DS106 probiert, aber wohl was falsch gemacht. Die DS ist nicht mehr hochgefahren und die Statuslampe blinkte wie wild. Habe sie zur Sicherheit 1 Tag laufen lassen und konnte dann nur noch den Strom ziehen.

Bevor ich das wieder probiere, möchte ich kurz fragen ob meine Vermutung auch mein Fehler war. Ich habe den fsck auf dem Device selber und nicht auf der Partition ausgeführt (also hda anstatt hda1). Kann es das gewesen sein? Wie kann es denn sein, dass fsck mit falschen Parametern nicht einfach -1 zurückgibt und rc weiter abgearbeitet wird? Ich frage dies nicht vorwurfsvoll (du hast ja sehr deutlich davor gewarnt), es nimmt mich einfach wunder warum der Bootvorgang nicht einfach forgesetzt wurde...

Zur Lösung des Problems habe ich die HD auf eine SATA-USB Dockingstation gesetzt und mit der heute gekauften ct das neuste Knoppix gestartet. Dann schnell die Änderungen in rc auskommentiert und die Platte wieder in die DS eingebaut. Flupps bootete das Teil wieder wie ne 1

Wäre es denn auch möglich fsck unter Knoppix auszuführen? Dann sollte es ja eigentlich weniger Probleme geben, weil / auch rw gemountet werden könnte. Ich werde das mal mit einer nicht Systempartition probieren...

Gruss

tobi

 

[itari]

Bevor ich das wieder probiere, möchte ich kurz fragen ob meine Vermutung auch mein Fehler war. Ich habe den fsck auf dem Device selber und nicht auf der Partition ausgeführt (also hda anstatt hda1). Kann es das gewesen sein? Wie kann es denn sein, dass fsck mit falschen Parametern nicht einfach -1 zurückgibt und rc weiter abgearbeitet wird? Ich frage dies nicht vorwurfsvoll (du hast ja sehr deutlich davor gewarnt), es nimmt mich einfach wunder warum der Bootvorgang nicht einfach forgesetzt wurde..

Es gibt da wohl ein grundsätzliches Verständigungsproblem: Ein File-System-Check geht nie auf Platten oder Partitionen, sondern immer auf Dateisysteme

Platte = physikalisches Medium (unter Linux /dev/hda)
Partition = Einteilung auf dem physikalischen Medium (unter Linux /dev/hda1)
File-System (Dateisystem) = Verwaltungsinformationen für die Nutzung einer Platte oder einer Partition (z. B. FAT32 oder NTFS oder etx3) (unter Linux auch /dev/hda1 oder bei RAID-1 /dev/md0)

Der fsck kann als nur auf File-Systeme losgelassen werden ... alles andere würde ja eine Intelligenz der Tools voraussetzen ... und das wollen wir ja nicht

Man kann die Skriptzeilen ein wenig entschärfen, indem man etwas Logik einbaut und die Fehler abfängt. Hatte das aber nicht eingebaut, weil ich das auch nicht testen wollte.

Man kann die Platte nicht nur am PC testen (Knoppix), sondern auch als externes Laufwerk an einer DS (wenn man eine 2. Systemplatte hat oder eine 2. DS geht das super).

Itari

 

[jahlives]

Habe es heute wie du geschrieben hast auf das Filesystem (testweise mal die eSata Disk) losgelassen und es hat wunderbar geklappt. Wurden ca 10 Fehler mit Verzeichnissen gefunden und anscheindend korrigiert.

Man kann die Skriptzeilen ein wenig entschärfen, indem man etwas Logik einbaut und die Fehler abfängt. Hatte das aber nicht eingebaut, weil ich das auch nicht testen wollte

Müsste ich mal ein bisschen rumprobieren...
Aber sehe ich das richtig, dass Fehler auf der Syspart nicht gefixed werden können weil / als ro gemounted ist?

 

[itari]

Aber sehe ich das richtig, dass Fehler auf der Syspart nicht gefixed werden können weil / als ro gemounted ist?

Probier doch mal auf ein rw-gemoutetes File-System einen korrigierenden fsck zu machen. Da bekommst den Hinweis, dass das nicht geht. Also entweder du muss das Dateisystem umounten oder auf ro setzen. Macht doch auch Sinn, denn ansonsten könnte ja während der Reparatur noch durch andere Programme was im Dateisystem modifiziert werden und das wäre ja nicht klug.

Itari

 

[udius]

*alte threads ausgrabend*

moin.

da ich gerade zum wiederholten male einen rsnapshot abbruch hatte, weil angeblich das filesystem voll sei (quotes nutze ich nicht!), dachte ich, es wäre ne gute idee, über /root und /volume1 einen fsck zu schicken.

hier die /tmp/bootlog.txt

DS207plus> more boot.log 
Tue Feb 14 17:37:41 CET 2012
e2fsck -pf /dev/md0 1.41.12-1636: 18188/155648 files (0.3% non-contiguous), 140685/622480 blocks
e2fsck -nv /dev/md0 1.41.12-1636: is cleanly umounted, 18188/155648 files, 140685/622480 blocks

e2fsck -p /dev/md2 /dev/md2: 
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

e2fsck -nv /dev/md2 
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

nun weiß ich nicht, was ich davon halten soll, denn wenn ich auf der shell ein fsck absetze geschieht folgendes:

DS207plus> type e2fsck
e2fsck is /sbin/e2fsck
DS207plus> e2fsck -nv /dev/md2 
e2fsck 1.41.12 (17-May-2010)
Warning!  /dev/md2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
1.41.3-0959 contains a file system with errors, check forced.

es gibt auch nur unter /sbin/ ein e2fsck

DS207plus> find / -xdev -name e2fsck -print
/sbin/e2fsck
DS207plus>

meine /etc/rc habe ich dann noch angehängt (bis auf den unveränderten itari-fsck-hack habe ich nix daran geändert).

zum schluss noch ein df

DS207plus> df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                2.4G  512M  1.8G  23% /
/dev/root             2.4G  512M  1.8G  23% /
/tmp                   62M  360K   62M   1% /tmp
/dev/md2              1.4T  830G  543G  61% /volume1

die offensichtlichen unterschiede sind:

1. auf der shell zeigt e2fsck seine versionnummer - im rc nicht. das liegt daran, dass die version nach stderr geschrieben wird, welches zwar von itari nach stdout umgelenkt wird, was aber anscheinend nicht im rc funzt
2. viel wichtiger: auf der shell kann e2fsck /dev/md2 mit den optionen -nv checken - im rc nicht

------------------------------
EDITH sagt: die returncodes für fscks von /dev/md0 sind 0 (NULL), die returncodes für die checks /dev/md2 sind 8(ACHT)
------------------------------

JUDITH fragt, ob sie statt /dev/md2 /dev/sda3 fscken soll oder ob sie da lieber die finger von lassen soll?

 

[udius]

ich habe dann doch lieber alle services gestoppt (bis auf sshd!) und dann

umount /dev/md0
e2fsck -f /dev/md2

gestartet, nachdem

e2fsck -nv /dev/md2

ergab, dass

e2fsck 1.41.12 (17-May-2010)
1.41.3-0959: is cleanly umounted, 16651/91381760 files, 223179370/365498800 blocks
 (check after next mount)

 

[jahlives]

hast du denn sichergestellt, dass die Dateisysteme nicht gemounted sind? Gemäss der Fehlermeldung von md2 ist da noch ein mount aktiv und dein df zeigt zumindest /volume1

 

[udius]

hast du denn sichergestellt, dass die Dateisysteme nicht gemounted sind? Gemäss der Fehlermeldung von md2 ist da noch ein mount aktiv und dein df zeigt zumindest /volume1

woran erkennst du aus der fehlermeldung, dass da noch ein mount aktiv ist? wie sollte es denn sein, der e2fsck geschieht weit vor der mounten der "user-filesysteme"?

und das df-kommando habe ich natürlich im multi-user-modus abgesetzt, da war natürlich /volume1 gemountet.

 

[jahlives]

woran erkennst du aus der fehlermeldung, dass da noch ein mount aktiv ist?

ich meinte diese Meldung:

DS207plus> e2fsck -nv /dev/md2 e2fsck 
1.41.12 (17-May-2010)Warning!  
/dev/md2 is mounted.Warning: skipping journal recovery because doing a read-only filesystem check. [LEFT][COLOR=#333333]1.41.3-0959 contains a file system with errors, check forced.[/COLOR][/LEFT]

 

[udius]

ich meinte diese Meldung:

DS207plus> e2fsck -nv /dev/md2 e2fsck 
1.41.12 (17-May-2010)Warning!  
/dev/md2 is mounted.Warning: skipping journal recovery because doing a read-only filesystem check. [LEFT][COLOR=#333333]1.41.3-0959 contains a file system with errors, check forced.[/COLOR][/LEFT]

jo, die ist ja wieder auf der shell im multiusermodus und diente nur zur veranschaulichung, dass sich e2fsck /dev/md2 im multiusermodus anders als zur /etc/rc-zeit verhält

 

[jahlives]

sorry aber ich verstehs noch nicht ganz ;-) Der e2fsck wird doch "anders" reagiert haben weil ein Dateisystem gemountet war, dann können keine Fehler korrigiert werden. Btw: eine Option kann es auch sein die Platten in eine PC einzubauen und dann ein Linux zu starten. Denn falls du irgendwann mal einen check mit Fehlerbehebung von der Syspart machen willst, geht das so oder so nicht auf der DS ;-)
Und manchmal kann es auch helfen den -f Parameter beim check zu verwenden, dann wird der check auch gemacht wenn das Volume an sich gut auschaut

 

[udius]

sorry aber ich verstehs noch nicht ganz ;-) Der e2fsck wird doch "anders" reagiert haben weil ein Dateisystem gemountet war, dann können keine Fehler korrigiert werden. Btw: eine Option kann es auch sein die Platten in eine PC einzubauen und dann ein Linux zu starten. Denn falls du irgendwann mal einen check mit Fehlerbehebung von der Syspart machen willst, geht das so oder so nicht auf der DS ;-)
Und manchmal kann es auch helfen den -f Parameter beim check zu verwenden, dann wird der check auch gemacht wenn das Volume an sich gut auschaut

es ging mir darum, dass der e2fsck gleich mit einem "operational error" (return code 8) aufhört, wenn man zur /etc/rc-zeit versucht, dev/md2 zu checken, während zur multiuser-zeit der e2fsck zumindest anfängt.

klar, dass da andere meldungen kommen, aber darum ging es nicht.

ich glaube, dass ich auch verstehe, warum es so ist. es gibt wohl zu der zeit noch kein /dev/md2 sondern nur /dev/sda3. als itari den hack schrieb, war es anscheinend anders.

aber egal: ich habe ja im multiuser-modus alle services, die irgendwie auf /dev/md2 (/volume1) herumhühnern, stoppen können, so dass ich dann /dev/md2 fsck-en (mit -f) konnte.

ergebnis: alles ok

bezüglich fehlern auf /dev/md0 haste natürlich recht, aber die war ja sauber

 

[itari]

Denn falls du irgendwann mal einen check mit Fehlerbehebung von der Syspart machen willst, geht das so oder so nicht auf der DS ;-)

wenn ein Dateisystem ro ist, kannst es per fsck korrigieren

Itari

 

[Deepbluesee]

leider kommt bei mir folgende Fehlermeldung:

1 logical volume(s) in volume group "vg1000" now active
sh-4.3# fsck.ext4 -pvf -C 0 /dev/vg1000/lv
fsck.ext4: Bad magic number in super-block while trying to open /dev/vg1000/lv
/dev/vg1000/lv:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

Was mach ich falsch?

 

[kev.lin]

Der Thread ist 7 (!) Jahre alt. Ohne mich damit detailiert beschäftigt zu haben, vermute ich, dass sich an den Bedingungen (DSM) einiges geändert hat.

 

[Deepbluesee]

Ja 7 Jahre alt ist richtig aber an dem Unix unter dem DSM hat sich fast nix getan, sieht man auch gut an der Version der Shell.