In Vorbereitung auf Das Boot 3.0

Status
Für weitere Antworten geschlossen.
Da kommt bald wohl noch eins *suspect*...

--- Update ---

Und wenn man das oben verlinkte installiert, werden Optionen aus dem BIOS entfernt (ECC-Options und RAM-Speed-Zeugs).
 
Added support for hidden item "Memory Corrected Error Enabling" and function that disabled CMC source to prevent OS from receiving the CECC error.


Für ein Server Board macht es kein Sinn die ECC Funktion abzuschalten, also Fail seitens des Hersteller. Ohne wenn und Aber, da es hier eine Kompromisse geben darf ! :]


Bei einem Desktop Board ist allerdings dieser Parameter durchaus, Akzeptabel ;)
 
Zuletzt bearbeitet:
Ich werde aus dieser Änderung auch nicht schlau, zumal nach dem Update weniger Optionen als vorher zur Verfügung stehen. Auf jeden Fall arbeiten SM und AMD aktuell an diesem Board.

--- Update ---

Und 100% stabil ist die Kiste auch nicht, hatte im Testbetrieb schon zwei Abstürze. Teste gerade Server 2019, weil ich vermute, dass das "alte" Server 2016 da ein wenig hinterherhängt. Wenn diese Dinge weg sind, dann werde ich wohl weitere Systeme ordern.

Vielleicht noch interessant zu wissen [Quelle]:

ECC injection is a test method to "inject" fake errors into the RAM to determine if ECC RAM is correcting memory faults.
MemTest86 supports ECC injection on some platforms.

For the AMD EPYC CPUs it seems ECC injection support in the specifications for the CPU, but they also say, "Error injection is disabled on production parts".

The behavior of MemTest86 V7.5 is to detect ECC injection support as being available, but as per the spec's, it seems to be disabled if you try and actually use it.
i.e. It won't work on production CPUs. Which implies it can maybe work on engineering samples.
 
Zuletzt bearbeitet:
Hmm, hört sich nicht so gut an. Hoffen wir mal das das Zeug noch stabil ans laufen zu bekommen ist. Wäre ein Jammer wenn Supermicro wonach es hier aussieht ein unreifes Produkt auf dem Markt wirft, mit dem Versuch durch UEFI-Updates zu kaschieren. Mit meinem ersten Ryzen System hatte ich da erstaunlich wenig Probleme. Mit jedem Update wurde es besser, konnte aus dem Ram alles rausholen und ECC funktioniert auch.


Schade ist allerdings das Memtest v 7.x auf dem Board das ECC nicht erkennen mag, und darauf gezielt Fehler provozieren zu lassen die er dann korrigieren sollte. Unter Windows tut er es ja, dank der Einstellmöglichkeiten kann ich im Gegensatz zum Server Board "Fehler" provozieren lassen, indem man einfach die Spannung senkt oder den Takt erhöht, und LinX reicht hier schon aus und wartet ab bis die WHEA Errors kommen. Einfacher geht's nicht.

Memtest reicht hier leider nicht aus, wenn da schon ab UEFI-Mode Fehler bringt kann man von ausgehen das Board oder Speicher defekt sind wenn dies im Standard Betrieb auftreten mag. In Windows bitte dann LinX und den maximalen möglichen Ram zuweisen lassen. Mit Prime oder Memtest für Windows kann ich den Ram nicht ausreichend auslasten !
 
Zuletzt bearbeitet:
Ich weiß nicht, ob unreif das richtige Wort ist, etwas stiefmütterlich behandelt vielleicht. Aber kann man es SM verdenken? Sooo viele EPYCs habe ich in freier Wildbahn noch nicht gesehen und z.B. Boincstats listet verdammt wenig aktive EPYCs (wenn man das als Indiz heranziehen möchte). Das SM ist schon grundsolide und bis auf ein schmales BIOS und einen Fauxpas beim RAM läuft das alles recht ordentlich. Ich hatte da mit so manchen Intel-Pendants größere Probleme, die teilweise nie gelöst wurden. Erfreulich ist, SM hat sich meiner sehr schnell und sehr hilfsbereit angenommen und auch AMD hat innerhalb eines Tages reagiert.
 
Ich nenne es halt Unreif, mache da wie gesagt kein Unterschied zwischen Desktop und Server und Hersteller sprich selbst wenn die Platine aus Gold bestehen würde. Die Erfahrungen mit neuen Desktop Boards die ich in den Jahren gekauft habe, waren im Grunde die gleichen wie du sie jetzt hier hast. Als ich das Asus B350 Prime Plus gekauft habe, lief es quasi schon relativ stabil, weil es schon länger am Markt war.

Habe nun noch ein Asus B350 TUF Gaming hier, mit Trident-Z 3200 CL-14 und einem Ryzen 2600 (Hoffe das schon das schon neues UEFI drauf ist) mal sehn wie das Zeug laufen wird. Da es eine Zocker Kiste für ein Kollegen wird, wurde auf ECC Ram verzichtet.


Mit dem letzten UEFI Update, und dem Memtest 7.5 sieht es nun so aus. Leider habe ich kein Pro Version :)

20180603_01544650pg7.jpg



Nun mit Pro Version

20180603_025244x0p4o.jpg



Nun bitte der EPYC :)
 
Zuletzt bearbeitet:
Wie schaut es den nun aus, ab wann kann das Boot ins Wasser gelassen werden.
 
Das Austausch-RAM ist da, der unmittelbare WHEA-Fehler alle 5 Sekunden taucht nicht mehr auf. Werde das System jetzt noch ein wenig mit der bestehenden Windows-Installation quälen, dann könnte tomturbo loslegen :D
 
Hört sich gut an, kannst ja z.B mal 60 LinX Durchläufe machen. Es lastet Cache, CPU, Ram extrem aus. Habe bisher noch kein Alternativ Programm gefunden, wenn es da keine Fehler findet, sollte es schon recht stabil sein.
 
Ich habe ein paar Fragen und eine Bitte. Der Hintergrund meines Posts ist folgender: Wir haben in der Firma unter anderem einen Server (Barebone) von SuperMicro im Einsatz, dessen Basis das Board X10SLL-F ist. Beim Einrichten und Benutzen der integrierten IPMI-Funktion - konkret des Java iKVM Viewer - ist uns etwas aufgefallen, das wir nicht unerwähnt lassen möchten: Das Passwort für den IPMI-Benutzer ist im Klartext in der Prozessliste zu sehen! Hier ein Screenshot, der das Problem zeigt:

Im Bild sieht man die Kommandozeile des Java iKVM Viewer, gestartet via SuperMicro IPMIView (für Windows); der verpixelte Bereich nach dem Benutzer wartung ist das Passwort.

Auch wenn das Board in unserem Fall schon einige Jahre auf dem Markt ist, so ist das IPMIView und der damit einhergehende Java iKVM Viewer für (fast) alle SuperMicro-Server/-Boards dasselbe/derselbe. Daher gehe ich ganz stark davon aus, dass dieses Verhalten bei allen SuperMicro-Servern/-Boards zu finden ist. Nun meine Fragen und gleichzeitig die Bitte:
  • Nutzt ihr die Remote-Administration via IPMI (vor allem, wenn das OS nicht gebootet ist)?
  • Könnt ihr die Beobachtungen auf dem EPYC-Board nachvollziehen?
  • Wenn dem so ist, was haltet ihr davon? Könnt ihr das an SuperMicro melden, sofern ihr das ebenfalls problematisch seht?
Grüße
Dalai
 
Ist auch beim H11SSL-NC so; in der Tat!
 
Anbei weiß heute jeder, vielleicht nicht jeder Server-Admin das Java wie auch Flash "Unsicher" sind, und heute nicht mehr verwendet werden sollte. Würde daher Wartungssoftware nutzen, die nicht auf JAVA aufbaut. Das was auf einem Desktop schon für unnötige Sicherheitslücken sorgt, sollte auf einem Server nicht verwendet werden.

Flash wurde durch HTML5 ersetzt, und auch für Java gibt's mit Sicherheit Ersatz.
 
Da ich eh gerade mitm Support zu Gange bin, habe ich das mal auf die Agenda gesetzt.
 
Java ist nur dann pauschal unsicher, wenn man es im Internet im Browser zulässt.
Lokal dürfte die Gefahr von Schadsoftware ziemlich gering sein - die müsste ja dann Jemand auf den eigenen Server oder Rechner platzieren, damit sie aufgerufen wird.

Das ist irgendwie der gleiche Quark wie die angeblichen AMD-Sicherheitslücken, die Admin-Rechte brauchen.
 
Anbei weiß heute jeder, vielleicht nicht jeder Server-Admin das Java wie auch Flash "Unsicher" sind, und heute nicht mehr verwendet werden sollte.
Was vor allem Sicherheitslücken hat und sie einfacher ausnutzbar macht, ist das Zeug im Browser - um die Plugins geht's hier aber nicht. Oder willst du mir sagen, ich solle TV-Browser nicht mehr nutzen, nur weil es Java-basierende Software ist?

Würde daher Wartungssoftware nutzen, die nicht auf JAVA aufbaut.
Ist bei FSC ebenfalls Java-basierend, und zwar ohne Passwort im Klartext irgendwo! Wahrscheinlich ist der Fernwartungskram bei Dell und HP ebenfalls Java-basierend, aber mangels Erfahrung damit kann ich dazu keine Aussage treffen.

Das was auf einem Desktop schon für unnötige Sicherheitslücken sorgt, sollte auf einem Server nicht verwendet werden.
IPMIView wird normalerweise nicht auf dem Server installiert sondern auf dem Rechner, von dem aus man auf das IPMI des Servers zugreifen will, also irgendein Client bzw. ein Wartungssystem.

Flash wurde durch HTML5 ersetzt, und auch für Java gibt's mit Sicherheit Ersatz.
Das nützt dir gar nix, wenn die Software Java voraussetzt, unabhängig davon, ob das nun die JRE von Oracle ist oder die von jemand anders. Darum geht's außerdem überhaupt nicht. Auch Java-Software kann man ordentlich schreiben, ohne Passwörter im Klartext irgendwo zu hinterlassen.

@Sightus:
Danke fürs Prüfen und schonmal danke fürs Nachhaken(wollen)!

Grüße
Dalai
 
Auf dem Screenshot sieht das doch so aus, als ob das Passwort quasi nur Teil der Kommandozeile ist?
Also im Grunde kann man zusätzliche Optionen doch beim Programmstart völlig unabhängig von der Programmiersprache mitgeben.
Sprich selbst mit Assembler hätte Jemand auf die merkwürdige Idee kommen können, Passwörter im Klartext zu übergeben.
 
Java ist nicht unsicher!
Wer das verbreitet hat keine Ahnung von Java!

Wenn eine dämlich programmierte Software ein Passwort in der Kommandozeile anzeigt liegt das am Programmierer und nicht an der darunterliegenden Middleware.
Java ist per se sicherer als andere Software, da hier prinzipiell eine Sandbox läuft.

@Dalai
Java Applets in Browsern sind ab einer bestimmten Java und/oder Browserversion sowieso abgeschafft worden.
Nur noch uralt Browser und Java Versionen unterstützen das, welche eh nicht mehr eingesetzt werden sollten.
Die Sicherheitslücke sitzt quasi vor dem Rechner :P
 
Zuletzt bearbeitet:
Mir wurscht nutze kein Java und kein Flash mehr auf meinem System, und nutze keine Anwendungen die das nutzen, oder habe diese Anwendungen gelöscht. Solange die Rechner am Netz hängen, besteht immer eine Potenzielle Gefahr. Es sei den man guckt durch die Rosa Rote Brille. Wer sich auf andere verlässt kann das ja gerne tun, ich verlass mit nur auf mich selbst, nutze keine Cloud etc. Gut das ich nicht das Fachwissen wie mein Bruder habe, der damals für Telefónica als Netzadmin die Aufgabe Sicherheitslücken im System zu finden, da hat er mit Stories erzählt wovon einige hier nur träumen konnten. Oder jemand mal versucht hat ihn daheim zu hacken, der jenige hatte nix zu lachen.
 
Java Applets in Browsern sind ab einer bestimmten Java und/oder Browserversion sowieso abgeschafft worden.
Nur noch uralt Browser und Java Versionen unterstützen das, welche eh nicht mehr eingesetzt werden sollten.
Die Sicherheitslücke sitzt quasi vor dem Rechner :P
Das weiß ich doch :). Nur um's nochmal für alle Leser zu verdeutlichen: Es geht nicht um ein Java Applet sondern um eine lokal laufende Java-Anwendung.

Grüße
Dalai
 
Vielen Dank für die Anregungen; aber Stresstests hab ich genug 8)

Ich bin mir noch gar nicht so schlüssig, ob wir IPMI überhaupt dauerhaft angeschlossen lassen sollten. Ich mein, wir haben jetzt 13 Jahre lang ausgehalten ohne IPMI. Manchmal wäre es hilfreich gewesen, aber wer weiß wie oft wir schon gehackt worden wären, wenn wir das Uralt-Board mit Uralt-Sicherheitsstandard am Internet hängen hätten. Es wäre mir wohler, wenn der Support vor Ort IPMI nur bei Bedarf anstöpseln würde. Dann ist es mir auch wurscht, ob da ein Passwort im Klartext übertragen wird oder nicht. Wobei das an sich natürlich schon der Hammer ist :o
 
Ja, wir werden es angeschlossen lassen damit wir auch wirklich restarten können. Und ins bios können. ;D
Hat aber nichts mit einem ipmiviewer zu tun, das geht per html alles auch.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Zurück
Oben Unten