Freshly created container with MC 1.20.6 results in failure to open ViaVersion, zip END header not found #34
Comments
|
I am having the exact same issue. I dug a little deeper and found out that the link being generated by the script is not being generated properly. For some reason the $ViaVersionVersion variable in the shell script is returning "pattern". Therefore the resulting link is something along the lines of "https://ci.viaversion.com/job/ViaVersion/lastBuild/artifact/build/libs/pattern". I ran the command itself that assigns data to the $ViaVersionVersion variable, and all I get is the string "pattern". The resulting "ViaVersion.jar" file that is downloaded is actually an HTML file that mirrors the "Not Found" page on Jenkins. I hardcoded the link to a specific version of ViaVersion, it worked fine. I just had to comment out the code resposible for updating ViaVersion, and manually update ViaVersion when a new update releases. In addition to commenting out the code responsible for updating ViaVersion, you can install the AutoViaUpdater plugin at: https://www.spigotmc.org/resources/autoviaupdater.109331/ to continue to autoupdate ViaVersion, along with ViaBackwards, and ViaRewind. |
|
Glad I'm not the only one experiencing this. Thanks for sharing your solution. |
+1 to this issue replicated here too. Same corrupt ViaVersion.jar being downloaded, same file size (9737) Further to the solution provided by @TylerJohnson177 (you can edit start.sh from line 173), or more easily you can disable ViaVersion by recomposing with environment variable NoViaVersion: "Y". If you do need ViaVersion, you can download the AutoViaUpdater.jar to your plugins folder and that will still auto-update ViaVersion for you even though you have NoViaVersion: "Y" env var set. Don't forget to restart your container as per the AutoViaUpdate install notes - "The first time you start the server, you will need to restart it again since it installs all the Vias the first time and actually enables them on the second restart." |
|
I ran into this issue ~3 days ago and I was able to resolve this by doing the following steps (thanks everyone in this thread for the clues!):
Not sure if this is the best way to do this, but these steps got me back up and running again so I wanted to share. Thanks all! |
|
Actually with my steps above, I am still facing an issue which I never had previously: Bedrock clients (1.21.20) can connect for ~10-15 minutes and then after some time every bedrock client is disconnected at the same time. Docker logs show "[Geyser-Spigot] {username} has disconnected from the Java server because of Bedrock client timed out". (I don't see anything else inside the docker logs which indicates an issue) Is anyone else facing this issue? And any idea how to troubleshoot this? |
I followed the method @TylerJohnson177 did and Bedrock clients haven't been getting booted in my case. I pulled the git repo, commented out all code in start.sh dealing with ViaVersion, and built the image locally. I don't think it should make a difference with the edited start.sh but I set NoViaVersion=Y in my docker compose just in case. I'd assume using the ViaVersion updater plugin shouldn't behave differently than downloading it manually, so you might want to check for other configuration issues especially if you try this method and have the same problem. start.sh:165-202 .....
# Update Geyser
echo "Updating Geyser..."
if [ -z "$QuietCurl" ]; then
curl -H "Accept-Encoding: identity" -H "Accept-Language: en" -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4.212 Safari/537.36" -o /minecraft/plugins/Geyser-Spigot.jar "https://download.geysermc.org/v2/projects/geyser/versions/latest/builds/latest/downloads/spigot"
else
curl --no-progress-meter -H "Accept-Encoding: identity" -H "Accept-Language: en" -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4.212 Safari/537.36" -o /minecraft/plugins/Geyser-Spigot.jar "https://download.geysermc.org/v2/projects/geyser/versions/latest/builds/latest/downloads/spigot"
fi
echo "ViaVersion update process has been disabled in /scripts/start.sh. Check for updates manually"
# COMMENT OR DELETE all ViaVersion lines. and don't forget to leave the fi below (I did lol)
fi
# Accept EULA
AcceptEULA=$(echo eula=true >eula.txt)
.....docker-compose.yml services:
minecraft-server:
container_name: minecraft-server
restart: always
build:
context: .
dockerfile: ./amd64.Dockerfile
ports:
- "25565:25565"
- "19132:19132"
- "19132:19132/udp"
volumes:
- ./minecraft:/minecraft
stdin_open: true # docker run -i
tty: true # docker run -t
entrypoint: [ "/bin/bash", "/scripts/start.sh" ]
# Environment variables
environment:
Port: "25565"
BedrockPort: "19132"
TZ: "America/Los Angeles" # Timezone
#BackupCount: 10 # Number of rolling backups to keep
MaxMemory: 4096 # Maximum memory usage for Java
Version: 1.20.6 # Use custom version
#NoBackup: "plugins" # Optional folder to skip during backups
NoPermCheck: "Y" # Optional flag to skip permissions check
#NoViaVersion: "Y" # Optional flag to disable ViaVersion plugin
#QuietCurl: "Y" # Optional flag to reduce curl log output by suppressing progress meter
|
|
@morganmattr Also I'm using Minecraft 1.20.6 for the server, so it's possible that your issue is version specific. |
|
Thank you @spktkl!! I did exactly this (set Version: 1.20.6 and those edits to start.sh) and now the server hasn't had any of these Bedrock disconnects in ~12 hours that require a server restart, so I think I am good now. Appreciate the quick help and work around advice! |
|
The issue is in So I made pull request #35 to fix it :) |
Came here to say that I found the exact root cause of the issue. Nice synopsis. For now, I'm just setting the |
Context
On startup, the server log shows the error 'java.lang.RuntimeException: Failed to open plugin jar plugins/ViaVersion.jar' &
Caused by: java.util.zip.ZipException: zip END header not found. Other plugins don't load or even show a failure message in the log. Removing and reinstalling ViaVersion did not solve the issue.The error started happening this morning 2024-09-04, and the server was running fine using this image before that point. Since there hasn't been a new release of LJMGF, I'm guessing there was an update in one of the dependencies that bricked it.
I reproduced the error by doing
docker compose up -dwith the below docker-compose.yaml in an empty volume with no plugins or world data added. I tried with and without NoPermCheck and got the same result.docker-compose.yaml
Log
The text was updated successfully, but these errors were encountered: