Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Mehr Sorgen würde ich mir machen, dass die allermeisten SATA-SSDs noch mit alter, nicht ganz so langlebiger Speichertechnik arbeiten, von daher dürften sie nicht so lange halten. Und sie sind insofern einfach sehr teuer im Vergleich.
Danke euch zwei. Dann wäre das auch eine Option auf dem Board.
Ja bei ZFS in einem Mirror hab ich schon Erfahrung mit Consumer SSDs.
Wegen den Sync-Writes war das am Ende eine Katastrophe.
Hier gibt es für mich nur noch hochwertige Enterprise mit PLP.
Beitrag automatisch zusammengeführt:
Ob es durch die heute viele schnelleren Consumer SSDs besser ist weiß ich nicht. Test ist gut 3 Jahre her.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe jetzt gestern Mal die weiteren Teile für meinen neuen Server in einer Tabelle erfasst.
Erschreckend war, dass RAM, CPU doch ordentlich zu Buche schlagen für eine „alte“ Plattform.
Hat sich jemand ggf. auch überlegt gleich auf AM5 mit z.B. dem Asus Pro B650M-CT-CSM zu gehen.
ECC RAM ist nicht viel teuere und CPUs (APU) mit mehr als 6 Kernen viel günstiger.
Sind hier am Ende mehr Nachteile als nur kein IPMI?
Natürlich nicht. Natürlich bekommt man auch halbwegs aktuelle Technik, da schrieb ich ja: "relativ teuer".
Modelle wie die MX500 haben bereits 7-8 Jahre auf dem Buckel. Ja, ich weiß, davon hat es auch ein refreshtes 4TB-Modell im Programm. Kostet aber wie eine 990 Pro mit 4TB knapp 300 Euro. IOPS ist der relevanteste Aspekt - ich kenne kein SATA-Produkt, was konkurrenzfähig zur guten NVMe-Palette wäre.
Man muss auch bedenken: Kontext dieses Threads ist ein Board für knapp 40 Euro inkl. Versand. Von daher habe ich auch industrial SATA-SSDs nicht betrachtet.
Du hast dich am Ende dann für AM4 entschieden, weil du wahrscheinlich noch alte HW hattest die du weiterverwenden konntest?
Hast wahrscheinlich nicht alles neu gekauft, wie wahrscheinlich die meisten hier?
Hat hier jemand seinen Storage für die VMs aus SATA-SSDs realisiert und kann was zur Performance sagen.
Die maximale Datenrate im Vergleich zu NVME ist natürlich viel schlechter, aber in der Praxis kleine Dateien sollten genauso schnell sein. Somit als VM Storage ggf. in Ordnung.
Richtig oder seht ihr das anders und für VM Storage nur NVME?
Du hast dich am Ende dann für AM4 entschieden, weil du wahrscheinlich noch alte HW hattest die du weiterverwenden konntest?
Hast wahrscheinlich nicht alles neu gekauft, wie wahrscheinlich die meisten hier?
Nein, weder noch.
Für mich ist das sinnigste, das Gigabyte MJ11-EC1 zu verwenden, denn da habe ich alles da - inklusive sehr günstigem RAM und passendes Gehäuse. Einzig was mich etwas ärgert sind die geringen Erweiterungsmöglichkeiten. Ein AM5-System wäre da sehr reizvoll, aber realistisch eher in der Kategorie "Spielerei" für mich zu sehen.
Ende des Jahres steht ein Umzug an und vielleicht auch eine Erweiterung des HomeServers, vielleicht wird's dann nochmal spannend
falls mein eigenes Geschrieb zu Verwirrung geführt haben sollte - der Meinung würde ich mich anschließen, wenn das SATA-Zeugs schon da ist oder günstig kommen kann.
Laut den Releasenotes war da schon etwas seit F8, aber ob das gleichzusetzen mit "offzieller Support" ist? Nach Lesart würde ich eigentlich sagen, dass ja. Wie denkt ihr dazu?
Joa... Aber benötigt der HomeUser hier der sich ein Board für 35-100€ kauft das unbedingt? Welche Features sind denn da so wichtig?
Ist das nicht eher Enterprise level für 500-700€ baords?
Ich hab ja gerade mal das dritte MC12-LE0-System mit nem 5600G zusammen gestöpselt und liege da im idle bei insgesamt 18W (430W ATX Power Supply, eine SATA-SSD, ein Ram-Riegel - sonst nüschts drin&dran). OS ist allerdings Windows 11.
Joa... Aber benötigt der HomeUser hier der sich ein Board für 35-100€ kauft das unbedingt? Welche Features sind denn da so wichtig?
Ist das nicht eher Enterprise level für 500-700€ baords?
Was einem wichtig ist, ist glaube ich ziemlich individuell Ich wollte nur das Gleichsetzen von iKVM und IPMI torpedieren, weil das "ich kann den PC bedienen, als wuerde ich gerade vor ihm sitzen"-Feature vielleicht fuer viele Leute den obersten, offensichtlichsten Nutzen von OOB-Management via IPMI darstellt, aber es damit halt nicht getan ist. Ich finde es z. B. sehr Hilfreich ein System Event Log (SEL) zu haben, das mir unabhaengig vom Host-OS ein Tagebuch ueber ggf. bedenkliche Ereignisse (Komponenten-Fehler im Betrieb, unerwartete Reboots/Power Cuts, etc.) bietet. Auch dass ich die gesamte Sensorik des Hosts via IPMI auslesen kann, das Host-BIOS-ROM flashen, die Host-POST-Codes interpretieren... das sind alles Features, die schnell einmal wichtig (oder zumindest sehr praktisch) werden koennen, die man mit so einer PiKVM-artigen Dranstoepsel-Loesung prinzipbedingt kaum kriegen kann.
Keine Garantie! Das Risiko ob das ein zuverlässiger Verkäufer ist muss jeder selbst wissen! Ich habe das in der Vergangenheit immer so gehandhabt meist "zu PayPalen" und nachgefragt ob die einen Memtest laufen lassen können. Und wenn nicht, wie es aussieht wenn bei meinem Test Fehler auftauchen.
Heute muss ich mir mal ein bisschen Frust von der Seele tippen hier :')
Wie sich manche erinnern, arbeite ich ja (ja, immer noch! bzw. in den letzten Tagen mit wiedererstarktem Eifer ) am Port von OpenBMC auf dieses Board. Die letzten paar Abende waren eigentlich gepraegt von schoenen Fortschritten. Ich hab mich auf die DeviceTree-/Kernel-Seite der OpenBMC-Firmware konzentriert und Userspace-Sachen (d. h. die Integration der Kernel-seitigen Features in das, was man via IPMI, Webinterace etc. ansprechen und so via OpenBMC als "User" bzw. Admin nutzen kann) auf die lange Bank geschoben. Das hat zu einigen kleinen Durchbruechen gefuehrt: Die I2C-Configs sind jetzt ofenbar soweit korrekt, dass ich fuer die Spannungs- und Temperatursensoren am Board nun (bei manchen mehr, bei manchen aber auch weniger ) sinnvolle Werte auslesen kann. Ich kann die PWM-Werte aller Fan-Header am Board via sysfs regeln. Ich kann die ID-LED des Board per sysfs an- und ausschalten. Alles notwendige Vorarbeit, um OpenBMC-Userspace so konfigurieren zu koennen, dass eine funktionstuechtige OpenBMC-Distro entstehen kann.
Dabei hat mich immer wieder geaergert, dass ich die Ethernet-Konfiguration weder in u-boot, noch in Linux 100% korrekt hinbekommen hatte - das hatte nervige Auswirkungen auf meinen Arbeitskomfort, weil die Bandbreite des Ethernet-Links durch irgendeine Unstimmigkeit in der Initialisierung des MII (oder vielleicht auch von NCSI - ich verstehe das alles leider nur zu ~10-20% ) ziemlich im Eimer - effektiv bei wenigen zig KByte/s - war. Also wollte ich das durch Trial und Error (mangels Board Schematics kenne ich keinen anderen Weg) fixen, und hab begonnen, unterschiedliche denkbare Kombinationen durchzuprobieren. Das hatte u. a. mal den Effekt, dass ich sowohl dem BMC als auch dem Host saemliches Ethernet-Schnittstellen permanent deaktiviert hatte - und mich lernen lassen, wie ich via XMODEM (den Namen/das Protokoll kannte ich zuvor nur aus Heldengeschichten von mir bekannten BBS-Altvorderen ) fette BLOBs mit viel Geduld ueber meine Debug-Konsole auf das BMC-Filesystem bekomme
Die letzte Kombination aus PHY-Configs, die ich gerade vorhin probiert habe, hat mich und meinen armen BMC aber leider in ein neues Gefaengnis gestubst, aus dem wir offenbar nicht mehr rauskommen koennen... u-boot initialisiert jetzt den AST2500 bis zum ersten Netzwerkinterface, und dann haengt sich die CPU in einem busy loop auf. Sieht so aus:
Dort haengt der BMC also ewig und tut nix mehr. Bloederweise ist das, NACHDEM u-boot die Mitigations fuer die Schwachstellen in der Host-BMC-Kommunikation durchgefuehrt hat - was bedeutet, dass ich den Chip mit der BMC-Firmware auch nicht via Host flashen kann.
Bleibt mir wohl nichts anderes uebrig, als zu versuchen, den n25q512ax3 mit der BMC-Firmware drauf per Flash-Programmer zu wipen (davon kann ich recovern, das hatte ich ja schon mal versehentlich geschafft ) bzw. den Chip gleich mit einem nicht-brickenden Image neu zu flashen.
Tja... und jetzt bin ich hier, und starre auf das Datenblatt des Chips, meine Debug-Klemme fuer den 16-Pin-Sockel, und male mir aus, was beim Rettungsversuch noch alles schiefgehen koennte. Sollte das alles nicht zu einem toedlichen Zimmerbrand fuehren, lest ihr vielleicht mal, wie (oder ob) es ausgegangen ist!
HAHAHAHA LEUTE, I SURE WAS DOWN, BUT I WAS NOT OUT!!!!
Kurzmoral von der Geschicht: Rumweinen bei Paul hilft, er hat einfach immer die besten Ideen
Langfassung: Stellt sich raus dass dem n25q512ax3 man durch Shorten der Pins #10 (VSS/Ground) und #15 (DQ0) verhindern kann, dass der Inhalt durch den BMC gelesen werden kann. Das hab ich nach ein bisschen Ratlosigkeit im Umgang mit der 16er-Klemme recht schnell geschaft gehabt, was dazu gefuehrt hat, dass der UART-Debug-Port trotz Power still geblieben ist. Das ist gut, weil so kann der AST2500 nicht die Instruktionen aus dem Flash lesen, die ihn unverwundbar gegenueber Angriff aus dem Hostsystem machen. Ein paar Minuten spaeter verliert der Host die Geduld beim Warten auf den BMC (das ist auch bei voellig zerstoertem Flash-Inhalt, also ohne BMC-Firmware, so der Fall) und faehrt auch hoch.
Leider hat sich schnell gezeigt, dass der BMC periodisch immer wieder versucht, vom Flash seine Firmware zu laden und zu booten - es war also nicht damit getan, ihn ein Mal am Beginn der Uptime am Booten zu hindern, sondern ich musste die Klemme mit den geshorteten Pins dranlassen.
In meinem so am Host gebooteten grml konnte ich aber immerhin mit culvert taetig werden. Ohne die Mitigations, die u-boot mitbringt, kann man da viel anstellen - mit `culvert probe` war klar, dass der AST2500 am Leben (und offen wie ein Scheunentor) ist:
... aber das Flashen eines korrigierten OpenBMC-Images sollte (wegen des Pin-Short-Tricks, mit dem ich den Zugriff auf den Flash verhindert hatte) ein Problem darstellen. In diesem Zustand konnte die von culvert verwendete libflash nicht einmal ermitteln, welcher Baustein da am SPI sitzt und gelesen oder beschrieben werden koennte.
Die Theorie war nun, dass ich mit einem schnellen Loop aus `culvert firmware write < myimagefile` vielleicht nach Abziehen der Bruecke ueber die Pins eine vermutete Race Condition zwischen dem AST2500-Reboot-Timer und dem Beschreiben des Flashs gewinnen koennte. Und... naja, fast:
Code:
# while :; do ./culvert write firmware < /tmp/image-bmc && break; done
[*] Accessing the BMC's AHB via the p2a bridge
[*] Preventing system reset
[*] Gating ARM clock
[*] Configuring VUART for host Tx discard
[*] Initialising flash subsystem
[*] Writing firmware image
.
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
.
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
.
................................................................................................................................................................................................................................................................
[*] LIBFLASH: Miscompare at 0x00020000
.
................................................................................................................................................................................................................................................................
[*] LIBFLASH: Miscompare at 0x00020000
Da war culvert nach ein paar Bytes die Luft ausgegangen. Aber ich witterte dennoch Morgenluft, denn die geschrieben Bloecke haben ausgereicht, um den Bootloader im Flash effektiv zu zerstoeren, und den BMC schon etwas VOR dem frueheren Stillstandszeitpunkt zu bricken. Sah so aus:
Code:
[...picocom init...]
Type [C-a] [C-h] to see available commands
Terminal ready
DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3784/DH:0.3823 CK (min:0.30)
Ende Gelaende. Quasi der selbe Zustand, wie wenn ALLES im Flash kaputtgeschlagen wurde. Ihr seht vielleicht schon, wohin das fuehrt u-boot versucht in diesem Zustand nicht mehr, weiter Daten vom Flash zu laden - ich spare mir also den Clamp-Trick. Das bedeutet auch, dass ich den BMC in diesen kaputten Zustand booten lassen kann, waehrend ich ueber AHB via culvert aus dem Host ganz bequem und ungestoert alle Operationen durchfuehren kann - auch das bereits erprobte `firmware write`. Und tatsaechlich, einen Power Cut (mit einem geeigneten OpenBMC-Image am Host paratgelegt) spaeter:
Code:
root@grml /tmp # ./culvert write firmware < /tmp/image-bmc
[...]
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
[*] Performing SoC reset
./culvert write firmware < /tmp/image-bmc 405.86s user 0.88s system 98% cpu 6:52.77 total
... der BMC so:
Code:
DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3784/DH:0.3823 CK (min:0.30)
U-Boot 2019.04 (Jul 26 2024 - 07:18:46 +0000)
SOC : AST2500-A2
RST : WDT2 - 2nd Boot
default boot
RST : WDT3 - Boot
RST : Power On
LPC Mode : SIO:Enable : SuperIO-2e
Eth : MAC0: RMII/NCSI, , MAC1: RGMII,
Model: Gigabyte MC12-LE0 u-boot
DRAM: 496 MiB (capacity:512 MiB, VGA:16 MiB, ECC:off)
MMC:
Loading Environment from SPI Flash... SF: Detected n25q512ax3 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
*** Warning - bad CRC, using default environment
In: serial@1e784000
Out: serial@1e784000
Err: serial@1e784000
Net: Invalid PHY interface '<NULL>'
eth-1: ethernet@1e660000Invalid PHY interface '<NULL>'
, eth-1: ethernet@1e680000
Hit any key to stop autoboot: 0
## Loading kernel from FIT Image at 20100000 ...
Using 'conf-gigabyte-mc12-le0.dtb' configuration
Trying 'kernel-1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x20100118
Data Size: 3279824 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80001000
Entry Point: 0x80001000
Hash algo: sha256
Hash value: ac104186382035da31caec0dd5b32fc612acf419ae5bcfa15226f7d15556c5d0
Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at 20100000 ...
BOOM!!! Back. In. The. Game!!
Danke fuers Lesen, und vielleicht auch Mitfiebern Was fuer ein Abend! Ich liebe diesen Sche*ß!
Update lief auf meinen beiden System (PRO 5650; 3600) erfolgreich durch. Achtung: Das UEFI Update zieht einen nicht verhinderbaren restore der default settings nach sich.
USB Power Meter ist bereits vorhanden.
Ich wollte nur das Gleichsetzen von iKVM und IPMI torpedieren, weil das "ich kann den PC bedienen, als wuerde ich gerade vor ihm sitzen"-Feature vielleicht fuer viele Leute den obersten, offensichtlichsten Nutzen von OOB-Management via IPMI darstellt, aber es damit halt nicht getan ist. Ich finde es z. B. sehr Hilfreich ein System Event Log (SEL) zu haben, das mir unabhaengig vom Host-OS ein Tagebuch ueber ggf. bedenkliche Ereignisse (Komponenten-Fehler im Betrieb, unerwartete Reboots/Power Cuts, etc.) bietet. Auch dass ich die gesamte Sensorik des Hosts via IPMI auslesen kann, das Host-BIOS-ROM flashen, die Host-POST-Codes interpretieren... das sind alles Features, die schnell einmal wichtig (oder zumindest sehr praktisch) werden koennen, die man mit so einer PiKVM-artigen Dranstoepsel-Loesung prinzipbedingt kaum kriegen kann.
...
u-boot versucht in diesem Zustand nicht mehr, weiter Daten vom Flash zu laden - ich spare mir also den Clamp-Trick. Das bedeutet auch, dass ich den BMC in diesen kaputten Zustand booten lassen kann, waehrend ich ueber AHB via culvert aus dem Host ganz bequem und ungestoert alle Operationen durchfuehren kann - auch das bereits erprobte `firmware write`. Und tatsaechlich, einen Power Cut (mit einem geeigneten OpenBMC-Image am Host paratgelegt) spaeter:
