Eine Anmerkung von Zima
Vielen Dank, sbinske, dass du gezeigt hast, dass ein nützlicher Home-Server weder mit speziell entwickelter Server-Hardware noch mit professioneller Administrationserfahrung beginnen muss. Dein Retro-LAN-Party-Aufbau hat ausgedienten PC-Komponenten neues Leben eingehaucht und daraus ein ZimaOS-System gemacht, auf dem Docker-Dienste, mehrere virtuelle Maschinen, DNS, TeamSpeak und die unterstützenden Tools liefen, die für eine LAN-Veranstaltung nach alter Tradition erforderlich waren.
Wir schätzen besonders, dass du die Fehlersuche ebenso klar dokumentiert hast wie die Erfolge. Die Freezes der GT710, die Instabilität der Netzwerkkarte, die Grenzen, auf die du beim Workflow des App Stores gestoßen bist, und dein Wunsch nach flexibleren Speicherkombinationen sind genau die Art von Rückmeldung, die zeigt, wo sich ein schlankes System zugänglich anfühlt und wo es einem Hobbyanwender noch zu viel abverlangt.
— Zima
Lernen Sie sbinske kennen
sbinske beschreibt sich selbst als nicht professionellen Techniknutzer und DIY-Hobbyisten. Diese Unterscheidung ist für diese Geschichte wichtig. Er ging nicht als Systemadministrator an ZimaOS heran, der nach einer weiteren Plattform für Vergleichstests suchte. Er näherte sich dem System als jemandem, der gerne Dinge baut, Hardware wiederverwendet und praktische Ergebnisse erzielt, ohne jedes Projekt in eine Unternehmensinfrastruktur zu verwandeln.
Bevor er sich für ZimaOS entschied, suchte er lange nach einer Alternative zu Unraid. Ihn reizte nicht die Funktionsgleichheit. Tatsächlich gefiel ihm unter anderem, dass sich ZimaOS schlanker anfühlte und nicht versuchte, so umfassend wie Unraid zu sein.
Sein Projekt im Februar 2026 wurde zu einem sehr konkreten Test dieser Idee: Konnte ein vergleichsweise schlankes Home-Server-Betriebssystem die Mischung aus Containern, virtuellen Maschinen, Netzwerkfunktionen und Speicher bereitstellen, die für eine Retro-LAN-Party erforderlich war?
Eine Retro-LAN-Party wurde zum Testfall
Der Server wurde für eine LAN-Party nach alter Tradition vorbereitet, bei der die Infrastruktur lokal betrieben werden und die Veranstaltung unterstützen musste, ohne von einer Vielzahl externer Dienste abhängig zu sein.
Als er den Aufbau dokumentierte, liefen auf ZimaOS bereits zwei Docker-Container: ein TeamSpeak-Server und ein DNS-Server. Dazu kamen drei virtuelle Maschinen: ein ETI-SyncServer, eine LanPage-VM und eine weitere VM, die die übrigen Dienste rund um die Veranstaltung organisieren sollte.
Diese Arbeitslast machte das Projekt interessanter als einen einfachen NAS-Test. Speicher war nur ein Teil davon. Das System musste gleichzeitig auch Netzwerkdienste und mehrere isolierte virtuelle Maschinen hosten.
Warum ZimaOS als schlanke Unraid-Alternative funktionierte
sbinskes Vergleich mit Unraid war bewusst praxisorientiert. Er erwartete nicht, dass ZimaOS jede Funktion von Unraid nachbildet. Er wollte ein kleineres System, das die tatsächlich benötigten Funktionen abdeckt und verständlich genug bleibt, damit ein Hobbyanwender damit arbeiten kann.
Nachdem die Hardwareprobleme behoben waren, fiel seine Gesamterfahrung positiv aus. Das System stabilisierte sich und bewältigte die LAN-Party-Workload, die er dafür eingerichtet hatte.
Die aktuelle ZimaOS-Dokumentation beschreibt virtuelle Maschinen weiterhin als einen sich entwickelnden Bestandteil der Plattform, während das übergeordnete System Speicher, Docker-Anwendungen und Virtualisierung in einer Oberfläche vereint. Damit ist sbinskes Projekt ein gutes Beispiel dafür, diese Komponenten gemeinsam zu nutzen, anstatt jede Funktion als separate Demo zu betrachten.
Das erste große Problem sah wie ein ZimaOS-Absturz aus
Der Aufbau begann nicht reibungslos. sbinske berichtete, dass ZimaOS nach etwa 20 Minuten Betrieb vollständig einfror.
Nach der Prüfung der Protokolle und dem Testen der Komponenten führte er die erste Störungsrunde auf eine alte NVIDIA GeForce GT 710 zurück. Er versuchte, Treiber manuell über das Terminal zu installieren, doch das behob das Problem nicht. Außerdem experimentierte er erfolglos mit Änderungen im Zusammenhang mit virtuellen Laufwerken.
Schließlich entfernte er die Grafikkarte, setzte das System zurück und installierte ZimaOS ohne sie erneut. Die saubere Installation lief wieder ordnungsgemäß.
Dies sollte als ein vom Ersteller gemeldetes Kompatibilitätsproblem auf seinem spezifischen Rechner betrachtet werden, nicht als allgemeine Behauptung, dass jede GT 710 mit jedem ZimaOS-Build inkompatibel ist. Die Quelle dokumentiert, was in dieser Konfiguration geschah; sie stellt keine universelle Treiberregel auf.
Das Wiedereinsetzen der GPU offenbarte ein komplizierteres Hardwareproblem
Als sbinske die Grafikkarte wieder einsetzte, änderte sich das Verhalten. Statt nur ein Problem mit dem Grafiktreiber zu sehen, begann der Rechner wiederholt, Festplatten und Netzwerkkarten zu trennen und neu zu erkennen.
Die Protokolle zeigten Fehler, aber er konnte sie nicht mit Sicherheit einem bestimmten Netzwerkadapter oder allein der Grafikkarte zuordnen. Daher änderte er seine Vorgehensweise bei der Fehlersuche: Er entfernte die Hardware nacheinander und beobachtete, wann das System aufhörte, Fehler zu melden.
Dieser Prozess führte zum eindeutigsten Ergebnis der gesamten Debugging-Sitzung. Das System war mit drei zusätzlichen Netzwerkkarten plus der integrierten Netzwerkschnittstelle des Motherboards instabil. Mit nur zwei zusätzlichen Netzwerkkarten lief der Rechner problemlos.
Er vermutete eine PCIe-Lane-Zuweisung – konnte dies aber nicht beweisen
Der Host war keine speziell für Server entwickelte Hardware. Er verwendete einen AMD Ryzen 5 2600, ein MSI-B450-Plus-Motherboard und 64 GB RAM – im Wesentlichen Ersatzhardware, die für das Projekt verfügbar war.
sbinske vermutete, dass die Kombination aus Mainboard, CPU, Grafikkarte und mehreren Netzwerkadaptern möglicherweise auf ein Problem mit PCIe-Lanes oder der Ressourcenverteilung gestoßen war. Er führte die Untersuchung jedoch nicht weit genug fort, um diese Theorie zu beweisen, da der Rechner seine Anforderungen bereits mit zwei zusätzlichen Netzwerkkarten erfüllte.
Diese Abgrenzung ist wichtig. Das erfolgreiche Ergebnis der Fehlersuche ist bekannt: Die Kombination der Erweiterungskarten wurde reduziert, woraufhin das System stabil wurde. Die genaue elektrische, Firmware- oder Lane-Zuweisungsursache bleibt eine Hypothese des Erstellers und ist kein bestätigter ZimaOS-Fehler.
Nachdem sich die Hardware beruhigt hatte, blieb der Server stabil
Nachdem sbinske die Anzahl der Netzwerkkarten reduziert und die problematische Hardwarekombination entfernt hatte, berichtete er, dass das System stabil lief.
Das veränderte seine Sicht auf das Projekt. Die anfänglichen Abstürze hatten die Installation unzuverlässig erscheinen lassen, doch das spätere Verhalten deutete auf ein komplexeres Zusammenspiel zwischen dem Betriebssystem und einer ungewöhnlichen Sammlung wiederverwendeter Desktop-Komponenten hin.
Bei einem DIY-Build war dieser Unterschied wichtiger als die Ermittlung einer perfekten Hauptursache. Er hatte eine Konfiguration erreicht, mit der die LAN-Party-Dienste ausgeführt werden konnten, und zwei Netzwerkkarten reichten bereits für die von ihm geplante Aufgabe aus.
Im App Store wirkte ZimaOS weniger benutzerfreundlich als Unraid
Die deutlichste Kritik an der Benutzerfreundlichkeit in sbinskes Fragebogen betraf die App-Store-Erfahrung mit Docker-Containern von Drittanbietern.
Sein Vergleichspunkt war Unraid: Einen App Store installieren, nach dem Container suchen, einer klaren Beschreibung und einem Einrichtungsformular folgen und ihn anschließend installieren. Seiner Ansicht nach könnte ZimaOS dasselbe Ergebnis erreichen, doch das Einbinden eines unbekannten Containers oder eines Containers eines Drittanbieters erfordere zu viel Wissen von Nichtfachleuten und Hobbyanwendern.
Dieses Feedback wurde im Februar 2026 aufgezeichnet. Die aktuelle ZimaOS-Dokumentation besagt nun, dass Benutzer beliebige Docker-Compose-YAML-Dateien importieren, Konfigurationen direkt bearbeiten, Stacks mit mehreren Containern ausführen und von der Community gepflegte Stores von Drittanbietern verwenden können. Die Entwicklerdokumentation beschreibt den aktuellen Workflow für die Paketierung von Apps im App Store außerdem deutlich ausführlicher.
Diese neueren Möglichkeiten machen seine ursprünglichen Erfahrungen nicht ungeschehen. Sie liefern nützlichen Kontext: Der von ihm als zu kompliziert empfundene Arbeitsablauf betraf genau den Bereich, den ZimaOS später im Jahr 2026 weiter ausbaute.
Speicherflexibilität war das andere fehlende Puzzleteil
sbinske wollte außerdem mehr Freiheit, mehrere Laufwerke für unterschiedliche Arbeitslasten in verschiedene Speichergruppen aufzuteilen.
Sein Beispiel war praxisnah: Ein Laufwerkspaar konnte als RAID 0 verwendet werden, wenn Kapazität und Geschwindigkeit wichtiger als Redundanz waren, während ein anderes Paar für Daten, die eine Spiegelung verdienten, als RAID 1 dienen konnte. Insbesondere seine SyncServer-Arbeitslast benötigte mehr als 4 TB Speicherplatz, erforderte aber nicht dasselbe Maß an Datenschutz wie wichtigere Speicherbereiche.
Aus seiner Sicht könnte die Möglichkeit, günstigere vorhandene Laufwerke zu workload-spezifischen Arrays zu kombinieren, die Hardwarekosten senken und die bereits vorhandenen Laufwerke besser nutzen.
Die aktuelle ZimaOS-Dokumentation behandelt inzwischen RAID 0, RAID 1, RAID 5, RAID 6, JBOD und ZFS. Die für diese Geschichte geprüfte öffentliche Dokumentation bestätigt jedoch nicht ausdrücklich den genau von sbinske gewünschten Workflow mit mehreren Arrays – beispielsweise das unabhängige Erstellen eines RAID 0 mit zwei Laufwerken und eines separaten RAID 1 mit zwei Laufwerken auf demselben Host über die reguläre Benutzeroberfläche. Aus diesem Grund hält diese Seite an seiner Anforderung fest, anstatt zu behaupten, sie sei vollständig erfüllt.
Die Definition von Erfolg durch einen nicht professionellen Nutzer
Das Nützliche an diesem Projekt ist, dass sbinske das System nicht danach beurteilte, wie viele fortgeschrittene Funktionen es bot. Er beurteilte es danach, ob es die Dienste unterstützen konnte, die er tatsächlich ausführen wollte.
Nach der Fehlersuche an der Hardware lautete die Antwort weitgehend: ja. ZimaOS war schlanker als Unraid, aber das war akzeptabel, weil sein LAN-Party-Server nicht alle Unraid-Funktionen benötigte. Zwei Docker-Container, drei virtuelle Maschinen, lokales DNS, Sprachkommunikation, Synchronisierung und Dienste zur Veranstaltungsverwaltung reichten aus, um den Server nützlich zu machen.
Seine Kritikpunkte entsprangen derselben praxisorientierten Denkweise. Eine einfachere Installation von Docker-Containern von Drittanbietern würde die Lernkurve verkürzen. Eine flexiblere Gruppierung von Laufwerken könnte die Hardwarekosten senken. Eine bessere Kompatibilität mit ungewöhnlichen Kombinationen von Desktop-Erweiterungskarten würde Projekte mit vorhandener Hardware weniger unberechenbar machen.
Die Geschichte wird noch geschrieben
Die Geschichte von sbinske und Zima wird noch geschrieben. Sein aktuelles Projekt begann als schlanke Unraid-Alternative für eine Retro-LAN-Party und entwickelte sich zu einem Praxistest dafür, wie sich ZimaOS auf wiederverwendeter Desktop-Hardware unter einer gemischten Docker-und-VM-Arbeitslast verhält.
Das Endergebnis war keine vollkommen reibungslose Erstinstallation. Es war ein funktionierendes DIY-System, das durch Fehlersuche auf Komponentenebene erreicht wurde: die GT 710 entfernen, die Kombination der Erweiterungskarten reduzieren, die tatsächlich benötigten zwei Netzwerkkarten behalten und fortfahren, sobald der Rechner stabil blieb.
Für jemanden, der sich ausdrücklich eher als Hobbyisten denn als Profi bezeichnet, könnte das das nützlichste Ergebnis des Projekts sein. Das System verbarg nicht jedes technische Detail vor ihm, aber nachdem die Hardwarekombination vereinfacht worden war, bot es die schlankere Home-Server-Umgebung, nach der er gesucht hatte.
Für den aktuellen Plattformkontext siehe die Übersicht der ZimaOS-Funktionen und die aktuelle Referenz zur RAID-Konfiguration.
