Fehlersuche nach Server down / UNEXPECTED INCONSISTENCY

[svenjalell]

Hi,

auf einem Dell Server betreibe ich seit mehreren Jahren mehrere VMs.
Die Virtualisierung erfolgt durch ESXi. Auf dem VMs läuft Debian 9.

Jetzt ist eine VM abgeraucht. In der Gui vom ESXi konnte ich auf der Server Console
der betreffenden VM folgendes lesen:

/dev/sda1 contains a file system with errors, check forced.
/dev/sda1:
Inodes that were part of a corrupted orphan linked list found.

/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., withouth -a or -p options)

fsck exited with status code 4

The root filesystem on /dev/sda2 requires a manual fsck

BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)

enter 'help' for a list of built-in commands:

(initramfs)

OK im initramfs konnte ich dann einen Filecheck ausführen

fsck /dev/sda1

Dann kam die Meldung ähnlich wi:

FILE system modified

/..: *****FILE SYSTEM WAS MODIFIED *****
/..1: 265804/30334976 files (0,2% non-contiguous), 3947627/121315840 blocks
(initramfs)

Danach bootete das System wieder ordungsgemäß.


Das gabs es allerdings schon mal. Ich brauche hier Hilfe um auf Fehlersuche zu gehen.
Log-tehnisch habe ich unter "/var/log/fsck/checkfs" oder "/var/log/fsck/checkroot" nichts
gefunden, da die Files veraltet sind. "/run/initramfs/fsck.log" ist von heute, enthält aber
lediglich:

Log of fsck -C -a -T -t ext4 /dev/sda1
Thu May 14 06:46:31 2020

/dev/sda1: clean, 863943/26083328 files, 67819199/104333312 blocks

Thu May 14 06:46:31 2020
----------------
fsck.log (END)

Grundsätzlich frage ich mich, ob es an Hard- oder Software liegt. Der Server läuft seit
2015.Es sind HDDs verbaut.

Habe ich die Möglichkeit fsck mit debug oder log - Optionen etwas sprechender zu machen
um sodann sda1 zu unmounten und das Device nach mal mit fsck zu checken.

Es geht mir also um Ursachenforschung und Beheben des Probs.

Vielen Dank für eure Hilfe

VG
Svenja

[DeletedUserReAsG]

Grundsätzlich frage ich mich, ob es an Hard- oder Software liegt.

Grundsätzlich ist beides möglich.

Habe ich die Möglichkeit fsck mit debug oder log - Optionen etwas sprechender zu machen
um sodann sda1 zu unmounten und das Device nach mal mit fsck zu checken.

Natürlich. Es gibt zu dem Programm ’ne ziemlich gute Anleitung, aufzurufen mit man fsck.

OT: seit wann hat das initramfs eines Debians eine Buntu-Kennung?

[pferdefreund]

Kann auch defektes RAM sein. Hatte auch mal angeblich Plattenfehler und nach dem Austausch des RAMs war wieder alles OK. Einfach mal bei der betreffenden Platte eine große Zip-Datei erstellen - das ganze dann noch mal unter einem anderen Namen und dann ein diff darauf loslassen. (binär). Mit etwas Glück kommt dann das Aha-Erlebnis.
badblocks auf die entsprechende Platte wäre dann auch noch eine Alternative.

[svenjalell]

Hallo Pferdefreund,

... habe mal zwei zips (foo.gz & foo1.gz / Größe 1.3 GB) auf dieselbe Art gebaut . Die sind aber gleich:
# cmp foo.gz foo1.gz && echo "identical" || echo "different"
identical


oder sind 1.3 GB noch zu klein ? Wie würde ich die bad blocks sehen ?

VG

Svenja

[svenjalell]

Hi niemand,

vielen Dank...
... wie man fsck loggt erschließt sich mir nicht. Da stets auch nichts in der manpage.
Da hatte ich als erstes reingeguckt.

Es muß aber möglich sein, da bei jedem neuen Boot das "initramfs" durchlaufen wird,
was filecheck logs in "/run/initramfs/fsck.log" anlegt.

Dort steht:


Log of fsck -C -a -T -t ext4 /dev/sda1
Fri May 15 09:24:46 2020

/dev/sda1: clean, 663010/32702464 files, 116668270/130809600 blocks

Fri May 15 09:24:46 2020
----------------

Vieleicht muß irgendeine Umgebungsvariable gesetzt werden. ... keine Ahnung.
In jedem Fall scheint das Filesystem clean zu sein.

Ich würde natürlich trotzdem gerne ein Filecheck machen wollen.

"df -h" liefert:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
udev 2,0G 0 2,0G 0% /dev
tmpfs 396M 5,5M 391M 2% /run
/dev/sda1 491G 437G 29G 94% /
tmpfs 2,0G 0 2,0G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 2,0G 0 2,0G 0% /sys/fs/cgroup
tmpfs 396M 0 396M 0% /run/user/1000
#

Um auf "/dev/sda1" ein filecheck zu machen, müßte man es erstmal unmounten

"umount /dev/sda1" liefert (glücklicherweise):

umount: /: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)


Könnt ihr mir hier sagen, wie ich hier vorgehen muß , um auf "/dev/sda1"
einen filecheck machen zu können ?
lsof liefert tons of information... weiß grad nicht, wie es geegnet
eingrenzen kann.

Starthilfe wäre nochmal nett !

VG

Svenja

[bluestar]

Macht wirklich nur eine VM Probleme oder auch noch andere?

Was für ein Storage hast du unter dem ESXi laufen?

Zur Sicherheit würde ich den physikalischen Server einmal runterfahren, mit ner LiveCD/Stick booten und darüber den Memtest laufen lassen.

Danach würde ich im ESXi das Storage prüfen lassen und erst danach würde ich mich bei der Fehlersuche in die VM begeben.