FTB Direwolf18 installation failing (at least with direwolf 1.18.0, not sure about the rest)

[ThatCoffeeGuy]

First of all, thank you for your work on this image - very useful and nicely developed.

Describe the problem

The issue I am facing:

After changing modpack version ID in docker-compose (2142 --> 2234), to update from direwolf18 1.5.1 to 1.8.0, the installer complained of not being able to download all mods, crashed the process and rendered the server unable to start.

2022/08/05 21:08:38 Downloaded 491 successful, 266 failed, 0 incomplete.

Using serverinstall_95_2234 file downloaded from FTB, will download all the required mods, but will also break something, because running the docker image will end up like this:

[22:24:21] [main/ERROR] [ne.mi.fm.lo.ModSorter/LOADING]: Missing mandatory dependencies: forge, forge, forge, forge, forge

After trying a lot of copying and trying to match required dependencies, I somehow ended up with:

[init] ERROR unable to locate the installed FTB server jar
minecraft_server.1.18.2.jar 

While obviously, the file is present...

Thanks!

Container definition

version: "3"

services:
  mc:
    image: itzg/minecraft-server
    ports:
      - 25569:25565
      - 8127:8123
      - 21565:21565
    environment:
      EULA: TRUE
      TYPE: "FTBA"
      FTB_MODPACK_ID: "95"
      FTB_MODPACK_VERSION_ID: "2234" # 1.8.0
      MOTD: "Modded MC FTW! Direwolf 1.18 1.8.0"
      ONLINE_MODE: true
      SERVER_NAME: "FTB Direwolf 1.18 1.8.0"
      ENABLE_RCON: true
      ENABLE_QUERY: true
      QUERY_PORT: 21565
      INIT_MEMORY: "4G"
      MAX_MEMORY: "8G"
      TZ: "Europe/Budapest"
      ENABLE_QUERY: true
      ALLOW_FLIGHT: true
    tty: true
    stdin_open: true
    restart: unless-stopped
    volumes:
      - /mnt/ftb-direwolf18broken:/data


  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: 'dynmap'
      MYSQL_USER: 'dynmap'
      MYSQL_PASSWORD: 'dynmap'
      MYSQL_ROOT_PASSWORD: 'dynmap'
    ports:
      - '3306:3306'
    expose:
      - '3306'
    volumes:
      - /mnt/ftb-direwolf18-dynmap-mysql:/var/lib/mysql

Container logs

log.txt

[itzg]

As currently implemented there are a couple of challenges to solve this. Since the container startup script downloads and uses FTB's installer, the failed downloads will be something their installer encountered. You may want to look closer at the installer logs to see if it gave any clues about why the downloads failed. You also may want to contact FTB.

As for upgrading in place, that's a tricky one since again the installer is taking over file management. As a result, the container startup doesn't know what to clean up from an upgrade. I'm afraid it might actually be easier to transplant the world data into a new container.

Side note: I'm going to be starting to work on revamping all of the modpack support, so I'll add an entry to look at using the FTB directly to obtain and manage modpacks and their files.

[ThatCoffeeGuy]

IIRC manually trying the container bundled installer (ftb_installer) resulted with the same download errors (seemingly a wget parsing bug?), while using the one downloaded from the link above downloaded all ~700 files successfully. - not exactly sure how it works, but couldn't it be an outdated installer bin?

[itzg]

Ah, it could be. I do see in the script that it will skip downloading the installer if it sees one already downloaded. One thing to try is manually deleting ftb-installer -- the container itself doesn't bundle the installer, it just got downloaded during a previous startup.

[Rirush]

This is an issue on FTB side. There were changes in the way they represent modpacks in their API, and that broke a lot of things. Here's a related issue: https://github.com/FTBTeam/FTB-Modpack-Issues/issues/1158

I tried doing a clean install, and it works without issues. The image is downloading the latest ftb-installer - 22.724.1015.

I've encountered those download issues in the past, I managed to go around them by removing version.json and running the installer manually, but this way, run.sh will not be created, and the error above will occur (unable to locate FTB server jar). This can be fixed by doing java -jar forge-1.18.2-40.1.67-installer.jar --installServer, it'll install forge correctly, and create run.sh.

Btw, I personally find the output of "unable to locate FTB server jar" misleading. It's not clear that it's outputting the .jar files it found, not the .jar files it wants.

[itzg]

Thanks @Rirush !

I'm not sure how to address this comment though:

I personally find the output of "unable to locate FTB server jar" misleading. It's not clear that it's outputting the .jar files it found, not the .jar files it wants.

Would you really want it to output all jar files present when it fails to find the forge server jar or run.sh? That would be a lot of files considering all the mods and the libraries of forge.

[Rirush]

Would you really want it to output all jar files present when it fails to find the forge server jar or run.sh? That would be a lot of files considering all the mods and the libraries of forge.

No, of course not, that's too much :D It already outputs the list of all .jar files in the /data directory (https://github.com/itzg/docker-minecraft-server/blob/master/scripts/start-deployFTBA#L85), but from the wording, it might seem that those are the files it searches for, instead of those that it found. Maybe adding a remark that those are the files in /data would clear it up, not sure.

Also, the only way to find out what files actually can the script launch seems to be to look at the sources of that script. Not sure, but it might be better if that script outputted $variants, so that when you encounter this issue, you know what files can satisfy it.

[garbelini]

Would you really want it to output all jar files present when it fails to find the forge server jar or run.sh? That would be a lot of files considering all the mods and the libraries of forge.

Yeah, if upstream makes breaking changes it's complicated. I do think a slightly more verbose error message mentioning the locations it looked for the installer would be helpful though.

[itzg]

Yep, output has been adjusted in the most recent image.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please add a comment describing the reason to keep this issue open.