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

So Jan 3 13:31:56 CET 2021

Am 02.01.2021 um 23:59 schrieb 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

Hallo Oezbilen,

der defekte Speicherbaustein ist ein Infineon 64Mx72 SDRAM, 512MB, Sync,
133MHz, ECC, Reg. MB ist ein Asus TR-DLS, demidecode liest leider keine
Details der Speicherbausteine aus.

> 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.
Hätte ich gerne, da ich bisher ausschliesslich HD- bzw. Elko-Ausfälle
von Netzteil und Mainboards zu beklagen hatte und wohl den
Speicherbausteinen zu blind vertraut habe. Zukünftig wird bei
Ungereimtheiten der memtest die erste Wahl sein.

Gruss, Wolfgang