[Eisfair] [e1] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0, 0)

[D. Oezbilen]

Hallo Wolfgang, @all,

*frohes Neues Jahr @all.*
Ich habe etwas ueberlegt, ob ich die Zeilen schreibe, denn es klingt 
altklug und besserwisserisch. Doch ist es nicht so gemeint.

Auch, wenn eis/x64 fuer @home konzipiert wurde, am Ende ist es ein 
__Server__, noch dazu ein grossartiges Konstrukt.

Sprich, diese Maschine hat eine zentrale Funktion, man vertraut dieser 
Einheit blind die Daten, die man im Zugriff haben will, ebenso Dateien, 
die dort auflaufen und nicht verloren gehen sollen (Raid/Backup etc).

Das Beispiel in diesem thread zeigt wie fatal evtl. auch desastroes 
-wenn noch zu spaet- entdeckt, dieser defekte RAM-Riegel sich auf den 
Betrieb auswirkt. Hier ging es hoffentlich glimpflich ab 
(backup-Korruption?).

Dass die Einheit einen Tag nicht im Netz ist - der memtest fast einen 
Tag laeuft- kann man wohl verschmerzen, weil @home und keine Produktion 
dran haengt.

Was aber, wenn dieser RAM-Fehler so lange das fs so korrumpiert hat, 
dass auch x-Backups zerstoert sind? Allein diese Vorstellung treibt doch 
einem den Schweiss auf die Stirn, nicht nur das Dokumente defekt sind, 
auch familiaere Bilder, die alle (ab wann?) kaputt sind etc.

Wenn Server, sollte der Chipsatz den Fehler abfangen, zudem man diesen 
Zustand auch abfragen kann. Sicher nicht jeder Chipsatz kann das, auch 
nicht jede CPU/Chipsatz-Kombination.

Klar kann man abwaegen, wie oft so ein defekter RAM-Riegel vorkommt, 
oefter als man denkt, gar bei hoeherwertigem Speicher, der v. 
Server-Herstellern fuer ihre System freigegeben sind.

Geschweige 08/15-Speicher, die kein ECC haben und still und leise das 
umgekippte Bit staendig irgendwohin schreiben, ohne, dass man frueh 
genug bescheid bekommt.
Wie will man das ohne ECC ueberpruefen?  Geht halt nicht, evtl. nur 
ueber rsyncs hash zum Backup, dann nach einem --dry-run den echten 
Sync-Vorgang anzustossen?

Ebenso wenn man SW-Raid hat (nicht OK), was, wenn die libs/bins des 
SW-Raids per Zufall defekt sind?

Hingegen, hat man ECC-Speicher funkt es mit edac-util so einfach; hier 
sind paar Zeilen aus der Vergangenheit:

edac-util

mc0: csrow0: CPU#0Channel#1_DIMM#0: 60229 Corrected Errors

mit verbose:

edac-util -v

mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
mc0: csrow0: 0 Uncorrected Errors
mc0: csrow0: CPU#0Channel#0_DIMM#0: 0 Corrected Errors
mc0: csrow0: CPU#0Channel#1_DIMM#0: 60229 Corrected Errors
mc0: csrow0: CPU#0Channel#2_DIMM#0: 0 Corrected Errors
mc0: csrow1: 0 Uncorrected Errors
mc0: csrow1: CPU#0Channel#0_DIMM#1: 0 Corrected Errors
mc0: csrow1: CPU#0Channel#1_DIMM#1: 0 Corrected Errors
mc0: csrow1: CPU#0Channel#2_DIMM#1: 0 Corrected Errors
mc1: 0 Uncorrected Errors with no DIMM info
mc1: 0 Corrected Errors with no DIMM info
mc1: csrow0: 0 Uncorrected Errors
mc1: csrow0: CPU#1Channel#0_DIMM#0: 0 Corrected Errors
mc1: csrow0: CPU#1Channel#1_DIMM#0: 0 Corrected Errors
mc1: csrow0: CPU#1Channel#2_DIMM#0: 0 Corrected Errors
mc1: csrow1: 0 Uncorrected Errors
mc1: csrow1: CPU#1Channel#0_DIMM#1: 0 Corrected Errors
mc1: csrow1: CPU#1Channel#1_DIMM#1: 0 Corrected Errors
mc1: csrow1: CPU#1Channel#2_DIMM#1: 0 Corrected Errors

cat /sys/devices/system/edac/mc/mc0/csrow0/ch1_ce_count
60229

dmidecode -t memory | grep 'Locator: PROC

kriegt man diese Liste (zumindest bei diesem Server):

         Locator: PROC 1 DIMM 1G
         Locator: PROC 1 DIMM 2D
         Locator: PROC 1 DIMM 3A
         Locator: PROC 1 DIMM 4H
         Locator: PROC 1 DIMM 5E
         Locator: PROC 1 DIMM 6B
         Locator: PROC 1 DIMM 7I
         Locator: PROC 1 DIMM 8F
         Locator: PROC 1 DIMM 9C

         Locator: PROC 2 DIMM 1G
         Locator: PROC 2 DIMM 2D
         Locator: PROC 2 DIMM 3A
         Locator: PROC 2 DIMM 4H
         Locator: PROC 2 DIMM 5E
         Locator: PROC 2 DIMM 6B
         Locator: PROC 2 DIMM 7I
         Locator: PROC 2 DIMM 8F
         Locator: PROC 2 DIMM 9C

Hier bei ist
mc0: csrow0: CPU#0 = PROC 1

1...9 geben die laufende Numerierung an, A/B/C etc jedoch die 
Bestueckungsreihenfolge:

3A,6B,9C = Channel 0
2D,5E,8F = Channel 1
1G,4H,7I = Channel 2

Channel#1 betreut 2D,5E,8F

_DIMM#0 => 2D


Mit

dmidecode --type memory | grep -A 10 -B 10  2D

Handle 0x1101, DMI type 17, 34 bytes
Memory Device
         Array Handle: 0x1000
         Error Information Handle: Not Provided
         Total Width: 72 bits
         Data Width: 64 bits
         Size: 8192 MB
         Form Factor: DIMM
         Set: 2
         Locator: PROC 1 DIMM 2D
         Bank Locator: Not Specified
         Type: DDR3
         Type Detail: Synchronous
         Speed: 1333 MHz
         Manufacturer: Not Specified
         Serial Number: Not Specified
         Asset Tag: Not Specified
         Part Number: Not Specified
         Rank: 2
         Configured Clock Speed: 1066 MHz
--

kriegt man auch die Pos. des Riegels, aber leider hier nicht mehr Infos, 
wie Seriennummer, Hersteller etc. :-(

Wie CPUX, ChannelX, DIMMX definiert sind, geben die RTFM-Blaetter des 
Boards (auch dem Blechcover des Servers) her.

Mit einem Zweizeiler per Cron gestartet, kann man eine Mail absetzen, so 
hat man auch Zeit den Riegel zu ersetzen oder einfach _raus_ zu nehmen 
und auch nicht voellig blind die Backups zu zerstoeren.

Das Abfallprodukt: ___kein___ Stillstand.
Keine 5 min downtime.

Allein die Vorstellung, was denn nun kaputt ist, ist doch eine Lotterie, 
__wann___ ist das eingetreten?

Ist das Backup vor einer Woche/Monat/wann(?) schon korrumpiert, ist doch 
ein lebensverkuerzender Process. Und wer sagt, was nun richtig/korrekt ist?

Kann doch sein, dass das Backup einen anderen hash hat (trotzdem defekt 
ist), jetzt auch die online-Dateien einen anderen hash aufweisen, gulp. 
:-(. Was ist korrekt?

Klar ist die Kombination aus ECC-Speicher/Chipsatz/CPU/MB etc beim 
Einstieg teurer. Was ist einem selbst das Wert, welches Risiko geht man 
bewusst -bei vorhandener Alternative- ein?

Vllt. hilft einem das o.a. beschriebene Szenario einen RAM-Fehler zu 
detektieren, bevor
... then.the.shit.hits.the.fan-Situation. ;-)

Frohes Neues Jahr.

Gruss
Oezbilen