[Gelöst] Unmotivierte Systemabstürze (CentOS)

[gehrke]

Moin *,

ich scheine hier ein fieses Problem mit Abstürzen auf meinem Server (CentOS 6.2) zu bekommen. Heute zum zweiten Mal in einer Woche fehlen jegliche Netzwerkdienste und bei der lokalen Anmeldung lande ich in einer rudimentären Umgebung (busybox?). Siehe Screenshot:

Als es beim bisher einzigen Mal zuvor passiert ist, habe ich das System neu gebootet und in den Logs nach Fehlern/Hinweisen gesucht, bin aber nicht fündig geworden. Der letzte Eintrag war ein beliebiger DHCP-Eintrag, erst Stunden später dann etwas vom Reboot. Details habe ich in meinem Wiki vermerkt, dass ist aber auch auf dem Server und der ist derzeit kaputt.

Es handelt sich um einen Server von 2011 mit CentOS 6.2. Bislang machte die Hardware keine Probleme im 24x7-Betrieb.

Konfiguration:
md0: RAID1 (md-adm) für /boot
md1: RAID6 mit 6 Disks (md-adm)

Letzte bekannte Aktivität war ein Full-Backup als Bacula-Server innerhalb eine VM (KVM) über mehrere Tage, also hohe Last.

Derzeit befindet sich das System noch in diesem Zustand. Ich vermute, dass ich kaum mehr relevante Informationen nach einem Reboot bekommen werde. Kann ich jetzt noch etwas aus diesem Systemzustand herauskitzeln, bevor ich durchstarte???
TNX

cu, gehrke

 

[marce]

Die Fehlerbeschreibung deutet auf defekte Hardware (ich tippe auf Speicher, Netzteil oder CPU / Board - in der Reihenfolge) hin.

 

[josef-wien]

fehlen jegliche Netzwerkdienste

Screenshot: unable to mount rootfs

Das ist für mich ein Widerspruch. Nachdem ich /dev/mapper/... sehe, muß übrigens mehr als mdadm im Spiel sein.

Ohne Systempartition gibt es keine Log-Dateien. Falls dmesg in der initrd enthalten ist, sehe ich das als einzige Chance.

Unmotivierte Systemabstürze

Da könnte marce richtig liegen.

 

[gehrke]

@marce: Woran erkennst Du das???
Bei den FS-Checks vermute ich, dass es Inkonsistenzen infolge des Absturzes gibt. Aber die Ursache?

 

[gehrke]

fehlen jegliche Netzwerkdienste

Screenshot: unable to mount rootfs

Das ist für mich ein Widerspruch. Nachdem ich /dev/mapper/... sehe, muß übrigens mehr als mdadm im Spiel sein.

Inwiefern ein Widerspruch?

Ja, da ist mehr dahinter. Auf dem RAID md1 liegt ein LUKS-Container und darin eine LVM-Partitionierung. Das habe ich in der ersten Beschreibung nicht für relevant gehalten, weil schon das RAID nicht gefunden wird.

 

[marce]

@marce: Woran erkennst Du das???

Ganz einfach - Fehlerbild / Beschreibung und ca. 20 Jahre Erfahrung in PC und Server-Technik.

Ja, zugegeben - Garantie ist das keine, da würde ich aber zumindest mit suchen anfangen...

 

[josef-wien]

Inwiefern ein Widerspruch?

Wenn es keine Systempartition gibt, können nicht bloß "jegliche Netzwerkdienste fehlen", dann ist gar nichts vorhanden.

Bei den FS-Checks vermute ich, dass es Inkonsistenzen infolge des Absturzes gibt.

Die Fehlermeldung ist der 08/15-Text, entscheidend ist die Aussage, daß es die Systempartition gar nicht gibt.

 

[gehrke]

Zwei Dinge habe ich am System geändert, bevor das Problem erstmals auftrat:
*ntp in der bacula-VM aktiviert
*Eine neue Festplatte als Backup-Ziel eingebaut. Diese wird an die VM weitergereicht.

 

[marce]

ok, an der Hardware rumgebastelt und hinterher tut nichts mehr? Die Info hätte auch früher kommen können...

Wie ist denn die neue HD reingekommen? HotSwap oder rumgeschraubt? Konfiguration der restlichen HDs über dev, UUID, Label, ...? Was sagt das BIOS zu allen beteiligten HDs? Reihenfolge identisch? Neue HD am gleichen Controller oder IDE / SATA / SCSI gemischt? ...?

 

[gehrke]

Inwiefern ein Widerspruch?

Wenn es keine Systempartition gibt, können nicht bloß "jegliche Netzwerkdienste fehlen", dann ist gar nichts vorhanden.

Das ist dann ein Missverständnis.
Mit "jegliche Netzwerkdienste fehlen" war das erste Symptom gemeint. Demnach habe ich mich lokal an das System gesetzt und die Meldungen aus dem Screenshot gesehen.

 

[gehrke]

ok, an der Hardware rumgebastelt und hinterher tut nichts mehr? Die Info hätte auch früher kommen können...

Ich plädiere für mildernde Umstände, Euer Ehren.
Kann schon sein dass ich heute nicht mehr der Schnellste bin - und eine frische HD als neues Backupmedium ist nicht wirklich so etwas ungewöhnliches, dass es augenfällig sein müsste. Das passiert im monatlichen Wechsel.

Wie ist denn die neue HD reingekommen? HotSwap oder rumgeschraubt? [...] Neue HD am gleichen Controller oder IDE / SATA / SCSI gemischt? ...?

Neustart. Es gibt einen unabhängigen Controller für die Backup-Festplatten, welcher bislang aber nicht zu solchen Effekten geführt hat. Das ganze läuft schon geraume Zeit, nur gab es für Mai eine neue Festplatte ohne Probleme und für Juni ein weitere neue, beide identischer Typ.

 

[josef-wien]

Eine zusätzliche Platte sollte keine Auswirkungen auf die RAID-Definitionen haben. Gibt es eine Ausgabe bei:

mdadm -AsR

 

[gehrke]

Eine zusätzliche Platte sollte keine Auswirkungen auf die RAID-Definitionen haben.

Zumal diese Platte nicht Bestandteil irgendeines RAIDs ist.

Gibt es eine Ausgabe bei:

mdadm -AsR

Nein. Keine Ausgabe.

Mal unabhängig von der konkreten Ursache - was wird der Grund für den aktuellen Systemzustand sein?
In meiner laienhaften Vorstellung ist es ein mögliches Szenario, dass es aus irgendeinem Grund im laufenden Betrieb zu einem Absturz kam (ob dabei noch Logs geschrieben wurden, kann ich erst feststellen, wenn das System wieder voll gebootet ist. Beim letzten Mal habe ich leider nichts gefunden).
Es folgt ein automatischer Neustart, der aber scheitert, weil
A: entweder beim Absturz Meta-Informationen für das RAID verloren gegangen sind
B: schlicht niemand da war, der die Passphrase für den LUKS-Container eingegeben hat und es zu einem Timeout kam. In diesem Fall wäre mir aber unklar, warum nicht wenigstens das RAID md1 angezeigt wird.
Dieses Scheitern bringt mich dann auf die busybox.

Ist das plausibel?
TNX

 

[josef-wien]

Die Informationen über das RAID sind auf allen beteiligten Platten vorhanden. Ich kann mir keinen Systemabsturz vorstellen, bei dem alle diese Informationen in Mitleidenschaft gezogen werden.

Ich interpretiere

Auf dem RAID md1 liegt ein LUKS-Container und darin eine LVM-Partitionierung.

so, daß zuerst das RAID6 aufgebaut wird und danach Entschlüsselung und LVM-Aufbau erfolgen. Bei dieser Interpretation hätte ich eine Ausgabe des mdadm-Befehls erwartet, das Schweigen deutet üblicherweise an, daß nichts zu tun ist. Durch die Anzahl der Platten und die Zeilenbegrenzung des Bildschirms wird der zusätzliche Parameter -v (dann kommen sehr viele Zeilen) wahrscheinlich auch nicht weiterhelfen.

Nachdem ich den init-Prozeß Deiner initrd nicht kenne (bei openSUSE war er schon vor systemd ziemlich komplex, bei PCLinuxOS (das nash verwendet) besteht er in meiner Variante einschließlich echo-Anweisungen aus 61 Befehlen), habe ich keine Ansatzpunkte.

 

[Geier0815]

Ich bin so gut wie überhaupt nicht in CentOS drin aber ein paar Dinge: Die Screenshots zeigen einen Rechner der neu gebootet wurde. Der Rechner findet irgendwelche Devices nicht. Der Rechner verfällt dann in eine Notfall-Shell, also nix busybox sondern aus der initrd heraus.
Du hast mindestens zwei Controller verbaut.
Nun kommen die doofen Fragen: Was für eine Serverhardware verwendest Du? Was für Controller sind verbaut? Gibt es im Bios/UEFI den Punkt "Reihenfolge der Controller beim booten"? Werden deine Festplatten in deiner Konfiguration fürs Raid über /dev/sdx angegeben oder über eindeutige Namen? Festplatten hast Du schon per hdparm mit einer Live-DVD gecheckt?
Meine Vermutungen: Die Reihenfolge der Controller beim booten hat sich getauscht, evtl. durch "weich gewordenen" Controller. Damit hauen dann die /dev/sdX Bezeichnungen nicht mehr hin und das Raid (ein Soft-Raid) kann nicht gebaut werden. Evtl ist einfach auch nur eine Platte matschig ala Blinker: geht, geht nicht und bringt damit das Raid durcheinander.
Ansonsten sind Späße wie RAM, Netzteil oder Motherboard tatsächlich auch Kandidaten die solche Fehler verursachen können. Hast Du evtl. in letzter Zeit Updates gemacht? Möglicherweise ein neuer Kernel der Probleme macht?

 

[gehrke]

Danke für die Antworten bislang!

Die allermeisten Fragen kann ich erst beantworten, wenn der Server wieder gestartet ist bzw. ich im BIOS war. Aktueller Stand ist aber noch wie beschrieben (Notfall-Shell) - in der Hoffnung, da noch Informationen herauszukitzeln. Für letzteres gibt es wohl keine Ansätze mehr, daher werde ich mal versuchen, die Büchse am Abend zu booten.

Falls das klappt, werde ich neben der LogFile-Analyse insbesondere mal einen Check der jüngst hinzugekommenen Backup-Disk durchführen.

 

[gehrke]

Hast Du evtl. in letzter Zeit Updates gemacht? Möglicherweise ein neuer Kernel der Probleme macht?

Zumindest das kann ich für den Host ausschliessen. Die VMs werden gepatched, aber das betreffende Host-System darunter wurde seit laaaanger Zeit bewust nicht mehr gewartet.

 

[josef-wien]

daher werde ich mal versuchen, die Büchse am Abend zu booten

Das wird nur funktionieren, wenn es sich um eine temporäre Unpäßlichkeit gehandelt hat, und daran glaube ich nicht (aber möglich ist alles).

Eine (auch theoretische) Erklärung für das RAID-Problem fällt mir nicht ein. Hoffentlich gibt

mdadm -Asv

in einer grafischen Konsole eines Live-Systems (das mdadm an Bord hat) Erhellendes.

Gibt es im Bios/UEFI den Punkt "Reihenfolge der Controller beim booten"? Werden deine Festplatten in deiner Konfiguration fürs Raid über /dev/sdx angegeben oder über eindeutige Namen?

mdadm arbeitet mit seinen eigenen Array UUID und Device UUID:

mdadm --examine /dev/sd{a,b}1 | grep UUID

 

[gehrke]

Durch die Anzahl der Platten und die Zeilenbegrenzung des Bildschirms wird der zusätzliche Parameter -v (dann kommen sehr viele Zeilen) wahrscheinlich auch nicht weiterhelfen.

Hier der Output von

mdadm -Asv

noch aus der Notfall-Shell:

Ein Paging war leider nicht möglich.

 

[marce]

mdadm -Asv | more

geht nicht? Oder eine Umleitung der Ausabe in eine Datei?

... und poste mal die Ausgabe von fdisk -l - ich habe immer noch das Gefühl, daß da eine HD wo reinspukt, wo sie nicht hin sollte...