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

[Marcus Röckrath]

Hallo Derya,

D. Oezbilen wrote:

> 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?).

Meine Erfahrung ist, dass sich defekter RAM sehr schnell durch unerklärliche
Abstürze bemerkbar macht. Bei Linux viel schneller als bei Windows; ich
hatte da oft schon massive Startprobleme des Kernels.

Wolfgang konnte ja auch durch Vergleich feststellen, dass alle "fixen" Daten
nicht korrumpiert waren. Da einzelne kippende Bits nicht immer genau die
gleiche Datei an gleicher Stelle treffen, müsste man klare
Checksum-Abweichungen finden.

Wenn Daten von einem Datenträger auf einen anderen kopiert werden, gehen die
überhaupt den Weg über das RAM oder wird das direkt über den Chipsatz
abgehandelt?

> 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.

Mit einer langfristigen Backupstrategie sollte man davor gefeit sein - die
Haltbarkeit von Backup-Medien dürfte da viel unbemerbarer für Zerstörung
sorgen.

> 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.

Wie sieht der Zweizeiler nun genau aus?

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

Wäre doch einen Wiki-Artikel wert, oder?

Danke für deine Ausführungen.

-- 
Gruß Marcus
[eisfair-Team]