Da komm doch mal drauf!¶

Ich muss etwas ausholen.
Wieso? Weil ich ich bin :-)

Meine Technikausstattung hat sich im Laufer der Jahre, die ich jetzt mit Computern rumfrickle, verändert.
Ist ja klar: der ZX81, miot dem ich mal angefangen habe, zieht heute keinen Trecker mehr vom Acker.

"Früpher" (tm) hatte ich in der Regel ein Bastel- und ein Stabilsystem.
Wem das aus der Softwareentwicklung (stable vy. testing Zweige) bekannt vorkommt, der irrt nicht.
Denn ähnliche Probleme fordern ähnliche Lösungen.

Drauf gekommen bin ich damals, als ich nach einem Mod an meinem Atari ST mit einem extrem unstabilen System konfrontiert war, das alle Nase lang abstürzte während man grad dabei war, das morgen abzugebende Protokoll für den Laborversuch an der Uni einzutippen :-(
Sowas schult ja ungemein.

Der zweigleisige Betrieb hat sich dann aber verändert.
Heute habe ich meisst ein Windows- und ein Linuxsystem parallel im Einsatz statt eines Bastel- und eines Produktivsystems in Dual-Boot.

Der Windows-Rechner hat zwei Rollen: - es läuft die verflixte Vendor-Software, die es verdammt noch mal nur unter Windows gibt und die dreckigerweise nicht in einer VM eingesperrt zum Laufen zu bringen ist - Spielkram Ergo hat diese Maschine die dickste, idR. jüngste Grafikkarte in meinem Arsenal.

Mein aktueller Linux-Rechner ist eine HP Z600 Workstation, die ich als Gebrauchtgerät (Leasing-Rückläufer vermutlich) seinerzeit für um die 370 Euro geschossen habe (sind inzwischen billiger geworden bzw. zum gleichen Preios besser ausgestattet zu bekommen). Die habe ich dann noch mit USB3-Karte, NVM-Storage (so ein Mini-PCIe-Streifchen auf Adapterkarte), Sata-SSD (das olle BIOS kann nicht von NVM booten), zweitem Prozessor (10 Euro :-) mit passendem Kühler (70 Euro :-() und ein klein wenig RAM (gekauft mit 8G, jetzt 40) aufgerüstet habe.
Ergebnis: ein grundsolides System, nicht grad lautlos aber unaufdringlich leise, leistungsfähig (8Kern/16Thread und genug Platz für einen Sack voll Development-VMs). Ich mag das Ding - wie ich sicher eine Profi-Workstation eines anderen Hersteller auch mögen tät.

Daneben verrichtete bis vor kurzem noch ein weiterer PC seinen Dienst als NAS, also Fileserver.
Das war eine Zeit lang ein Mini-ITX SYstem mit entsprechendem Gehäuse und Platz für 6 Festplatten des 3,5er Formats. Ich benutze die noch gerne, weil die in Punkto Speicherplatz pro Euro ungeschlagen sind.
Neben den 4 Sata-Anschlüssen auf dem Board lieferte eine Sata-Controllerkarte zwei weitere Anschlüsse und erlaubte so den Betrieb von 6 Festplatten.
Schon der Aufbau dieses System war etwas knifflig. Der auf dem Board verbaute spezielle Sata-Chip und der auf der ersten Adapterkarte verbaute Chip waren identisch. Und waren einfach nicht zum Laufen zu bringen; offenbar waren die beiden BIOS-Versionen nicht in der Lage, sich beim Rumfiddeln an Chip-Registern auf einen der beiden Controllerchips zu beschränken; die funkten sich gegenzeigid dazwischen. Erst mit einer Adapterkarte, die einen Chip anderer Bauart trägt als das Board, war das dann lauffähig zu bekommen.
(spannend am Rande: unter Windows lief das Teil, mit Linux oder FreeBSD aber nicht. Windows hat offenbar seinen Treiber und ignoriert einfach das BIOS oder ACPI oder sonstwas).

Irgendwann gab dieses Teil den Geist auf.
Völlig unklar, was da kaputt ist, bootet einfach nicht mehr.
War wohl doch keine gute Idee, ein passiv gekühltes System mit verlöteter CPU zu verbauen: da kann man jetzt nichts daran diagnostizieren.
Nun gut, so weit so schlecht.

Wie jetzt fix an die Daten des NAS-Array rankommen?
Oh, wait, da in der Ecke steht doch noch der alte, ausgemusterte Windows-Rechner rum.
Seine Phenom-II-CPU war seinerzeit das Spitzentier von AMD, die 8GB DDR2-800 ebenso.
Und das Board hat auch shcon 4 Sata-Anschlüsse drauf, mit Adapterkarte müssten die 6 Platten also einfach laufen.
Und das Linux sollte auch einfach so booten können.

Ganz so simpel war es nicht, diejenige Platte, die die Boot-Partition trägt (und nur den Rest dem RAID zur Verfügung stellt) musste an einem bestimmten Anschluss hängen, damit das Bios booten mochte.
Aber das kann man ja herstellen - und dann lief das.
Wenn auch lauter und mit mehr Strombedarf als das alte NAS, aber wenigstens waren die Daten wieder da.
Drei Wochen lang...

Dann fiel mir auf, warum ich diese Maschine seinerzeit ausgemustert hatte.
Die hatte nach einigen Jahren des Betriebs die Eigenart entwickelt, gelegentlich einfach mal einzufrieren oder neu zu booten.
Was natürlich genau gar keinen Spass macht, wenn man grad mit den Kumpels aus der Gilde dabei ist, ein WoW-Monster zu verkloppen...

Mist.
Ein NAS das alle paar Stunden unvermittelt einfach so neu bootet ist echt nur der halbe Spass.

Eine Funktion des NAS, nämlich eine Nextcloud-Instanz zur Synchronisation meiner Kontakte und Kalender bereitzustellen, erforderte Dauerbetrieb.
Und im Grunde ist dafr so ein Stromfresser sowieso falsch.
Da gibt es doch diese neumodischen Micro-PCs auf ARM-Basis? Das eäre doch was?
Nach etwas experimentieren - Olimex mag ich. Tolle Leute (mal auf ner Messe mit denen geschnackt) und nettes Produktportfolio. Aber die Olinuxino-Boards mit den Allwinner-Chips sind keine Gewinner. Weil einfach zu wenig Support und zu wenig Doku gleichzeitig eine doofe Kombo ergeben - landete ich beim Raspi.
Wo sonst?
Der Raspi ist auch in der Version Raspi-3 kein Speedmonster, speziell beim Massenspeicher-IO. Der USB stellt sich als Flaschenhals auf und allen Daten in den Weg.
Und zwar sowohl den Daten für das Ethernet - das noch dazu mit 100Mbit unzeitgemäss dürftig ist - als auch den Daten für die USB-Sata-Bridge.
Dafür passt das ganze System mit einer Sata-SSD in <10 Watt Leistungsbedarf.
Zusammen mit einem effizienten Netzteil, das zudem meinen WLAN-Router mitversorgt (12V. Für den Raspi war also ein mal-eben-schnell selber zusammengedengeltes HAT mit Schaltregler erforderlich) ergibt das gegenüber einem NAS doch erfreuliche Einsparungen.

Bleibt also das Problem, an die Daten auf den 6 Platten auch mal ranzukommen.
Aber zumindest war jetzt - auch weil der Raspi über einen der Optokoppler auf dem HAT auch den NAS Rechner booten kann - das, was dauerhaft laufen sollte, wieder dauerhaft. Und wenn der Fileserver gelegentlich mal weg ist, dann aber wiederkommt, kann man damit erstmal leben.

Jedenfalls so lange, bis er eben nicht mehr zuverlässig wiederkommt.
Lange Geschicht kurz erzählt: der Phenom tut es eben auch nciht mehr.
So ein Dreck!

Aber wir haben da ja die Z600.
Grundsolide, zuverlässig, Remote-Boot fähig (wake-on-lan) wenn man mal von unterwegs an eine Datei ranmuss.
Und Linux eh schon drauf für den Einsatz als Workstation.
Aber das Teil hat halt nur 6 Sata-Anschlüsse auf dem Board.

Die Z600 hat 2 Einbauplätze für 3,5er Platten, 2 Einbauplätze für 5,25er Geräte (wie DVD-ROMs oder olle 5,25er Platten) und 6 mal Sata onboard.
Streng genommen isnd as SAS-Anschlüsse, aber ausgeliefert werden die Dinder idR. mit Sata-Platten.
(Dadurch habe ich übrigens gelernt, dass an SAS-Anschlüssen idR. Sata-Geräte problemlos laufen; elektrisch ist beides dasselbe, und beide Protokolle sind sich auch so ähnlich, dass die Treiber etc. das unterstützen).

Und das ist natürlcih zu wenig.
Zumal die Workstation ja schon 3 3,5er Platten, ein DVD-ROM, und eine Sata-SSD eingebaut hat, 5 der 6 Ports also belegt sind.
Also ist eine Adapterkarte nötig.

Für die 4-Kanal-SAS-Steckverbinder, wie sie auf SAS-Controllern für den Servereinsatz gern verbaut sind, gibt es preisgünstig Adapterkabel-Peitschen, die dann 4 Sata-Steckverbinder tragen.
Also kauft man einfach einen gebrauchten 8-Kanal SAS-Controller und hängt da die Platten dran, nicht wahr?

Im Prinzip ja.
Aber Murphy.
Ein Controller mit LSI-Chip ist auf der Auktions-Plattform der Wahl schnell gefunden und für wenig Geld erstanden.
Eingebaut, gebootet, Platten erkannt, SMART-Daten werden korrekt ausgelesen.
Nur das btrfs beklagt sich, dass es das Filesystem nicht mounten kann.
WTF?

Etwas Recherche in diversen obskuren Foren, die wie alles heutzutage voll von Halbwissen, ungeprüften Vermutungen und und Dummem Zeug sind (ich spreche daher ja gerne vom Forendreschen statt von der Recherche. Ähnlich wie man beim Getreide das Korn von Stroh und Spreu separiert muss man bei Internet-Foren den Content rausfriemeln), ergab dann Erleuchtung.
Genu dieser ältere LSI-Chipsatz schneidet jede Festplatte auf 2TB PLatz ab.
Bei Zugriffen auf Blöcke jenseits der 2TB gibt er den Fehler "Zugriff ausserhalb des physikalischen Datenträgers" zurück - und btrfs ist dann unglücklich, wenn es von einer 4TB-Platte nur die Hälfte zugreifen kann.
Was ich verstehe.

Und jetzt verstehe ich auch, warum, der Anbieter bereit war, sich für so kleines Geld von der Karte zu trennen...
Mist.
Alle Daten immer noch unzugreifbar.

Ein anderes Modell von LSI sol diese Grenze nicht haben und wird überhaupt in einigen Foren sehr gelobt.
Und als Künigsweg zu Beschaffung wird eine Controllerkarte von IBM genannt, die nach dem Ersetzen des feature-reduzierten IBM-BIOS die volle Funktionalität des Chips erschliesst.
Und diese ist auch an den deutlich höheren Gebrauchtpreisen gut erkennbar.

"Egal," denkt der Semken, "so ein Teil kaufe ich jetzt!"
Und dann kommt das Ding an, un inzwischen ist auch ein externer Käfig für die Platten fertig gefrickelt, denn im Gehäuse der Z600 ist ja kein PLatz mehr.

Karte eingebaut, Platten angeschlossen, gebooetet.
Irgendeine komische BIOS-Fehlermeldung weggecklickt, ich will was sehen.
Und in der Tat: Lunix bootet wie gewohnt, lspci zeigt die Controller-Karte, /dev/disk/by-path zeigt den Zuwachs an Geräten und ein sudo mount /dev/sdi /mnt liefert keinen Fehler mehr. Meine Daten sind wieder da!
Natürlich muss das Array jetzt erstmal einen Check-Run (btrfs scrub start /mnt) durchlaufen, schliesslich hat der ständig crashende alte Rechner Kerben in der Filesystem-Struktur (nicht komplett abgeschlossene Schreibvorgänge zum Beispiel) hinterlassen.
NAch 8 Stunden ist der scrub auch erledigt, die 130 Fehler sind korrigiert.
Ja, in der Tat, selbst bei 600 MB/s Lesegeschwindigkeit dauert so ein scrub-run über 6,5TB RAID1 nun mal...

Alles könnte gut sein.
Wäre da nicht der Anlass für diesen Blog-Rant.

Mit dem SAS-Controller installiert meldet das BIOS der Z600 einen RAM-Fehler
Dabei ist es egal, ob in dem betreffenden RAM-Slot (CPU1, Dimm1) überhaupt ein DIMM steckt: es wird ein "incompatible DIMM detected, memory rank disabled" ausgegeben.

Es scheint auch egal zu sein, in welchem PCIe-Slot der Controller steckt (nur 2 Slots probiert) und auch die BIOS-Einstellungen für den Slot lösen das Problem nicht.
Einstellen kann man für einen Slot übrigens genau 2 Dinge: "OptionRom Download (enabled/diabled)" und "compute (enabled/disabled)".
Das setting compute hat keine Auswirkungen. Und bei OptionRoim disabled läuft der Controlelr einfach gar nicht.
Aber immer - also settings egal - kommt der RAM-Fehler.

Natürlich habe ich zunächst vermutet, dass bei meinen Basteleien an der Maschine irgendwie das RAM beschädigt wurde oder der RAM-Sockel.
Also habe ich dort nach dem Fehler gesucht.
Das war es aber nicht.

Bei der systematsichen Suche - die immer mit einer Minimierung des Systems beginnt, also alles Nichtessentielle ausbauen bzw. abstöpseln - trat der Fehler dann sofort nicht mehr auf.
Um dann nach der Montage des Controllers wieder zu erscheinen.

Und da soll man als PC-Techniker drauf kommen?
Dass der angezeigte Fehler "incompatible DIMM detected" ausfühlich eher "either something is wrong with the memory controller in CPU1, the DIMM in slot x, the motherboard the DIMM slot, the lunar cycle, any PCIe devices OptionRom, the african sparrows migration pattern or the fiber content in the users diet" geschrieben werden müsste?
Klar, so ein langer Fehlermeldungstext passt in kein ROM und auf keinen Boot-Screen.
Logisch, dass der abgekürzt werden muss.

Ach, hatte ich erwähnt, dass dieses doofe Profi-Maschine-BIOS natürlich nicht die ganzen Einstellmöglichkeiten hat, die jedes frecking Gamer-Board bietet?
Weil ja offenbar die Kundschaft, die 4,5 Kiloeuro für einen Computer ausgibt, sowas alles nicht haben will?

Diese Haltung scheint ja nicht HP-spezifisch zu sein.
Auch Apple 2schützt" seine Kunden gern vor zuviel Detailkenntnissen.
Und auch die Evangelisten des Gnome-Desktops sind von dieser Mutation etwas zu sehr betroffen für meinen Geschmack.

So ein verdammter Dreck.
Ok, meine Daten sind jetzt wieder da.
Udn ich komme wieder dran.
Aber jetzt muss ich mir mal-eben-schnell aus einem Arduino Leonardo oder vergleichbar ein USB-Gerät baun, das nach dem Power-On eine Weile den F1-Tastencode sendet, damit meine Workstation wieder remote gebootet werden kann.
Denn natürlcih hat die "press F1 to continue"-Meldung nach der Fehlermeldung über die Schwalbenmigration keinen Timeout.
Ist ja kein Gamer-PC-Board!
Workstation-User wollen sowas nicht!