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
> 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,
> 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.
> 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.
> [...] > 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
>> [...] >> 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
> [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
Die Flags stimmen ueberein, daran liegt es also nicht. Fazit: Mit "mke2fs -n" habe ich nicht herausgefunden wo meine Superblock Backups sind.
Micha -- 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
Michael Baeuerle <michael.baeue...@gmx.net> wrote: > 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.