Anleitung

Minecraft NeoForge 26.3: Mein Server-Update mit Problemen

KI-Generiertes Foto

Ein Minecraft-Server-Update klingt zunächst ziemlich einfach:

Server stoppen, neue Version installieren, Mods aktualisieren, wieder starten.

In der Praxis reicht allerdings schon eine einzige inkompatible Mod oder fehlende Abhängigkeit, und aus dem kleinen Update wird schnell eine längere Fehlersuche.

Genau das ist mir beim Wechsel meines NeoForge-Servers von Minecraft 26.2 auf Minecraft 26.3 passiert.

Der Server läuft unter Debian und wird über systemd verwaltet, während ich den Client unter Windows nutze.

Ausgangslage meines Minecraft-Servers

Nach dem Update sollte folgende Konfiguration laufen:

KomponenteVersion
Minecraft26.3
NeoForge26.3.0.97
Java25.0.5
BetriebssystemDebian
Verwaltungsystemd

Der Server befindet sich bei mir unter:

/home/thomas/minecraft_forge

und wird über den Dienst:

minecraft_forge.service

gestartet.

Ein vorhandenes start.sh mit screen brauche ich für den normalen Betrieb nicht mehr, weil der Server vollständig über systemd verwaltet wird.

Das finde ich inzwischen auch deutlich angenehmer.

Wenn schon Linux-Server, dann darf systemd wenigstens auch etwas zu tun bekommen.

Update von Minecraft 26.2 auf 26.3

Vor dem Update lief noch:

Minecraft 26.2 mit NeoForge 26.2.0.59

Ziel war:

Minecraft 26.3 mit NeoForge 26.3.0.97.

Die Installation selbst war zunächst erfreulich unspektakulär.

Im Serververzeichnis habe ich den NeoForge-Installer ausgeführt:

cd /home/thomas/minecraft_forge
sudo -u thomas java -jar neoforge-installer.jar --installServer

Der Installer meldete anschließend:

The server installed successfully.

Auch die run.sh wurde automatisch auf die neue NeoForge-Version angepasst.

Bis zu diesem Punkt sah also alles ziemlich gut aus.

Dann kamen die Mods.

Erstes Problem: Mods noch für Minecraft 26.2

Nach einem größeren Minecraft-Update reicht es natürlich nicht, nur Minecraft und NeoForge zu aktualisieren.

Die installierten Mods müssen ebenfalls zur neuen Version passen.

Bei mir waren noch mehrere Mods auf Minecraft 26.2 ausgelegt.

Betroffen waren unter anderem:

  • WorldEdit

  • Health Bars

  • Puzzles Lib

  • Xaero's Minimap

  • Xaero's World Map

Die Mod-Zusammenstellung musste daher zunächst angepasst werden.

Das ist wahrscheinlich einer der wichtigsten Punkte bei Modded Minecraft überhaupt:

Nicht automatisch davon ausgehen, dass eine Mod für die vorherige Minecraft-Version auch mit der neuen läuft.

Manchmal funktioniert es.

Manchmal startet der Server einfach nicht.

Und manchmal startet er sogar und man entdeckt das eigentliche Problem erst später.

Zweites Problem: Colossal Chests wollte Cyclops Core

Danach tauchte ein klassischer Mod-Abhängigkeitsfehler auf.

Colossal Chests benötigte:

Cyclops Core ab Version 1.30.0

Diese Abhängigkeit fehlte.

Zum Glück war der Fehler im Serverlog ziemlich eindeutig als Startblocker zu erkennen.

Das ist einer der Gründe, warum ich bei Problemen inzwischen zuerst ins Log schaue, statt wild Dateien auszutauschen.

Bei NeoForge steht dort häufig schon ziemlich deutlich:

  • welche Mod Probleme verursacht

  • welche Abhängigkeit fehlt

  • welche Mindestversion benötigt wird

Das spart viel Herumprobieren.

Fehlende Abhängigkeit nachinstalliert

Nachdem Cyclops Core in einer passenden Version ergänzt war, war zumindest dieser Startblocker erledigt.

Solche Abhängigkeiten sind bei Mods nichts Ungewöhnliches.

Viele Mods bringen ihre gemeinsamen Funktionen nicht selbst mit, sondern verwenden dafür zusätzliche Bibliotheks-Mods.

Das macht die Entwicklung sauberer.

Für den Serveradministrator bedeutet es allerdings:

Eine Mod kommt selten allein.

Drittes Problem: Minecraft-Client stürzt unter Windows ab

Der Server war aber nur die eine Hälfte der Geschichte.

Auch der Windows-Client machte anschließend Probleme.

Dort verursachte Carry On 2.12.0 einen Absturz mit folgender Meldung:

java.lang.NoSuchFieldError: ModConfig$Type COMMON

Die vorläufige Lösung war ziemlich pragmatisch:

Carry On aus dem Windows-Modordner entfernen und Minecraft erneut testen.

Gerade bei einem Versionssprung finde ich diese Vorgehensweise sinnvoll.

Wenn ein Fehler klar auf eine einzelne Mod zeigt, muss man nicht gleich die komplette Installation zerlegen.

Erst die verdächtige Mod deaktivieren.

Dann erneut starten.

Wenn es funktioniert, hat man den Kandidaten gefunden.

Server und Client müssen zusammenpassen

Bei einem modifizierten Minecraft-Server kommt noch ein weiterer Punkt dazu:

Server und Client müssen kompatibel bleiben.

Das betrifft nicht nur die Minecraft-Version.

Auch NeoForge und verschiedene Mods müssen zueinander passen.

Ein Server kann technisch sauber starten und trotzdem keine Verbindung vom Client erlauben, wenn dort andere Mod-Versionen installiert sind.

Deshalb gehört für mich nach einem Update immer beides zum Test:

Startet der Server vollständig?

und:

Kann sich der Client anschließend wirklich verbinden?

systemd macht die Serververwaltung angenehm

Mein Server läuft über systemd.

Dadurch sind die wichtigsten Befehle ziemlich übersichtlich.

Server starten

systemctl start minecraft_forge

Server stoppen

systemctl stop minecraft_forge

Server neu starten

systemctl restart minecraft_forge

Status prüfen

systemctl status minecraft_forge

Live-Log anzeigen

journalctl -u minecraft_forge -f

Diese Befehle habe ich mir inzwischen praktisch angewöhnt.

Besonders das Live-Log ist bei Updates Gold wert.

„Java läuft“ bedeutet noch nicht „Minecraft läuft“

Ein interessanter Punkt aus meinem Update:

Der systemd-Dienst startete erfolgreich einen Java-Prozess.

Das bedeutet aber noch nicht automatisch, dass der Minecraft-Server vollständig geladen wurde.

Der entscheidende Punkt ist die bekannte Meldung:

Done (...)!

Erst wenn diese im Log auftaucht, ist der Weltstart tatsächlich abgeschlossen.

In meinem Wartungsprotokoll war dieser vollständige Start zu diesem Zeitpunkt noch nicht bestätigt.

Das ist ein kleiner, aber wichtiger Unterschied.

systemctl status kann durchaus freundlich aussehen, während Minecraft selbst im Hintergrund noch an einer Mod scheitert.

Nach einem Update deshalb immer das Log kontrollieren

Ich würde mich nach einem NeoForge-Update nie ausschließlich auf:

systemctl status minecraft_forge

verlassen.

Besser zusätzlich:

journalctl -u minecraft_forge -f

öffnen und beobachten, ob die Welt wirklich vollständig geladen wird.

Das gleiche gilt übrigens auch bei einem Neustart nach Mod-Änderungen.

Grün bedeutet bei systemd zunächst nur:

Der Prozess lebt.

Nicht unbedingt:

Der Minecraft-Server ist glücklich.

Backup vorher – und danach auch prüfen

Vor einem solchen Update gehört natürlich ein vollständiges Backup dazu.

Wichtig finde ich inzwischen aber auch den zweiten Schritt:

Das Backup anschließend auf Vollständigkeit prüfen.

Ein Backup zu besitzen ist schön.

Ein Backup zu besitzen, das später tatsächlich wiederhergestellt werden kann, ist deutlich schöner.

In meinem Fall gehört die Kontrolle des erstellten Backups noch zu den offenen Punkten.

Für zukünftige Updates habe ich mir eine klare Reihenfolge notiert

Aus der Aktion ergibt sich für mich inzwischen ein recht klarer Ablauf.

Vor dem nächsten Update würde ich immer zuerst den Server stoppen und eine vollständige Sicherung erstellen.

Danach kontrolliere ich:

  • Zielversion von Minecraft

  • passende NeoForge-Version

  • Java-Version

  • Mod-Kompatibilität

  • benötigte Mod-Abhängigkeiten

  • Client-Mods

Erst danach wird der eigentliche Server aktualisiert.

Genau diese Punkte habe ich auch in meinem Wartungsprotokoll festgehalten.

Mods am besten vorher prüfen

Der größte Zeitfresser waren letztlich nicht Minecraft oder NeoForge selbst.

Es waren die Mods.

Deshalb würde ich beim nächsten Versionssprung bereits vor dem Update kontrollieren, welche Mods eine Version für das neue Minecraft anbieten.

Besonders wichtig sind Bibliotheken wie:

  • Puzzles Lib

  • Cyclops Core

  • andere gemeinsame Abhängigkeiten

Fehlt eine davon, können gleich mehrere Mods ausfallen.

Beim Rollback nicht nur run.sh zurückdrehen

Ein weiterer wichtiger Punkt betrifft den Rückweg.

Wenn ein Update wirklich scheitert, sollte man nicht einfach nur den alten Versionspfad in run.sh eintragen.

Besser ist es, den kompletten gesicherten Serverzustand wiederherzustellen.

Das betrifft unter anderem:

  • Mods

  • Konfigurationen

  • Libraries

  • Weltdateien

  • Startdateien

  • NeoForge-Dateien

Gerade Mods können während eines Starts Konfigurationen oder sogar Weltdaten verändern.

Ein halber Rollback ist deshalb nicht unbedingt ein sauberer Rollback.

Mein bisheriger Stand

NeoForge 26.3.0.97 wurde erfolgreich installiert.

Der systemd-Dienst konnte anschließend auch einen Java-Prozess starten.

Noch offen waren zum Zeitpunkt meines Protokolls allerdings:

  • vollständigen Weltstart bestätigen

  • Windows-Client ohne Carry On erneut testen

  • Backup kontrollieren

Genau deshalb würde ich das Update zu diesem Zeitpunkt noch nicht als vollständig abgeschlossen bezeichnen.

Installiert ist die neue Version.

Jetzt muss sie nur noch zeigen, dass sie auch wirklich sauber läuft.

Mein Eindruck

Das eigentliche NeoForge-Update war ziemlich problemlos.

Der Installer lief durch, die Startdateien wurden angepasst und der neue Server ließ sich grundsätzlich starten.

Die Arbeit kam danach.

Und genau das ist bei Modded Minecraft wahrscheinlich keine große Überraschung.

Minecraft selbst aktualisiert man relativ schnell.

Danach beginnt das kleine Gesellschaftsspiel:

Welche Mod möchte heute nicht mehr?

In meinem Fall waren es erst mehrere alte 26.2-Versionen, dann eine fehlende Cyclops-Core-Abhängigkeit und schließlich Carry On auf dem Windows-Client.

Alles lösbare Probleme.

Aber zusammen eben doch deutlich mehr als nur:

„Neue JAR installieren und fertig.“

Fazit

Mein Minecraft-NeoForge-Server wurde von Minecraft 26.2 mit NeoForge 26.2.0.59 auf Minecraft 26.3 mit NeoForge 26.3.0.97 aktualisiert.

Die NeoForge-Installation selbst verlief problemlos.

Schwieriger waren anschließend die Mods.

Mehrere Erweiterungen waren noch für Minecraft 26.2 vorgesehen, bei Colossal Chests fehlte Cyclops Core und Carry On 2.12.0 brachte den Windows-Client zum Absturz.

Für mich bleiben deshalb nach diesem Update vor allem drei Regeln hängen:

Vorher vollständiges Backup erstellen.

Jede Mod und ihre Abhängigkeiten kontrollieren.

Nach dem Update nicht nur schauen, ob Java läuft – sondern ob Minecraft wirklich vollständig startet und der Client verbinden kann.

Dann ist ein NeoForge-Update zwar immer noch kein Ein-Klick-Vorgang.

Aber zumindest weiß man ziemlich genau, wo man suchen muss, wenn Minecraft wieder einmal anderer Meinung ist.