FreeBSD 10.1 ständige Abstürze

m4rkus

Well-Known Member
Hallo,

seit dem Upgrade ist mein Server regelmäßig nicht mehr erreichbar und zeigt nur eine flackernde Konsole an - evtl. kann man irgendwas mit CPU erkennen (flackert zu schnell...). Muss den Server hart ausschalten und wieder anschalten.

In der Logdatei /var/log/messages finde ich keine Hinweise - wo kann ich mit der Analyse beginnen?

Danke im Voraus.
Markus
 
Hast du sichergestellt, dass der Server auf nichts mehr reagiert? Netzwerk? ACPI shutdown? Keyboard?

Solange du den zpool noch nicht aktualisiert hast, kannst du vielleicht den alten Kernel noch booten.
 
Upgrade ist schon länger her.

Server reagiert auf nichts.

Gibt es einen guten Start für eine Ursachenanalyse?

Gruß
Markus
 
Für mich hört sich das nach einem Hardware-Schaden und zwar bei etwas sehr zentralem.

CPU, Stromversorgung, GPU/APU?, Mainboard...

Bootet denn eine Live-CD?
 
Hoi,

drück doch oifach mal die Pause Taste und schau mal ob das hilft um auf der Console was zu erkennen. An sonsten würde ich mal das installierte System als Live OS von CD/DVD/USB-Stick/VirtualMedia booten, um zu schauen ob er damit auch abstürzt mit diesem Fehlerbild oder nicht. Wenn ja ist der Fehler sicherlich am ehsten in der Hardware zu finden.

Gruß Bummibär
 
Also ich hab mal ein Bild von der Konsole gemacht.

Irgend eine Idee?

Edit: Keine Ahnung warum das Bild falschrum ist???
 

Anhänge

  • IMG_1055.JPG
    IMG_1055.JPG
    564,1 KB · Aufrufe: 619
sieh zu dass du von allen Bauteilen die aktuelle Firmware/BIOS geladen hast.
Aktiviere ein Monitoring von so vielen Sensoren wie möglich und sinnvoll. Schreibe ein Syslog auf einen anderen Host im Netz.
Stell sicher dass der Server in allen Punkten korrekt verkabelt ist und keine Sedimente von Staub sich gebildet haben.
 
Ein "Double Fault" ist im Endeffekt ein Fault, der im Fault-Handler passiert ist. Da ist was ganz derbe hardwaretechnisch unfein. Mach mal einen Systemcheck.
 
Was genau meinst du mit Systemcheck?

Bzgl. richtig verkabelt und aktuelle Version: bisher lief der Server sauber durch. BIOS ist aktuell.

Gruß
Markus
 
Die CAM-Fehler nach der Panic sehen auch böse aus. Davon mal abgesehen ist es auch immer ein gutes Indiz für Hardware-Probleme, wenn man unterschiedliche Panics bekommt. Der Crash also an anderen Adressen auftritt, der Backtrace anders ausschaut, eventuell sogar die Art der Panic variiert. Durch Softwarefehler ausgelöste Panics sind hingegen in den meisten (aber nicht allen!) Fällen immer gleich oder zumindest sehr ähnlich.
 
Ich würde nur gerne Testen, was da schief geht.

Server ist ein normaler Rechner mit i7 2600k, 32 GB RAM, IBM 1015, 2 SSDs als Boot + Cache + 6x3TB Festplatten.
Bevor ich was austausche, möchte ich gerne wissen WAS ich austauschen muss.

Ich dachte es gibt vielleicht Logfiles / Crashdumps wo ich etwas genauer einblicken kann, was vielleicht nicht läuft.
Leider bin ich die ganze Woche auf Schulung im Hotel und kann jetzt keine LIveCD booten - Was würde ich denn auch erwarten? Aktiv warten, ob er auch abstürzt?

Gruß
Markus
 
Na ja, wenn die Live CD auch nicht bootet, kann man FreeBSD als Fehlerursache definitiv ausschließen.

Ansonsten zu Hause hinsetzen und alles abklemmen, was nicht unbedingt muss. RAM Riegeln einzeln entfernen und testen, HDDs usw. So würde ich zumindest vorgehen.
 
Mmh. Mittelfristig ist der Umstieg auf einen richtigen Server geplant - aktuell existiert dieser leider noch nicht.

Ich werde mal versuchen den ein oder anderen Test remote - oder ansonsten über die Feiertage vor Ort zu machen.
Werde mich noch mal melden.

Gruß
Markus
 
Ich bin zwar ein sehr großer Freund von ECC-Speicher und würde niemals einen Server ohne ECC einsetzen. Aber zu sagen, dass man ZFS nur auf Systemen mit ECC-Speicher nutzen sollte, halte ich für weit übertrieben. Gerade in Anbetracht dessen, dass die Auswahl an entsprechender Desktophardware doch begrenzt ist. Das Risiko, dass ein kaputtes Speichermodul zu einem zerstörten ZFS führt, ist extrem gering. Dafür muss die defekte Speicheradresse schon sehr, sehr ungünstig liegen. Genauso kann man argumentieren, dass eine defekte Speicheradresse an der falschen Adresse 'fsck_ufs' das Dateisystem zerdeppern lässt, chkdsk.exe darüber NTFS zerlegt und 'xfs_repair' den B-Tree fällt...

Wenn das ZFS tatsächlich zerlegt werden sollte, spielt man halt das Backup zurück. Wenn es kein funktionierendes Backup gibt, waren die Daten auch nicht wichtig. Das die korrupten Daten ins Backup gelangt sein könnten, ist kein Argument. Denn das wäre bei jedem anderen Dateisystem eben so passiert. Nimmt man halt ein älteres Backup. Und im Übrigen ist es gar nicht schwer, ZFS die Checksums ignorieren zu lassen. Dann kann man auch die von ihm als korrupt angesehenen Daten munter rauskopieren.
 
Ja, der Server den ich bei Hetzner habe wurde anfangs mit defektem RAM in Betrieb gestellt (kein ECC). Das zeigte sich dadurch, dass der Server nie 3 Tage Uptime schaffte und ständig neustartete. Es folgten auch Checksum-Errors durch ZFS.

Ob dadurch nun Dateien kaputt gegangen sind, kann ich natürlich nicht sagen, aber ist auch nicht so, als wenn der ganze Pool jetzt kaputt gegangen ist. Auch durch harte Panics etc. pp.

Aber ja, mit ECC wäre es mir natürlich lieber, aber das bliebt zur Zeit nur meinem Heimserver vorbehalten.
 
Mhhmmm, wundert mich, dass der Umstieg auf FreeBSD 10.1 zu solchen Ergebnissen führt...

Ich habe einen dicken Supermicro Server mit FreeBSD 10.1 "beseelt" und der rennt seit etlichen Wochen anstandslos auch unter Last... Dazu hatte ich ja auch schon einen Beitrag gemacht... Von daher gehe ich mal von defekter Hardware aus. Hatte schon mal sonderbare Effekte beim Installeiren einer anderen Maschine, die ich zigmal mit Solaris bestücken wollte. Ging nie durch, bis ich herausgefunden hatte, dass ein Speicherriegel defekt war - seit denn rennt die Kiste, nun auch unter FreeBSD... Vielleicht als Tipp: versuch's mal mit weniger Speicher und schau, wie das Verhalten ist...

Viele Grüße, Norbert
 
Ja, der Server den ich bei Hetzner habe wurde anfangs mit defektem RAM in Betrieb gestellt (kein ECC). Das zeigte sich dadurch, dass der Server nie 3 Tage Uptime schaffte und ständig neustartete. Es folgten auch Checksum-Errors durch ZFS.

Mit systemd wäre das alles kein Problem gewesen.
*SCNR*
 
Mhhmmm, wundert mich, dass der Umstieg auf FreeBSD 10.1 zu solchen Ergebnissen führt..

Och, manchmal sind Zufälle echt lustig. Ein Kumpel von mir hat letztens sein MacPro auf Yosemite aktualisiert... genau in dem Moment ist ihm die SSD ausgestiegen und das System stürzte alle Nase lang ab bzw. blieb hängen. Fehler überall. Abstürze, Hänger, "illegal instructions", etc. pp.

Ein Firmware-Update war die "Rettung". War ein Firmware-Bug der nach einer gewissen PowerOn Time auftritt.

@peterle

Den Zusammenhang verstehe ich nicht.
 
Ich bin zwar ein sehr großer Freund von ECC-Speicher und würde niemals einen Server ohne ECC einsetzen. Aber zu sagen, dass man ZFS nur auf Systemen mit ECC-Speicher nutzen sollte, halte ich für weit übertrieben. Gerade in Anbetracht dessen, dass die Auswahl an entsprechender Desktophardware doch begrenzt ist. Das Risiko, dass ein kaputtes Speichermodul zu einem zerstörten ZFS führt, ist extrem gering. Dafür muss die defekte Speicheradresse schon sehr, sehr ungünstig liegen. Genauso kann man argumentieren, dass eine defekte Speicheradresse an der falschen Adresse 'fsck_ufs' das Dateisystem zerdeppern lässt, chkdsk.exe darüber NTFS zerlegt und 'xfs_repair' den B-Tree fällt...

Hast du den Link gelesen? Die anderen FS haben keine Checksummen und kennen kein scrubbing. Das sind die Stellen, an denen bei ZFS ein Speicherfehler _richtig_ zuschlagen kann.
 
Hast du den Link gelesen? Die anderen FS haben keine Checksummen und kennen kein scrubbing. Das sind die Stellen, an denen bei ZFS ein Speicherfehler _richtig_ zuschlagen kann.

Trotzdem sind das "was-wäre-wenn" Spielchen und alles andere behebt ein Backup der Daten. Und statt scrub nimmst du halt irgend ein fsck-Tool, welches dann mal eben ein heiles Dateisystem reparieren will.
 
Nagut, wenns nicht mal für Serverhardware reicht, wird die entsprechende Backup-Infrastruktur, um zig TB zuverlässig zu sichern, bestimmt vorhanden sein.

Ich sehs ja ein.
 
Zurück
Oben