e2fsck repariert nicht dauerhaft
Juergen Naumann
Ich habe nun schon zum dritten mal Probleme mit meiner
Festplatte. Vermutlich komme ich um einen Neukauf nicht herum,
würde aber trotzdem gerne verstehen was passiert.
Ich habe auf der ersten primären Partition Windows XP, auf der
erweiterten /dev/hda7 (mit ReiserFS) SUSE Linux 8.2 und auf
/dev/hda5 (mit ext3) die /home Verzeichnisse. Gestern starteten
sowohl XP (die Registry in windows/system32/config/system wurde
als korrupt gemeldet) als auch Linux nicht mehr. Die Windows
Registry habe ich leider erfolglos versucht, mit einer Knoppix-CD
und den Tips aus einer kürzlich erschienenden c't zu reparieren.
Nun zu meinem eigentlichen Problem: Linux startet nicht, da fsck
einen Fehler meldet. Ich kann mich nach dem abgebrochenen boot-
Vorgang als root einloggen und finde heraus, daß es auf
/dev/hda5 einen defekten Superblock gibt. Den habe ich mit
e2fsck -b 32768 /dev/hda5 repariert, den Rechner mit Strg+D
rebootet und -voila- ich konnte mich einloggen. Leider trat das
Problem nach dem nächsten reboot wieder auf und konnte auf die
gleiche Weise wieder gelöst werden. Ich habe den Verdacht, daß
das Problem durch das unmounten der Partition ausgelöst wird,
denn ich habe nach erfolgreichem Hochfahren als root
umount /dev/hda5 ausgeführt und ein fsck auf diese Partition
losgelassen und habe wiederum die Meldung mit dem defekten
Superblock bekommen und konnte es mit e2fsck wieder beheben.
Hat jemand eine Ahnung, was da passiert? Vielleicht auch (obwohl
hier OT) warum Linux und Windows (übringens zum 3. Mal in den
letzten 6 Monaten) gleichzeitig den Geist aufgeben?
Danke vorab und freundlichen Grüße,
Jürgen Naumann
Jochen Schulz
>
> Nun zu meinem eigentlichen Problem: Linux startet nicht, da fsck
°°°°°°°°°°°°°°°°°°°
> einen Fehler meldet. Ich kann mich nach dem abgebrochenen boot-
°°°°°°°°°°°°°
> Vorgang als root einloggen
<korinthenkack>
Nur so nebenbei: die unterkringelten Aussagen werden von einigen
hier wohl als widersprüchlich angesehen. Wenn Du Dich einloggen kannst,
wurde Linux auch gestartet.
</>
> und finde heraus, daß es auf
> /dev/hda5 einen defekten Superblock gibt. Den habe ich mit
> e2fsck -b 32768 /dev/hda5 repariert,
Mit ein bißchen Pech ist genau der Bereich der Platte kaputt, wo der
superblock eigentlich hingehört. Vielleicht ist das hier interessant:
http://smartmontools.sourceforge.net/BadBlockHowTo.txt
> [nach Reboot wiederholt bad blocks gefunden]
>
> Hat jemand eine Ahnung, was da passiert? Vielleicht auch (obwohl
> hier OT) warum Linux und Windows (übringens zum 3. Mal in den
> letzten 6 Monaten) gleichzeitig den Geist aufgeben?
Naja, wenn die Platte kaputt ist, auf der beide Systeme liegen, dann
wundert das nicht. Und die vorigen zwei Male könnten Warnzeichen einer
langsam sterbenden Platte sein. Sowas kann sich hinziehen.
Wenn Deine Platte nicht zu alt ist (sie muß S.M.A.R.T unterstützen),
installier Dir mal die smartmontools (s. obiger Link). Mit
|# smartctl -t long /dev/hdX
kannst Du einen Check der Platte (nicht des Dateisystems) im laufenden
Betrieb durchführen. Das Ergebnis siehst Du mit
|# smartctl -l selftest /dev/hdX
Mit im Paket ist auch ein Daemon, der regelmäßig Checks durchführt und
Warnhinweise im syslog oder per Mail ausgeben kann. Könnte man aber auch
per cron regeln.
Wenn es eine Maxtor-Platte ist, besorge Dir PowerMax von deren Webseite.
Das ist eine Bootdiskette (nur unter Windows zu erstellen...), mit der
Du verschiedene Tests (auch destruktive!) durchführen kannst.
J.
--
I use a Playstation to block out the existence of my partner.
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Dietrich Schaffer
[...]
> Mit ein bißchen Pech ist genau der Bereich der Platte kaputt, wo der
> superblock eigentlich hingehört. Vielleicht ist das hier interessant:
> http://smartmontools.sourceforge.net/BadBlockHowTo.txt
Für ext2 -> man badblocks
....
AVAILABILITY
badblocks is part of the e2fsprogs package and is avail-
able from http://e2fsprogs.sourceforge.net.
Für ext3 und reiserfs weiß ich es nicht - aber Du schreibst ja e2fsck.
> J.
Servus,
Dietrich
Jochen Schulz
> Jochen Schulz <kannst...@gmx.net> wrote:
>
> [...]
>
>> Mit ein bißchen Pech ist genau der Bereich der Platte kaputt, wo der
>> superblock eigentlich hingehört. Vielleicht ist das hier interessant:
>> http://smartmontools.sourceforge.net/BadBlockHowTo.txt
>
> Für ext2 -> man badblocks
> ....
> AVAILABILITY
> badblocks is part of the e2fsprogs package and is avail-
> able from http://e2fsprogs.sourceforge.net.
Wobei in derselben manpage geraten wird, das Programm nicht selbst
direkt aufzurufen, sondern über mke2fs. Ich habe die von mir genannte
Anleitung eigentlich auch so verstanden, daß das normalerweise
automatisch passieren sollte. Aber man kann es eben auch von Hand
forcieren.
> Für ext3 und reiserfs weiß ich es nicht - aber Du schreibst ja e2fsck.
ext3 ist ext2 mit Journal. e2fsck kann auch ext3.
J.
--
If you do not move for long enough, you might see a rat.
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Michael Baeuerle
>
> [...]
> Nun zu meinem eigentlichen Problem: Linux startet nicht, da fsck
> einen Fehler meldet. Ich kann mich nach dem abgebrochenen boot-
> Vorgang als root einloggen und finde heraus, daß es auf
> /dev/hda5 einen defekten Superblock gibt. Den habe ich mit
> e2fsck -b 32768 /dev/hda5 repariert, den Rechner mit Strg+D
Bist du sicher, dass du weisst was du da getan hast? Ich bin kein ext2
Experte, aber meine e2fsck man page sagt folgendes zu "-b":
| -b superblock
| Instead of using the normal superblock, use an
| alternative superblock specified by superblock.
| This option is normally used when the primary
| superblock has been corrupted; most filesystems
| have primary superblocks located at blocks 8193,
| 16385, etc.
Das System das ich darin erkenne ist, dass Superblocks immer auf den
Adressen (2^n)+1 mit n>12, also immer auf ungeraden Adressen liegen. Das
trifft auf 32768 nicht zu. Nach obiger Formel waere es (2^15)+1), also
32769. Meine Vermutung geht dahin, dass e2fsck auf 32768 keinen
gueltigen Superblock gefunden hat und stattdessen mit den Daten des
beschaedigten nur zu retten versucht hat was eben moeglich war ...
> rebootet und -voila- ich konnte mich einloggen. Leider trat das
> Problem nach dem nächsten reboot wieder auf und konnte auf die
> gleiche Weise wieder gelöst werden. Ich habe den Verdacht, daß
> das Problem durch das unmounten der Partition ausgelöst wird
Hast du mal versucht einen normalen fsck -f (also ohne "-b") *direkt
danach*, also vor mount/umount auszufuehren um zu sehen ob es ueberhaupt
erfolgreich war? Der reboot direkt nach dem Check ging natuerlich, weil
das FS clean gesetzt war und nach dem reboot nicht gecheckt wurde. War
es aber immer noch fehlerhaft (weil fsck versagt hat) merkt er nach dem
mount, dass was nicht stimmt und setzt das error flag => Steht beim
naechsten reboot wieder.
Micha
P.S.: Das soll alles natuerlich nicht davon ablenken, dass mit grosser
Wahrscheinlichkeit deine Platte gerade am sterben ist!
--
Eine Konstruktion, die gehorsame_Elektronen(tm) benoetigt ;-/
"Gehe bis zur naechsten Ecke, warte dort 0,5s und fliege dann
weiter ..."
Oliver Bartels in de.sci.electronics
King Leo - Martin Oberzalek
> Juergen Naumann wrote:
>>
>> [...]
>> Nun zu meinem eigentlichen Problem: Linux startet nicht, da fsck
>> einen Fehler meldet. Ich kann mich nach dem abgebrochenen boot-
>> Vorgang als root einloggen und finde heraus, daß es auf
>> /dev/hda5 einen defekten Superblock gibt. Den habe ich mit
>> e2fsck -b 32768 /dev/hda5 repariert, den Rechner mit Strg+D
>
> Bist du sicher, dass du weisst was du da getan hast? Ich bin kein ext2
> Experte, aber meine e2fsck man page sagt folgendes zu "-b":
>
> | -b superblock
> | Instead of using the normal superblock, use an
> | alternative superblock specified by superblock.
> | This option is normally used when the primary
> | superblock has been corrupted; most filesystems
> | have primary superblocks located at blocks 8193,
> | 16385, etc.
>
> Das System das ich darin erkenne ist, dass Superblocks immer auf den
> Adressen (2^n)+1 mit n>12, also immer auf ungeraden Adressen liegen.
Nicht vermuten, sondern nachschauen wo ein neuerliches mkfs.ext2 die
Superblöcke schreiben würde: man mkfs.ext2
-n causes mke2fs to not actually create a filesystem, but display what
it would do if it were to create a filesystem. This can be used
to determine the location of the backup superblocks for a particular
filesystem, so long as the mke2fs parameters that were passed
when the filesystem was originally created are used again. (With
the -n option added, of course!)
Gruß, Martin!
--
Das ist keine fehlerhafte Rechtschreibung, sondern .. aehm.. modifizierte
Huffmann Codierung. Nur weil du das nicht lesen kannst ist es nicht
falsch! :)
Szomraky Stefan in at.linux
Michael Baeuerle
>
> Michael Baeuerle wrote:
>
> [e2fsck Auszug]
> > Das System das ich darin erkenne ist, dass Superblocks immer auf den
> > Adressen (2^n)+1 mit n>12, also immer auf ungeraden Adressen liegen.
Scheinbar etwas voreilig: Diese Aussage trifft offenbar nur zu, wenn
Blocksize=1024Byte (und das "sparse_super" Flag gesetzt ist). Bei
Blocksizes von 2048 bzw. 4096 haben meine Superblocks geradzahlige
Adressen die z.T. auch keine Zweierpotenzen sind ... waere ja auch zu
einfach gewesen :-(
> Nicht vermuten, sondern nachschauen wo ein neuerliches mkfs.ext2 die
> Superblöcke schreiben würde: man mkfs.ext2
> [...]
Das geht halt nur wenn man noch weiss, mit welchen Parametern man das FS
damals erzeugt hat ... wird idR aber nicht der Fall sein.
Man kann aber pruefen ob sich an einer bestimmten Stelle ein gueltiger
Superblock befindet (An Adresse 0 befindet sich offenbar immer der
"Haupt"-Superblock):
dumpe2fs -h -ob<superblock> /dev/<device>
Dass es im konkreten Fall nicht trivial ist die Superblock Backups zu
finden, zeigt folgendes Beispiel:
Von meinem lokalen root-FS kenne ich z.B. Blocksize, Groesse und Flags
(keine Ahnung mit welchen Parametern genau ich es vor Jahren angelegt
habe bzw. anlegen habe lassen):
----------------------------------------------------------------------
[root@WStation3:/tmp]# dumpe2fs -h -ob0 /dev/sda1
...
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
...
Block count: 240021
...
First block: 0
Block size: 4096
Fragment size: 4096
...
----------------------------------------------------------------------
Lasse ich jetzt mke2fs ein FS gleicher Blocksize und Groesse erzeugen,
sieht das so aus:
----------------------------------------------------------------------
[root@WStation3:/tmp]# touch FStest
[root@WStation3:/tmp]# losetup /dev/loop0 ./FStest
[root@WStation3:/tmp]# mke2fs -n -b 4096 /dev/loop0 240021
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
120064 inodes, 240021 blocks
12001 blocks (5.00%) reserved for the super user
First data block=0
8 block groups
32768 blocks per group, 32768 fragments per group
15008 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
----------------------------------------------------------------------
Wenn ich jetzt auf meinem root-FS nach diesen Superblock Backups suche,
ist keiner der obigen gueltig.
----------------------------------------------------------------------
[root@WStation3:/tmp]# dumpe2fs -h -ob32768 /dev/sda1
dumpe2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda1
Couldn't find valid filesystem superblock.
... (die anderen 3 ebenfalls ungueltig)
----------------------------------------------------------------------
Gegenprobe mit kleinerem 10MiByte FS (Platte recht voll):
----------------------------------------------------------------------
[root@WStation3:/tmp]# losetup -d /dev/loop0
[root@WStation3:/tmp]# dd if=/dev/zero of=./FStest bs=1024 count=10240
10240+0 records in
10240+0 records out
[root@WStation3:/tmp]# losetup /dev/loop0 ./FStest
[root@WStation3:/tmp]# mke2fs /dev/loop0
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
2560 inodes, 10240 blocks
512 blocks (5.00%) reserved for the super user
First data block=1
2 block groups
8192 blocks per group, 8192 fragments per group
1280 inodes per group
Superblock backups stored on blocks:
8193
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
[root@WStation3:/tmp]# dumpe2fs -h -ob0 /dev/loop0
dumpe2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
...
Filesystem features: filetype sparse_super
...
[root@WStation3:/tmp]# dumpe2fs -h -ob8193 /dev/loop0
dumpe2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
... (funktioniert)
----------------------------------------------------------------------
Die Flags stimmen ueberein, daran liegt es also nicht.
Fazit: Mit "mke2fs -n" habe ich nicht herausgefunden wo meine Superblock
Backups sind.
Micha
Juergen Naumann
> Juergen Naumann wrote:
>>
>> [...]
>> Nun zu meinem eigentlichen Problem: Linux startet nicht, da fsck
>> einen Fehler meldet. Ich kann mich nach dem abgebrochenen boot-
>> Vorgang als root einloggen und finde heraus, daß es auf
>> /dev/hda5 einen defekten Superblock gibt. Den habe ich mit
>> e2fsck -b 32768 /dev/hda5 repariert, den Rechner mit Strg+D
>
> Bist du sicher, dass du weisst was du da getan hast? Ich bin kein ext2
> Experte, aber meine e2fsck man page sagt folgendes zu "-b":
>
> | -b superblock
> | Instead of using the normal superblock, use an
> | alternative superblock specified by superblock.
> | This option is normally used when the primary
> | superblock has been corrupted; most filesystems
> | have primary superblocks located at blocks 8193,
> | 16385, etc.
>
> Das System das ich darin erkenne ist, dass Superblocks immer auf den
> Adressen (2^n)+1 mit n>12, also immer auf ungeraden Adressen liegen. Das
> trifft auf 32768 nicht zu. Nach obiger Formel waere es (2^15)+1), also
> 32769. Meine Vermutung geht dahin, dass e2fsck auf 32768 keinen
> gueltigen Superblock gefunden hat und stattdessen mit den Daten des
> beschaedigten nur zu retten versucht hat was eben moeglich war ...
Ich habe den Wert verwendet, den fsck mir vorgeschlagen hat. Immerhin hat
damit die kurzzeitige Rekonstruktion des Filesystems funktioniert. Nein,
wirklich gewußt, was ich da tat, habe ich zu diesem Zeitpunkt nicht. :-/
> P.S.: Das soll alles natuerlich nicht davon ablenken, dass mit grosser
> Wahrscheinlichkeit deine Platte gerade am sterben ist!
Herzlichen Dank für Eure zahlreichen Tips. Als erstes habe ich letzteren
beherzigt und mir eine neue Platte gekauft, auf die ich die Daten herüber-
gerettet habe. Da der Rechner erst 1,5 Jahre alt ist, wird die alte Platte
über den Händler eingeschickt und kehrt hoffentlich brauchbar zurück. Und
den zusätzlichen Plattenplatz kann ich gut gebrauchen.
Viel gelernt hat hier
Jürgen