Ein ext3 Filesystemfehler ist keine witzige Angelegenheit. Nachdem die HDD wieder als r/o (read-only) gemountet wurde kann man mit dem System nicht mehr viel anfangen, vor allem wenn es die Root-Partition betrifft .
Bei einem Server ist das natürlich problematischer als bei einem Desktoprechner, denn der Server muss in einer SecureShell gestartet werden, was eigentlich jeder Hoster anbietet. Bei dem Desktoprechner kann man einfach eine LiveCD einlegen um ein Linux-System zu booten.

Das System ist in einer SecureShell gebootet – ist nicht das eigentliche System auf der Platte, sondern ein Networkimage das bereitgestellt wird von dem Hoster – und man kann anfangen nach Fehlern zu suchen.
Nach meiner Erfahrung ist der häufigste Fehler ein Hardwaredefekt.

Reparatur

Falls es überhaupt noch möglich ist, ist es zunächst nötig sich einmal alle Partitionen auflisten zu lassen.

myhost:~>fdisk -l

Disk /dev/sda: 999.1 GB, 999116767232 bytes
255 heads, 63 sectors/track, 121469 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0×00017515

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 97656 83 Linux
/dev/sda2 13 137 1000000 82 Linux swap / Solaris
/dev/sda3 137 115842 929402344 83 Linux

Wie zu sehen ist, wird eine Liste der einzelnen Partitionen, Typen, Zylinder usw. auf den Festplatten dargestellt.
Wie unschwer zu erkennen ist, wird die 3. Partition /dev/sda3 also root-Partition verwendet und genau diese Partition soll nun überprüft werden.

myhost:~>fsck /dev/sda3

Es wird nun eine komplette Prüfung des Dateisystems vorgenommen. Falls fsck das Dateisystem nicht erkennt, kann dieses mit der Option -t mit übergeben werden.
Es werden einige Fehler erscheinen und es wird gefragt ob diese behoben werden sollen. Dies ist mit y beantworten.
Alternativ hierzu kann man auch zugleich die Option -a mit übergeben, denn dann wird alles automatisch bestätigt.

In den häufigsten Fällen sind es falsche oder fehlerhafte I-Node-Einträge. Diese werden repariert und die Dateien, die an dieser I-Node hingen, landen in dem Ordner lost+found.
Nachdem die Reperatur abgeschlossen ist, steht der Reboot an, mit dem man wieder in das eigentliche System bootet.

Fehleranalyse

Eine Fehleranalyse ist immer schwierig, vor allem wenn es um Hardwarekomponenten geht. Es gibt von manchen Herstellern Tools, womit man Ihre Hardware testen kann. Auch Herstellerunabhängige Tools gibt es zu genüge.
Ein solches Tool, speziell für Festplattenchecks, ist SMART . Das dazugehörige Paket heißt smartmontools.

Als erstes muss natürlich das Paket aus den Paketquellen mit den Abhängigkeiten installiert werden.
Nun kann das Testen los gehen. Man wählt als erstes die HDD aus die man prüfen will, nicht die Partition !!! (s.o.).

myhost:~>smartctl –test=long /dev/sda

Genauere Einstellungen zu den verschiedenen Testmechanismen kann man in der der Manual nachlesen.

Den Status des Tests kann man mit

myhost:~>smartcl –all /dev/sda

abfragen.
Es kann einige Zeit vergehen bis der Test durchgelaufen ist. Das oben beschriebenen Kommando beschreibt nicht nur den Status des Tests sondern die Fehler die aufgetreten sind.

ACHTUNG!!!
Sollte eine solche Meldung auftauchen,

Device type: disk
Local Time is: Thu Nov 5 12:15:56 2009 CET
Device does not support SMART

kann die Festplatte nicht mit SMART überprüft werden. Dann muss das Tool des Herstellers genommen werden.

Alles was nun beschrieben wurde, trifft genauso auch auf den Desktoprechner zu, mit der Ausnahme, das die SecureShell eine LifeCD ist auf der man ein Terminal startet.

Tags: ext3, fdisk, fsck, howtoo, smart, smartctl, tutorial

This entry was posted on Donnerstag, November 5th, 2009 at 12:28 pm and is filed under Linux. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.