Mainboard "Supermicro X11SSH-CTF" durch BIOS-Update geschrottet?

[hoppel118]

Hallo Leute,

da es sich um das Mainboard meines Homeservers handelt, denke ich, dass das Thema hier eher hin passt, als in den Mainboard-Bereich.

Mein Mainboard: Supermicro X11SSH-CTF
Meine CPU: Intel Xeon E3-1240Lv5 4x 2.10GHz So.1151 TRAY

ich habe meinen Homeserver vor ca. 4 Monaten mit komplett neuer Hardware ausgestattet. Nun wollte ich eine neue DVB-Karte in einem der beiden PCIe-Slots installieren, die aber auf "biegen und brechen" (Anpassung der PCI/e-Einstellungen im BIOS) nicht vom System erkannt werden wollte. "LSPCI" hat mir die Karte einfach nicht angezeigt. Der Test in meinem alten HTPC mit ASUS-Mainboard hat gezeigt, dass die Karte in Ordnung ist.

Nun habe ich mich also entscheiden, ein BIOS-Update auf dem Supermicro-Mainboard durchzuführen. Nachdem mir dann die BIOS-Software bestätigte, dass das Update erfolgreich war und ich "Enter" betätigen soll, um den Rechner neuzustarten, hing direkt danach die System-Initilisierung beim Starten bei der CPU-Initilisierung "PEI--CPU Initialization - 35" fest und ich konnte den Server nicht mehr bis zum Ende hochfahren. Die 35 bedeutet "CPU post - memory initialization. Boot Strap Processor (BSP) selection".

Leider komme ich nicht mal mehr ins BIOS. Hm..., das dumme ist, dass ich in meinem Leben (privat und beruflich) bereits einige Firmware- und BIOS-Updates durchgeführt habe und ausgerechnet jetzt geht es tatsächlich schief. Naja, irgendwann ist immer das erste Mal.

Habe diverse "CMOS Clears" (Vorgang: Batterie entfernen, contact pad kurzschließen, etc.) entsprechend Supermicro Manual durchgeführt und auch schon alle Komponenten inkl. CPU vom Mainboard für einige Stunden abgebaut und währenddessen ebenfalls einen CMOS Clear durchgeführt. Das hat leider alles nichts gebracht.

Übers Wochenende habe ich das Board ja noch. Momentan liegen alle Komopnenten fein säuberlich auseinandergebaut auf meinem Tisch. Sonntag abend baue ich es alles nochmal zusammen und teste es ein letztes Mal. Wenn es dann nicht klappt, geht das Mainboard auf jeden Fall in die RMA-Abwicklung.

Nachdem ich heute Kontakt mit Supermicro hatte, habe ich bereits bei meinem Reseller eine RMA in die Wege geleitet. Der muss jetzt aber erstmal Kontakt zu Supermicro aufnehmen und Supermicro muss die RMA abwickeln. Ich gehe davon aus, dass das ein paar Tage (evtl. auch Wochen) dauern wird. Also vrsl. noch ein paar Tage ZEit für weitere Tests.

Hat hier noch jemand eine Idee dazu?


Danke und viele Grüße

Hoppel

 

[Sightus]

Wenn das BIOS gesockelt ist (Bilder lassen so etwas erahnen), dann kannst Du auch auf die Schnelle einen neuen BIOS-Chip bestellen und so evtl. eine RMA umgehen.

 

[hoppel118]

Du meinst man könnte das BIOS einfach austauschen? Kann da gerade nichts erkennen.

Gruß Hoppel

 

[Sightus]

Sorry, keine Ahnung welches Bild ich eben angeschaut habe, aber auf dem Bild ist der BIOS-Chip verlötet. Müsste imho der Chip links oberhalb der BIOS-Batterie sein (8-Pin, weißer Aufkleber).


EDIT: Auf der SuperMicro-Seite hat das Board noch ein gesockeltes BIOS; ich hasse es, wenn Hersteller Vorserienbilder online stellen.

 

[Trambahner]

Wie bist Du ansonsten mit Mainboard zufrieden (bzw. was für Betriebssystem/Config)? Bis auf das BIOS-Thema nun natürlich?
Hast Du Daten bzgl. Leistungsaufnahme im Idle?

Das Ding ist nämlich schon verdammt "lecker" (2*10GB und LSI HBA) für den Preis.

 

[hoppel118]

EDIT: Auf der SuperMicro-Seite hat das Board noch ein gesockeltes BIOS; ich hasse es, wenn Hersteller Vorserienbilder online stellen.

Ja, du hast recht. Auf der Supermicro-Seite sind zwei Chips gesockelt. Bei mir sind sie definitiv fest verlötet. Schade!

Wie bist Du ansonsten mit Mainboard zufrieden (bzw. was für Betriebssystem/Config)? Bis auf das BIOS-Thema nun natürlich?
Hast Du Daten bzgl. Leistungsaufnahme im Idle?

Das Ding ist nämlich schon verdammt "lecker" (2*10GB und LSI HBA) für den Preis.

Moinsen, ich hatte mich auch in die Features verliebt. Ansonsten bin ich nun mit dem Board absolut zufrieden. Ich nutze debian jessie 8.5 mit kernel 4.5 seit einigen Monaten produktiv ohne jegliches Problem. An dem LSI habe ich 8x4 TB WD Red hängen und ein ZFS Raid-Z2 konfiguriert auf dem ungefähr 10TB Daten Daten liegen.

Die Ersteinrichtung war etwas tricky, da die Netzwerkkartentreiber (Intel X550) tatsächlich erst in Kernel 4.x enthalten sind. Die Installation musste dann erstmal ohne Netzwerkkarte erfolgen. Danach dann den Kernel per USB-Stick manuell installieren, die network/interfaces und sources.list ebenfalls manuell anpassen. Geht aber wenn man den Umgang mit der Command Line beherrscht. Im täglichen Betrieb habe ich noch nichts bemerkt, was mir irgendwie komisch vorkam.

Im Idle verbraucht er ca. 40 Watt. wenn die Festplatten hochfahren ca. 75 Watt, wenn ich mich recht entsinne.

Habe außerdem 64GB ECC Ram und die oben bannte CPU (25Watt TDP) verbaut.

Evtl. gibt es für das IPMI eine Lizenz (SFT-00B-LIC) anhand der man das BIOS (Update) managen kann. Der Tip wurde mir im VDR-Portal gegeben. Bin mir allerdings noch nicht sicher, ob diese Lizenz auch bei den X11ern funktioniert. Werde morgen nochmal alles zusammenbauen und dann nochmal im IPMI nachschauen, wie das bei mir aussieht. Evtl. habe ich damit dann noch eine Möglichkeit das gute Stück selbst zu retten.

Das wurde hier auch ganz gut erläutert: https://www.thomas-krenn.com/de/wiki/Supermicro_BIOS_Update_via_IPMI

 

[hoppel118]

Mainboard "Supermicro X11SSH-CTF" durch BIOS-Update geschrottet?

Hallo Leute,

habe gerade nochmal alle Komponenten wieder zusammengebaut in der Hoffnung, dass das Mainboard komplett zurückgesetzt wurde. Trotz zusätzlichem CMOS Clear hängt der Bottvorgang weiterhin an derselben Stelle. Ok, schade. Danach habe ich mir das IPMI nochmal genauer angesehen. Auf der Thomas Krenn Seite wird beschrieben, dass ein BIOS-Update mehrmals nicht funktioniert hat, bis eine aktuelle IPMI-Firmware installiert wurde. Es scheint da also einen direkten Zusammenhang zwischen IPMI und BIOS zu geben.

Das IPMI-Firmware-Update kann man im Gegensatz zum BIOS-Update auch ohne zusätzlichen Lizenz-Schlüssel durchführen.

Also habe ich das einfach mal ausprobiert. Viel zu verlieren habe ich ja nicht mehr. Das IPMI-Firmware-Update ist ohne Probleme durchgelaufen (wie das BIOS-Update auch). Das IPMI funktioniert allerdings weiterhin. Der Rechner bootet trotzdem nicht.

Vorher hatte ich folgende BIOS-und IPMI-Firmware-Versionen:

Firmware Revision : 01.12
Firmware Build Time : 12/31/2015
BIOS Version : 1.0
BIOS Build Time : 01/14/2016
CPLD Version : 02.b1.01

Mittlerweile wird folgendes angezeigt:

Firmware Revision : 01.15
Firmware Build Time : 02/19/2016
BIOS Version : 1.0a
BIOS Build Time : 03/22/2016
CPLD Version : 02.b1.01
undefined 1.0.1

Die neuen Versionsnummern des BIOS- und des IPMI-Firmware-Updates werden angezeigt, aber die letzte Zeile kommt mir spanisch vor, zumal es die vorher gar nicht gab. Kann da jemand was mit anfangen?

Wie dem auch sei. Ich werde morgen auf jeden Fall erstmal versuchen diese BIOS-Update-Lizenz für das IPMI zu bekommen. Hoffentlich kann man mir den Key per Email zuschicken.


Viele Grüße Hoppel

EDIT: Habe den Server übrigens gerade nochmal stromlos gemacht. Jetzt steht dort statt "undefined : 1.0.1" folgendes "Redfish Version : 1.0.1". Sieht jetzt irgendwie aus, als ob alles glatt gelaufen ist, bootet nur leider nicht...

 

[WyRoX]

Hast du schon versucht ein BIOS Recovery durchzuführen (Seite 54 und ab Seite 119 im Handbuch)?
SuperMicro hat seit der X10 Version jedem Mainboard ein DualBios spendiert.

Viele Grüße
WyRoX

 

[John Cyber]

... Hat hier noch jemand eine Idee dazu? ...

Ja. Es gibt für jedes SM Board ein Recovery BIOS mit Dateinamen AMI.ROM
Dieses wird auf einen FAT-formatierten USB-Stick gepackt, welcher ZWINGEND in den UNTEREN USB 2.0 Port gesteckt werden muss.
Booten und der Recovery Prozess läuft automatisch an. Die Supermicro Supporter haben das und nach einer Weile wird
das für praktisch jedes SM Board irgendwo öffentlich.

Wenn man die richtige Person im Supermicro Support erwischt, kriegt man es auf kurzem Wege per E-Mail. Leider kennt die
Prozedur nicht jeder SM-Supporter bzw. Händler.

Update: Jetzt habe ich mal meinen Vorredner gelesen. Ersetze AMi.ROM durch SUPER.ROM wie in Deinem Handbuch
auf Seite 119 beschrieben. Zusätzlich mit der Tastenkombination beim Booten sollte es klappen.

 

[hoppel118]

Hallo Leute,

danke für eure Unterstützung. Das Board befindet sich übrigens mittlerweile auf dem Weg zu Supermicro.

Hast du schon versucht ein BIOS Recovery durchzuführen (Seite 54 und ab Seite 119 im Handbuch)?
SuperMicro hat seit der X10 Version jedem Mainboard ein DualBios spendiert.

Ja, ich habe das Manual hoch und runter gelesen und sämtliche Sachen die mit CMOS Reset und BIOS Recovery zu tun haben ausprobiert. Leider alles ohne Erfolg.

Ja. Es gibt für jedes SM Board ein Recovery BIOS mit Dateinamen AMI.ROM
Dieses wird auf einen FAT-formatierten USB-Stick gepackt, welcher ZWINGEND in den UNTEREN USB 2.0 Port gesteckt werden muss.
Booten und der Recovery Prozess läuft automatisch an. Die Supermicro Supporter haben das und nach einer Weile wird
das für praktisch jedes SM Board irgendwo öffentlich.

Wenn man die richtige Person im Supermicro Support erwischt, kriegt man es auf kurzem Wege per E-Mail. Leider kennt die
Prozedur nicht jeder SM-Supporter bzw. Händler.

Update: Jetzt habe ich mal meinen Vorredner gelesen. Ersetze AMi.ROM durch SUPER.ROM wie in Deinem Handbuch
auf Seite 119 beschrieben. Zusätzlich mit der Tastenkombination beim Booten sollte es klappen.

Der Weg per Super.ROM auf einem FAT-USB-Stick war der Weg anhand dessen ich das Update durchgeführt habe. Nach der Erfolgsmeldung habe ich dann wie beschrieben mit "Enter" den Neustart bestätigt. Direkt im Anschluss hing der Bootvorgang. Warum auch immer, obwohl das Update angeblich erfolgreich war.

Naja, falls ich mal wieder ein BIOS-Update auf diesem Mainboard machen muss, werde ich mir auf jeden Fall die IPMI-Lizenz für knappe 25€ kaufen.

Gruß Hoppel

 

[hoppel118]

Moinsen,

hat hier jemand eine Idee, wo man ältere Supermicro-BIOS- und -IPMI-Firmwarestände downloaden kann?

Da ich nach dem erfolgreichen Update beim letzten Mal nicht mehr booten konnte, weil der Bootvorgang bei "PEI--CPU Initialization - 35" hängen blieb, möchte ich mich auf das nächste BIOS-Update besser vorbereiten. Das nächste BIOS-Update soll per IPMI mit der entsprechenden Lizenz durchgeführt werden, damit ich im Notfall ein Downgrade auf die bisherige Version durchführen kann.

Oder besteht irgendwie die Möglichkeit vor dem BIOS-Update die installierte BIOS-Version sowie vor dem IPMI-Update die installierte IPMI-Firmware-Version vom "Flash-Speicher" herunterzuladen?

Dazu finde ich keine Informationen im Netz.


Danke und Gruß Hoppel

 

[hoppel118]

Moinsen,

ein Antwort dazu ist nicht mehr erforderlich. Man nimmt einfach per Email Kontakt zum Supermicro Support auf und hat ein paar Minuten später alle IPMI-Firmware- und BIOS-Update-Versionen die man braucht.

Gruß Hoppel

 

[KevX]

Hallo Hoppel,

ich interessiere mich für das X11SSH-CTF, deine Informationen hier (und in anderen Foren) waren mir bei meinen Recherchen bereits eine große Hilfe, vielen Dank dafür!
Wie sind inzwischen deine Erfahrungen zu dem Board, bist du soweit zufrieden? Inzwischen verwendest du es ja bereits einige Zeit.

Mich interessiert besonders, wie die Verwendung des LSI 3008 unter Linux aussieht. Musstest du eine andere Firmware (IT-Mode) auf den Controller flashen um die Festplatten einzeln ansprechen zu können?
Stehen die Festplatten dann ganz normal unter /dev/sd[a-x] zur Verfügung, als wären diese direkt an die S-ATA Ports des C236 angeschlossen?

Viele Grüße

Kev

 

[hoppel118]

Hi @KevX

ja, das Board läuft seit mittlerweile einigen Monaten stabil. Allerdings verfalle ich immer wieder neuen Spieltrieben. Denn die Möglichkeiten sind cheer unbegrenzt.

Neulich musste ich diesen Thread öffnen, weil ich mir das BIOS bei einem Update zerschossen habe. Die RMA des Mainboards ging relativ langsam (ca. 2-3 Wochen) über die Bühne. Als das Board dann hier war, war direkt ohne mein Zutun der SAS-Chip defekt. Die LED hat direkt beim Booten konstant rot geleuchtet. Also habe ich die nächste RMA eingeleitet und das Board erneut ausgetauscht bekommen. Das neue Board hatte ich diesmal innerhalb von 5 Tagen wieder bei mir zu Hause. Ich wollte eigentlich die "digital devices max-s8" mit diesem Board betreiben. Habe aber so ziemlich alle Einstellungen durchprobiert, und es gibt wirklich viele, die damit zu tun haben könnten. Ich hatte mittlerweile auch mit dem Support von digital devices einen längeren Support Call. Die Kollegen hatten sich remote auf meinen Desktop geschaltet, ich war per ipmi im BIOS und wir haben gemeinsam die entsprechenden Einstellungen konfiguriert. Es war aber nix zu machen. Die Karte wollte nicht erkannt werden. Danke nochmal an digital devices für die klasse Unterstützung, auch wenn es im Endeffekt nichts gebracht hat, außer die Erkenntnis, das diese Konstellation aus TV-Karte, Mainboard und BIOS-Version nicht funktioniert. Die "cine s2" läuft übrigens ohne jegliche Einstellungen tadellos.

Zunächst hatte ich ca. ein halbes Jahr lang folgende Konstellation eingerichtet:

• openmedivault 3.0.13 (debian jessie) mit backportkernel 4.5 auf bare metal
• 8x4TB WD Red per Plugin "openmediavault-zfs" im RAID-Z2
• smb, nfs, ssh, etc. wurde alles direkt im openmediavault-webui konfiguriert
• emby media server -> zur zentralen Organisation meiner Mediensammlung
• vdr 2.2.0 und vnsi 1.3.1 server -> um tv-streams (dvb-s2) im Haus zu verteilen
• als tv-karte verwende ich die "digital devices cine s2", die läuft ootb durch den backportkernel
• als clients verwende ich einen odroid c2 mit libreelec von wrxtasy, zwei Windows 10 x64 Pro Clients (einen mit Kodi 16.1, einen mit der aktuellen Kodi 17 beta), ein iPad und iPhone

Damit gab es grundsätzlich überhaupt keine Probleme.

Nun habe ich mir kürzlich überlegt, das System komplett zu virtualisieren, um vor irgendwelchen Updates auch mal ein Backup zu erstellen und wenn etwas schief geht einfach wieder einen Restore drüber zu schieben. In einem ersten Schritt habe ich nun folgendes erreicht:

• proxmox 4.3 (debian jessie) mit lts kernel 4.4.x läuft als basis
• in einer kvm läuft openmediavault 3.0.41
• lsi sas3008 (sas-controller) per pci passthrough an openmediavault weitergereicht
• openmediavault-zfs als plugin konfiguriert und meinen vorhandenen Pool importiert
• emby media server in der kvm Zugriff auf meine Mediensammlung erteilt -> "emby for kodi" läuft tadellos
• "digital devices cine s2" (tv-karte) per pci passthrough an openmediavault weitergereicht
• sata-ssd per pci passthrough an openmediavault weitergereicht (es handelt sich um einen timeshift-buffer)
• vdr und vnsi in der kvm eingerichtet

Das läuft soweit seit ca. 2 Wochen alles tiptop! In einem weiteren Schritt werde ich mir dann anschauen, wie ich die einzelnen Dienste (insbesondere emby und vdr) in einem LinuxContainer (LXC) virtualisiert bekomme. Ich wollte aber in diesem Schritt möglichst wenige Abweichungen zur vorherigen Systemumgebung haben.

Aktuell kämpfe ich gerade mit einer Sache. Ich habe die Vermutung, dass das irgendwie mit der Virtualisierung zusammenhängt, bin mir aber nicht ganz sicher. Das Problem scheint aber bekannt zu sein und irgendwie mit zfs zusammenzuhängen. Ich bin mir leider auch nicht mehr sicher, ob das in meiner vorherigen Umgebung (openmediavault auf bare metal) auch so war.

Hier sind die Bugs dazu auf github. Bei dem zweiten habe ich mich direkt mal angehängt, da der noch offen und relativ aktuell ist:

https://github.com/zfsonlinux/zfs/issues/3785
https://github.com/zfsonlinux/zfs/issues/4638

Hast du noch konkrete weitere Fragen?

Gruß Hoppel

 

[KevX]

Hallo Hoppel,

vielen Dank für deine ausführliche Rückmeldung! Das ist sehr interessant zu lesen.

Ich nutze schon viele Jahre Virtualisierung (kvm mit libvirt + virt-manager), ganz lange davor openvz ("Opa" von lxc ). Mit proxmox und zfs habe ich aber noch nichts gemacht.
Für System-Sicherungen (Snapshots) nutze ich ebenfalls seit Längerem ganz klassisch lvm auf einem mdadm Raid. Damit lässt sich der Systemzustand in einer Sekunde einfrieren und wieder zurücksetzen, ohne, dass man zwingend Virtualisierung benötigt. kvm nutze ich primär als Bildschirm/Tastatur-Ersatz für das Hauptsystem. Das hat sich mit IPMI dann eigentlich auch erledigt, da bin ich schon sehr darauf gespannt.
Außerdem warte ich schon Jahre darauf, dass btrfs raid5/6 endlich stabil wird... aber das ist eine ganz andere Geschichte ...

Emby klingt sehr interessant, das muss ich mir dann auch unbedingt einmal anschauen. Zur Zeit nutze ich einfache Samba-Freigaben und greife per OpenElec (FireTV am Fernseher) darauf zu... Fernseh-Aufnahmen (nutze ich selten) per OTR.


Deine zwei Links habe ich mir angesehen. Mangels zfs-Erfahrung kann ich aber leider nichts dazu beitragen. Ich könnte mir nur vorstellen, dass ein zu kurzer Timeout daran schuld ist. Der Kernel bzw. das Dateisystem möchte einen bestimmten Block/Sektor lesen. Bekommt aber von der untergeordneten Schicht in der erwarteten Frist keine Antwort, dadurch gibt es einen Lesefehler auf eben diesem Sektor. Das scheint ein paar mal zu passieren, jedes mal gibt es einen Eintrag im Kernel Log.

Irgendwo auf dem Weg Anwendung -> Kernel -> Dateisystem -> Kernel -> Host-Controller (-> kvm -> Kernel) -> Festplatten-Controller dauert es möglicherweise zu lange, was zu dem Fehler führen könnte.
Wie du schon versucht hast, wäre es gut, wenn sich das Problem eingrenzen ließe, mögliche Fragen wären dann:

• Hast du die Kernel-Meldungen nur im Gastsystem oder auch etwas im Hostsystem?
• Bei einem einfachen Dateisystem im Gastsystem (Bug-Report: ext3) existiert das Problem anscheinend nicht, was ist aber mit einem klassischen Software Raid und darauf ein ext3/4? Möglicherweise tritt das Problem nur bei mehreren involvierten Festplatten auf? (z.B. zeitverzögertes Spin-Up der einzelnen Festplatten wg. Lastspitzen)
• Tritt das Problem auch bei einem ein-disk-zfs Dateisystem auf oder nur im Raid? Auch im Raid mit nur zwei Platten oder erst bei 4 oder mehr?
• Wie du schon schreibst, passiert das Gleiche auch ohne Virtualisierung?
• ...

Solche Fehler sind immer blöd zu finden. Immerhin hast du eine zuverlässige Reproduktion, das ist schon einmal viel wert.

Hast du noch konkrete weitere Fragen?

Ähm, ja, also meine Hauptfrage hast du quasi gekonnt umschifft... ;-).
Wie ist das denn nun mit dem Raid Controller auf dem Board? Muss man da den IT-Modus drauf flashen um auf die Festplatten einzeln zugreifen zu können (für zfs/mdadm/...) oder reicht es, wenn man den normalen IR-Modus unkonfiguriert lässt? Muss man sonst am Controller etwas einstellen um nicht das eingebaute Controller-Raid zu benutzen?

Viele Grüße

Kev

 

[hoppel118]

Irgendwo auf dem Weg Anwendung -> Kernel -> Dateisystem -> Kernel -> Host-Controller (-> kvm -> Kernel) -> Festplatten-Controller dauert es möglicherweise zu lange, was zu dem Fehler führen könnte.

Diese Vermutung liegt nahe.

• Hast du die Kernel-Meldungen nur im Gastsystem oder auch etwas im Hostsystem?

Im Hostsystem nutze ich ZFS nicht. Will da derzeitig auch nur ungern im Hostsystem mit herumspielen. Eigentlich möchte ich mein Gast-System auf eine weitere verfügbare SSD clonen und mir das ganze dann dort nochmal anschauen. Habe ich aber derzeitig noch keine Ahnung, wie sowas (kvm-to-ssd) funktioniert.

• Bei einem einfachen Dateisystem im Gastsystem (Bug-Report: ext3) existiert das Problem anscheinend nicht, was ist aber mit einem klassischen Software Raid und darauf ein ext3/4? Möglicherweise tritt das Problem nur bei mehreren involvierten Festplatten auf? (z.B. zeitverzögertes Spin-Up der einzelnen Festplatten wg. Lastspitzen)

Ich kann die 8x4tb nicht löschen und was ganz anderes (bspw. Dateisystem) ausprobieren, viel zu viel Aufwand.

• Tritt das Problem auch bei einem ein-disk-zfs Dateisystem auf oder nur im Raid? Auch im Raid mit nur zwei Platten oder erst bei 4 oder mehr?

Nicht getestet, aber danke für den Input.

• Wie du schon schreibst, passiert das Gleiche auch ohne Virtualisierung?

Das werde ich auf jeden Fall noch ausprobieren.

Solche Fehler sind immer blöd zu finden. Immerhin hast du eine zuverlässige Reproduktion, das ist schon einmal viel wert.

Jo, das stimmt.

Ähm, ja, also meine Hauptfrage hast du quasi gekonnt umschifft... ;-).
Wie ist das denn nun mit dem Raid Controller auf dem Board? Muss man da den IT-Modus drauf flashen um auf die Festplatten einzeln zugreifen zu können (für zfs/mdadm/...) oder reicht es, wenn man den normalen IR-Modus unkonfiguriert lässt? Muss man sonst am Controller etwas einstellen um nicht das eingebaute Controller-Raid zu benutzen?

Nö, ich habe keinen IT-Modus geflasht und ich musste auch nichts spezielles einstellen. Ich sehe meine 8 Platten per UUID und per /dev/sd[b-i].

folgendes finde ich noch in meinem Syslog:

mpt3sas version 12.100.00.00 loaded
mpt3sas_cm0: LSISAS3008: FWVersion(10.00.03.00), ChipRevision(0x02), BiosVersion(08.25.00.00)

Gruß Hoppel

 

[KevX]

Im Hostsystem nutze ich ZFS nicht. Will da derzeitig auch nur ungern im Hostsystem mit herumspielen.

Ganz so war das auch nicht gemeint. Die Frage hat eher darauf abgezielt, ob im Host-System irgendwelche Kernel-Meldungen zu dem Zeitpunkt erscheinen, wenn die Fehlermeldungen im Gast-System auftauchen. Diese Meldungen könnten z.B. auf Probleme in der Virtualisierung hindeuten.

Eigentlich möchte ich mein Gast-System auf eine weitere verfügbare SSD clonen und mir das ganze dann dort nochmal anschauen. Habe ich aber derzeitig noch keine Ahnung, wie sowas (kvm-to-ssd) funktioniert.

Den Teil verstehe ich nicht, was meinst du mit kvm-to-ssd?

Ich kann die 8x4tb nicht löschen und was ganz anderes (bspw. Dateisystem) ausprobieren, viel zu viel Aufwand.

Dass das Aufwand ist, ist klar. Es ist meistens Aufwand, wenn man ein (rätselhaftes) technisches Problem genauer untersuchen möchte ;-).
Ich habe auch erst einmal nur ein paar Punkte/Fragen als "mögliche Ansätze" aufgeschrieben, die mir beim Nachdenken über das Problem in den Sinn gekommen sind - ungeachtet davon, ob die Untersuchung jeweils praktikabel oder einfach ist.
Dieser Punkt im Speziellen ist aber vielleicht gar nicht so aufwändig, wie man zunächst vermuten würde, das hängt etwas von deiner genauen Einrichtung ab. Die kenne ich ja nicht im Detail. Bei so großen Festplatten benutzt man i.d.R. ja GPT und dort wiederum empfiehlt es sich grundsätzlich eine EFI-Partition einzurichten. Wenn du das gemacht hast, hättest du ein paar hundert MB auf jeder Platte quasi ungenutzt brach liegen (sofern diese nicht zum Booten gebraucht werden). Für ein kurzes Experiment würde dieser Speicherplatz ausreichen, ohne dein Array mit den Nutzdaten aufzulösen.
Ich habe auch mal gelesen, dass es bei zfs die Möglichkeit gibt, im zfs-Pool ein Block-Device zu erstellen, dass dann kein zfs-Dateisystem nutzt (zvol). Dort könnte dann auch ein anderes Dateisystem ausprobiert werden. Ob das einen Unterschied macht?


Eine weitere Frage, die sich mir im Nachhinein noch gestellt hat ist, ob deine Festplatten nach dem ersten Zugriff im Standby (hdparm -y) alle gleichzeitig anlaufen oder nacheinander? Eventuell kann man das durch fühlen oder Ohr-dran-halten erkennen. Ansonsten ein paralleles dd if=/dev/sdx of=/dev/null bs=4096 count=1 auf allen schlafenden Festplatten und schauen, ob die einigermaßen gleichzeitig fertig sind (bei mehrmaligen Versuchen Cache vorher leeren).

Wie gesagt, alles nur ein paar Ideen. Ob du das weiterverfolgen möchtest oder nicht, bleibt natürlich ganz dir überlassen. Man könnte natürlich auch einfach abwarten und hoffen, dass die zuständigen Entwickler das Problem lösen...

Nö, ich habe keinen IT-Modus geflasht und ich musste auch nichts spezielles einstellen. Ich sehe meine 8 Platten per UUID und per /dev/sd[b-i].

gae hat in einem anderen Thread geschrieben, dass der IT-Mode bzw. die IT-Treiber prinzipiell besser gepflegt seien und stabiler liefen. Das wäre vielleicht auch noch interessant, ob das in deinem Fall einen Unterschied macht? Ich kann das leider noch nicht beurteilen.

Auf jeden Fall danke ich dir sehr für die Infos und deine Erfahrungswerte. Damit sind die letzten Zweifel beseitigt und ich kann bei meinem Projekt weitermachen!

Viele Grüße

Kev

 

[hoppel118]

Ganz so war das auch nicht gemeint. Die Frage hat eher darauf abgezielt, ob im Host-System irgendwelche Kernel-Meldungen zu dem Zeitpunkt erscheinen, wenn die Fehlermeldungen im Gast-System auftauchen. Diese Meldungen könnten z.B. auf Probleme in der Virtualisierung hindeuten.

Die Karte wurde durchgereicht an den Gast und der Treiber im Hostsystem geblacklistet. Da taucht im Logfile des Hostsystems leider gar nichts mehr dazu auf. Ich habe aber übrigens nochmal meine "alte" omv3-bare-metal-ssd eingebaut und nochmal geprüft, was das Log mir ausgibt, wenn die Platten im standby sind und über eine smb-Freigabe darauf zugegriffen wird. Es entsteht exakt derselbe Fehler. Somit würde ich nun ausschließen, dass das in irgendeiner Form an Proxmox oder der Virtualisierng liegt.

Den Teil verstehe ich nicht, was meinst du mit kvm-to-ssd?

Ich wollte die virtuelle Maschine auf eine nackte ssd klonen, so dass ich die virtuelle Maschine ohne Virtualisierung direkt auf bare metal testen kann. Da der Fehler aber auch mit meiner omv3-bare-metal-ssd existiert, hat sich das nun erledigt.

Dass das Aufwand ist, ist klar. Es ist meistens Aufwand, wenn man ein (rätselhaftes) technisches Problem genauer untersuchen möchte ;-).
Ich habe auch erst einmal nur ein paar Punkte/Fragen als "mögliche Ansätze" aufgeschrieben, die mir beim Nachdenken über das Problem in den Sinn gekommen sind - ungeachtet davon, ob die Untersuchung jeweils praktikabel oder einfach ist.
Dieser Punkt im Speziellen ist aber vielleicht gar nicht so aufwändig, wie man zunächst vermuten würde, das hängt etwas von deiner genauen Einrichtung ab. Die kenne ich ja nicht im Detail. Bei so großen Festplatten benutzt man i.d.R. ja GPT und dort wiederum empfiehlt es sich grundsätzlich eine EFI-Partition einzurichten. Wenn du das gemacht hast, hättest du ein paar hundert MB auf jeder Platte quasi ungenutzt brach liegen (sofern diese nicht zum Booten gebraucht werden). Für ein kurzes Experiment würde dieser Speicherplatz ausreichen, ohne dein Array mit den Nutzdaten aufzulösen.
Ich habe auch mal gelesen, dass es bei zfs die Möglichkeit gibt, im zfs-Pool ein Block-Device zu erstellen, dass dann kein zfs-Dateisystem nutzt (zvol). Dort könnte dann auch ein anderes Dateisystem ausprobiert werden. Ob das einen Unterschied macht?

Puh, das ist mir momentan zu verrückt.

Eine weitere Frage, die sich mir im Nachhinein noch gestellt hat ist, ob deine Festplatten nach dem ersten Zugriff im Standby (hdparm -y) alle gleichzeitig anlaufen oder nacheinander? Eventuell kann man das durch fühlen oder Ohr-dran-halten erkennen. Ansonsten ein paralleles dd if=/dev/sdx of=/dev/null bs=4096 count=1 auf allen schlafenden Festplatten und schauen, ob die einigermaßen gleichzeitig fertig sind (bei mehrmaligen Versuchen Cache vorher leeren).

Die FEstplatten laufen alle nacheinander an. Kann man das irgendwo beeinflussen? Das könnte das Problem sein. Bis alle 8 Platten nacheinander eingeschaltet wurden, vergeht ca. 1 Minute. Ich kann mir schon vorstellen, dass das für zfs einfach viel zu lange dauert.

Wie gesagt, alles nur ein paar Ideen. Ob du das weiterverfolgen möchtest oder nicht, bleibt natürlich ganz dir überlassen. Man könnte natürlich auch einfach abwarten und hoffen, dass die zuständigen Entwickler das Problem lösen...

Da das Problem momentan keinen wirklichen Impact verursacht, belasse ich es erstmal dabei. Übergangsweise werde ich die Festplatten wohl erstmal nicht mehr schlafen legen. Das ist nur schade um den Stromverbrauch.

gae hat in einem anderen Thread geschrieben, dass der IT-Mode bzw. die IT-Treiber prinzipiell besser gepflegt seien und stabiler liefen. Das wäre vielleicht auch noch interessant, ob das in deinem Fall einen Unterschied macht? Ich kann das leider noch nicht beurteilen.

Erlischt dann die Garantie? Wenn du das erfolgreich durchgeführt hast, kannst du mir hier gern erläutern, wie du das bewerkstelligt hast. Ich habe keinen Bock mir das Mainboard zu zerschiessen und schon wieder eine RMA auszulösen.

Auf jeden Fall danke ich dir sehr für die Infos und deine Erfahrungswerte. Damit sind die letzten Zweifel beseitigt und ich kann bei meinem Projekt weitermachen!

Kein Thema, gerne. Denk an mich, wenn du den IT-Mode geflasht hast.

Gruß

 

[Morpheus2200]

Auch wenn das jetzt etwas spät kommt, BIOS update über IPMI mit SUM (Supermicro Update Manager) war bei dem Board keine option?
Ich habe damit letztens 2 Rechner wiederbeleben können.
Wenn man lieb fragt bekommt man mit etwas Glück für eine MAC eine Testversion.

 

[hoppel118]

Hm..., keine Ahnung, wo jetzt der genaue Unterschied zwischen SUM und der SFT-OOB-LIC ist. Mit der SFT-OOB-LIC kann man BIOS-Updates per IPMI machen. Da diese Lizenz damals bei meinem Reseller 2 Wochen Lieferzeit hatte und ich nicht wusste, ob das BIOS-Update per IPMI klappt, habe ich auf den Test verzichtet, und das Board direkt in die RMA geschickt.

Mittlerweile habe ich Lic und ein BIOS-Update per IPMI durchgeführt. Die gewünschte TV-Karte wird allerdings weiterhin nicht erkannt.

Gruß

 

[Morpheus2200]

Weisst du noch was die in etwa für die Lizenz haben wollten?

 

[hoppel118]

Mainboard "Supermicro X11SSH-CTF" durch BIOS-Update geschrottet?

Ich habe damals 25,62€ bei sona.de bezahlt. Du musst bei der Bestellung die MAC-Adresse deines IPMI-Interfaces angeben. Nach ca. 3 Tagen wurde mir die Lizenz per Email übermittelt. Derzeitig ist die Lizenz dort etwas günstiger.

https://www.sona.de/.152048043-Supermicro-SFT-OOB-LIC-Lizenz-für-OOB-BIOS-Management,-1-Node

@mod: Ich hoffe der Link ist erlaubt, wenn nicht bitte wieder entfernen.

 

[hoppel118]

Moin @KevX

schau mal, zufällig habe ich gerade folgendes gefunden:

http://www.vladan.fr/supermicro-sin...ding-lsi-3008-hba-on-the-x10srh-cln4f-part-3/

Ohne zu wissen, ob dann die Garantie erlischt, gehe ich da aber nicht bei.

Gruß Hoppel

 

[KevX]

Ich wollte die virtuelle Maschine auf eine nackte ssd klonen[...]

Sollte normal gehen, in dem du einfach deine Systempartition klonst/kopierst - im Zweifel per dd.

Die FEstplatten laufen alle nacheinander an. Kann man das irgendwo beeinflussen? Das könnte das Problem sein. Bis alle 8 Platten nacheinander eingeschaltet wurden, vergeht ca. 1 Minute. Ich kann mir schon vorstellen, dass das für zfs einfach viel zu lange dauert.

Okay - eine Minute ist da echt viel Zeit. Damit habe ich nun wirklich nicht gerechnet. Dann ist klar, dass das zu Fehlern kommt, wenn ZFS nicht berücksichtigt, dass das Anlaufen entsprechend Zeit benötigen darf.
Könnte entweder am Controller, an ZFS oder am Kernel liegen ;-(.

Wenn ich mir noch mal deine Kernel-Meldungen auf Github anschaue, würde ich tippen, dass der Controller für die Verzögerung verantwortlich ist und der Linux Kernel sich über den Fehler beschwert.
Hat der Controller irgend eine Einstellmöglichkeit (Bios-ähnlich oder so), in dem man das Anlaufverhalten einstellen kann?

Wegen dem Timeout gibt es da eine Kernel-Einstellung. Das ganze wird über das /proc/ Interface konfiguriert/ausgelesen:

/sys/block/sdX/device/timeout

Die Ganzzahl gibt die Anzahl der Sekunden des Timeouts an. Standardwert sind 30 Sekunden. Probiere das testweise mal auf deutlich über deiner Anlaufzeit zu stellen, z.B. 300 = 5 Minuten. Macht das einen Unterschied? Beachte: Die Einstellung ist nach einem Neustart wieder zurückgesetzt.

Klassischerweise stellt man den Timeout hoch, wenn man Desktop-Grade Festplatten für ein Raid benutzt, weil diese sehr lange versuchen einen nicht lesbaren Sektor doch noch zu lesen (z.B. WD Green). Wohingegen Festplatten für Raids/NAS (z.B. WD Red, "RAID-Fehlerbehebungsprotokolle") dieses Verhalten nicht haben und deutlich schneller einen Lesefehler melden. Wodurch man den Timeout niedrig lassen kann. In deinem speziellen Fall könnte der Timeout aber noch eine zweite Rolle spielen, unabhängig von der verwendeten Festplatte.

Hier noch zwei weiterführende Links:
kernel - Can the hard drive timeout be disabled in Linux (attempting task abort) - Unix & Linux Stack Exchange
https://kb.vmware.com/selfservice/m...nguage=en_US&cmd=displayKC&externalId=1009465

Erlischt dann die Garantie? Wenn du das erfolgreich durchgeführt hast, kannst du mir hier gern erläutern, wie du das bewerkstelligt hast. Ich habe keinen Bock mir das Mainboard zu zerschiessen und schon wieder eine RMA auszulösen.

[...]Denk an mich, wenn du den IT-Mode geflasht hast.

Der Supermicro-Support ist irgendwie nicht der Schnellste... Ich habe schon vor Ewigkeiten eine Mail genau wegen dem Thema dort hingeschickt. Inzwischen habe ich zumindest eine Teil-Antwort.

Yes, the onboard LSI 3008 can support the IT mode.

Please find the IT/IR mode firmware on our Supermicro’s FTP
ftp://www.supermicro.com.tw/driver/SAS/LSI/3008/

Auf meine Frage bezüglich Garantie sind sie allerdings nicht eingegangen. Ich würde "Yes... support the IT mode" jetzt mal frei so interpretieren, dass das offiziell unterstützt wird und keine (negative) Auswirkung auf die Garantie hat.
Ich werde es jedenfalls ausprobieren und dann natürlich berichten. Wird aber voraussichtlich noch ein Weilchen dauern.
Irgendwo hatte ich mir zwischenzeitlich noch zwei, drei Links zu dem Thema notiert, aber die finde ich gerade nicht. Reiche ich noch nach, wenn sie mir wieder über den Weg laufen ;-).

schau mal, zufällig habe ich gerade folgendes gefunden:

Supermicro Single CPU Board for ESXi Home lab – Upgrading LSI 3008 HBA on the X10SRH-CLN4F - ESX Virtualization

Ohne zu wissen, ob dann die Garantie erlischt, gehe ich da aber nicht bei.

Das ist in der Tat ein sehr interessanter Link bzw. eine super Projekt-Dokumentation. Habe ich mir heute in der Mittagspause direkt mal angesehen. Dankeschön!

Viele Grüße

Kev

 

[hoppel118]

Okay - eine Minute ist da echt viel Zeit. Damit habe ich nun wirklich nicht gerechnet. Dann ist klar, dass das zu Fehlern kommt, wenn ZFS nicht berücksichtigt, dass das Anlaufen entsprechend Zeit benötigen darf.
Könnte entweder am Controller, an ZFS oder am Kernel liegen ;-(.

Wenn ich mir noch mal deine Kernel-Meldungen auf Github anschaue, würde ich tippen, dass der Controller für die Verzögerung verantwortlich ist und der Linux Kernel sich über den Fehler beschwert.
Hat der Controller irgend eine Einstellmöglichkeit (Bios-ähnlich oder so), in dem man das Anlaufverhalten einstellen kann?

Ich habe momentan ein beta-BIOS von Supermicro aus August 2016 laufen. Das kann man auf der Homepage nicht downloaden. Damit haben wir geprüft, ob meine DVB Karte damit ggf. zum Laufen zu kriegen ist. Hat aber leider auch nicht geklappt. Mit diesem BIOS ist das Bootverhalten anders (schneller) als zuvor. Ich sehe den LSI SAS-3008 Controller beim Booten nicht mehr. Somit komme ich nun auf dem herkömmlichen Weg nicht mehr in's Controller BIOS. Stattdessen kann ich direkt den Controller nun direkt aus dem Mainboard BIOS heraus konfigurieren. Dort finde ich allerdings keine Option für "staggered spin up". Laut meinen Recherchen müsste es diese Option dort aber geben. Das könnte also an der beta Version liegen. Es wäre schön, wenn du das mal bei deinem X11SSH-CTF prüfen könntest. Mit Strg+C während des Bootvorgangs müsstest du in das BIOS des LSI SAS-3008 kommen.

Die Ganzzahl gibt die Anzahl der Sekunden des Timeouts an. Standardwert sind 30 Sekunden. Probiere das testweise mal auf deutlich über deiner Anlaufzeit zu stellen, z.B. 300 = 5 Minuten. Macht das einen Unterschied? Beachte: Die Einstellung ist nach einem Neustart wieder zurückgesetzt.

Klassischerweise stellt man den Timeout hoch, wenn man Desktop-Grade Festplatten für ein Raid benutzt, weil diese sehr lange versuchen einen nicht lesbaren Sektor doch noch zu lesen (z.B. WD Green). Wohingegen Festplatten für Raids/NAS (z.B. WD Red, "RAID-Fehlerbehebungsprotokolle") dieses Verhalten nicht haben und deutlich schneller einen Lesefehler melden. Wodurch man den Timeout niedrig lassen kann. In deinem speziellen Fall könnte der Timeout aber noch eine zweite Rolle spielen, unabhängig von der verwendeten Festplatte.

Hier noch zwei weiterführende Links:
kernel - Can the hard drive timeout be disabled in Linux (attempting task abort) - Unix & Linux Stack Exchange
https://kb.vmware.com/selfservice/m...nguage=en_US&cmd=displayKC&externalId=1009465

Das ist eine wirklich interessant Information. Das habe ich mal geprüft und habe mir wie hier beschrieben eine udev-Regel gebaut, so dass 120 sec gewartet wird:

https://access.redhat.com/documenta...ling-scsi-command-timer-onlining-devices.html

Die Meldungen mit den IO-Errors bleiben leider bestehen. Danach befand ich mich aber kurz erstmal in einer Schockstarre! Mein Pool war suspended. Der Fehler ist anscheinend ebenfalls bekannt:

https://github.com/zfsonlinux/spl/issues/417
https://github.com/zfsonlinux/zfs/issues/1370
https://github.com/zfsonlinux/zfs/issues/1857

Wie in den Issues erwähnt, war nach einem Reboot alles wieder gut. Puuuh

Wenn ich ehrlich bin, sehe ich derzeitig nur noch eine mögliche Lösung. Ich muss es irgendwie schaffen, die Festplatten gleichzeitig aus dem standby zu holen. Ggf. kann man den Controller auch so konfigurieren, dass 2x nacheinander 4 HDDs gleichzeitig oder 4x nacheinander 2 HDDs gleichzeitig gestartet werden. Das müsste eigentlich, wenn ich das richtig ergoogelt habe, mit diesem Controller möglich sein.

Auf meine Frage bezüglich Garantie sind sie allerdings nicht eingegangen. Ich würde "Yes... support the IT mode" jetzt mal frei so interpretieren, dass das offiziell unterstützt wird und keine (negative) Auswirkung auf die Garantie hat.
Ich werde es jedenfalls ausprobieren und dann natürlich berichten. Wird aber voraussichtlich noch ein Weilchen dauern.
Irgendwo hatte ich mir zwischenzeitlich noch zwei, drei Links zu dem Thema notiert, aber die finde ich gerade nicht. Reiche ich noch nach, wenn sie mir wieder über den Weg laufen ;-).

Schaue bitte vor und nach der Umstellung auf IT-Mode, ob du irgendwelche Einstellungsmöglichkeiten für "staggered spin up" im Controller Bios findest.

Das ist in der Tat ein sehr interessanter Link bzw. eine super Projekt-Dokumentation. Habe ich mir heute in der Mittagspause direkt mal angesehen. Dankeschön!

Hier noch so ein interessanter Link:

https://forums.freenas.org/index.ph...x11ssh-ctf-über-integrierte-uefi-shell.42558/

Gruß Hoppel

 

[Trambahner]

Bei meinem X10SL7 (LSI 2308 @ IT-Mode) kann ich im Controller-Bios das staggered Hochfahren der Platten konfigurieren; insofern würde ich das gleiche beim LSI 3008 erwarten.

 

[hoppel118]

Ok, danke für die Info. Handelt es sich bei deinem 2308 um einen Onboard-Controller?

Wenn ja, hast du diesen selbständig in den IT Mode gebracht?

Mein 3008 befindet sich im IR Mode.

Gruß Hoppel

 

[Trambahner]

Das ist bei mir der Onboard-2308 auf dem Board, der 3008 ist ja der direkte Nachfolger. Das X10SL7-F ist ja de facto der Haswell-Vorgänger des X11SSH.

Wenn ich mich recht entsinne, kam bei mir mit IR-Firmware und hab ich dann auf IT umgeflasht das der Einsatz für ZFS von Anfang an klar war.
Btw, mit einem Supermicro X11SSH-CTF hat mein Spieltrieb in mir auch schon geliebäugelt (und auch mit einem EPC612D4U-2TR8; aber dann brauch ich halt auch wieder Ram und CPU. 10Gbit hab ich halt durch eine Intel X540-Nic ergänzt.

 

[KevX]

Laut meinen Recherchen müsste es diese Option dort aber geben. Das könnte also an der beta Version liegen. Es wäre schön, wenn du das mal bei deinem X11SSH-CTF prüfen könntest. Mit Strg+C während des Bootvorgangs müsstest du in das BIOS des LSI SAS-3008 kommen.

Die Optionen habe ich natürlich schon längst gefunden und mir als Hinweis für dich notiert ;-). Leider hatte ich dann aber letzte Woche doch keine Zeit mehr zum Posten.
Da du jetzt aber explizit danach gefragt hast, habe ich dir die Optionen zusätzlich per Screenshot dokumentiert (IR Auslieferungszustand):

1. Übersicht:


2. Details:


3. Eigenschaften:


4. Erweiterte Eigenschaften:


5. Timing Einstellungen:


6. Bios Übersicht:


Wie du siehst (Nr. 5) werden bei mir in der Standardeinstellung zwei Laufwerke gleichzeitig gestartet und es ist eine Verzögerung von 2 Sekunden konfiguriert. Daneben gibt es noch einen IO Timeout von 10 Sekunden (Nr. 4).


Ansonsten läuft das Board bisher einwandfrei. Hardware-Installation und Konfiguration waren ziemlich einfach. Mein bisheriges Linux System konnte ich einfach übernehmen (Festplatten umbauen und läuft). Die einzige Anpassung war das Deaktivieren von KMS, weil die Grafiktreiber vom Kernel 4.4 mit der Kombination aus (nicht verwendeter) Skylake-Grafikeinheit und IPMI-Grafik nicht ganz zurecht kam. Die Folge war ein schwarzer Bildschirm während des Boot-Vorgangs. Mit den Kernel Boot-Optionen "nomodeset i915.modeset=0" läuft aber alles einwandfrei.

Die unkonfigurierten Festplatten am LSI Controller werden von Linux trotz IR-Modus erkannt und sind einzeln ansprechbar. Somit steht einer Verwendung mit BTRFS bzw. mdadm nichts im Wege. Ich werde trotzdem noch die IT-Firmware ausprobieren, da ich die integrierten Raid-Funktionen des Controllers sowieso nie verwenden werde.

IPMI ist insgesamt eine feine Sache, die Fernwartung (und das Erstellen von Bios-Screenshots, siehe oben) wird dadurch wirklich sehr angenehm.
Allerdings muss ich mich erst noch an die verhältnismäßig lange Bootzeit gewöhnen, weil erst einmal alles initialisiert werden muss.

Der Kaltstart - Powerbutton bis SSH-Login - dauert 4 Minuten und 5 Sekunden. Vorher (Desktop-Board) war das deutlich unter einer Minute. Das ist zwar insgesamt kein Problem, sobald alles eingerichtet ist. Aber wenn man am Ausprobieren ist und dauernd zwischen Bios, LSI-Controller-Firmware, Live-System und normalem System hin und herwechselt, kann das schon relativ nervig werden. Zumal der Zeitpunkt zum Drücken der richtigen Tastenkombination standardmäßig schon sehr kurz ausfällt. Da benötigt es schon einmal 2-3 Anläufe, bis man überhaupt alle Möglichkeiten gelesen hat (zumal zu verschiedenen Zeitpunkten des Boot-Vorgangs jeweils verschiedene Optionen bestehen).

Eigentlich war geplant, das vorhandene System auf eine M.2 SSD umzuziehen, damit die Festplatten bei Nichtbenutzung schlafen gehen können.
Leider stellt sich das als nicht ganz so einfach dar, wie ursprünglich gedacht:
Im Moment suche ich verzweifelt nach einer passenden M.2 SSD für das Mainboard...

 

[hoppel118]

Cool, du hast geantwortet. Das habe ich irgendwie gar nicht mitbekommen. War auch schon länger nicht mehr hier im Board. Schön, dass es alles bei dir läuft.

Da ich immer noch noch auf der Beta-BIOS-Firmware von Supermicro bin und diesen Zustand gern wieder auflösen möchte, habe ich gerade mal geprüft, ob es mittlerweile eine neue Firmware gibt. Siehe da, es gibt die Revision R2.0. Weiß hier jemand wo ich ein Changelog dazu finde bzw. hat diese neue BIOS-Revision hier schon jemand im Einsatz?

Gruß Hoppel