TheBrian

BepInEx requires this directory and libraries be removed. V+ is just a mod (one of thousands) that experiences this problem because the issue isn't with the mod but with BepInEx. This also isn't really a bug but more of a hygiene/clean-up issue. BepInEx no longer requires these libraries and if they exist, the game tries to load them but fails simply because they've been deprecated and should no longer be used. I would trigger off of BepInEx being enabled which would allow your container to work with any mod.

If BepinEx is enabled, the unstripped_corlib directory should be removed. V+ requires BepInEx, so if this is the only mod you're supporting, then I suppose yes, you can trigger off of v+ being enabled.

They're no longer needed. If they're seen, the game crashes:

delete the 'unstripped_corlib' directory.

I found my temporary root password at "/mnt/cache/appdata/<my container data dir>/config/initial_root_password"

I figured it out. This isn't a CA or unRAID issue. It's OCI compatibility with DockerHub. Hopefully this can help someone else. My debugging process: I grepped through the entire directory /usr/local/emhttp/plugins/dynamix.docker.manager/include for "not available" which is the HTML label shown in the Unraid Docker UI To prove to myself that I found the right label, I added the "!" you see in the screenshot above. This label is inside a case/switch condition. I.e., 0="up-to-date", 1="update ready", 2="rebuild ready" else, "not available" within the DockerContainers.php file. My containers were returning a NULL value which results in the "default/else" (not available message). This condition evaluates the variable "$updateStatus". This variable is set by an array read of the $info['updated'] array element. This variable is set by DockerClient.php and where most of my debugging occurred. /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php: I added the following to the "getRemoteVersionV2" function to assist in debugging. $file = '/tmp/foo.txt'; file_put_contents($file, PHP_EOL . $image . '(' . $manifestURL . ')' . ' ', FILE_APPEND); This sent me on a reverse engineering journey and helped me create a little test script: #!/bin/bash repo="theoriginalbrian/phvalheim-server" TOKEN=$(curl --silent "https://auth.docker.io/token?scope=repository:$repo:pull&service=registry.docker.io" | jq -r '.token') curl --header "Accept: application/vnd.docker.distribution.manifest.v2+json" --header "Authorization: Bearer $TOKEN" "https://registry-1.docker.io/v2/$repo/manifests/latest" The output of this little test script: {"errors":[{"code":"MANIFEST_UNKNOWN","message":"OCI manifest found, but accept header does not support OCI manifests"}]} A bit of research landed me in DockerHub API documentation...in short, OCI images do not contain the SHA256 image digest (at least in the location DockerHub expects). This led me to look at how I'm building my images. My dev system is just a simple Rocky 8.6 (EL) VM, which runs podman. By default, podman builds in the OCI format. Simply passing "--format=docker" to my podman build command solved the issue. Results: After clicking "check for updates": After clicking "apply update": After clicking "apply update" and "check for updates:" TL;DR: add "--format=docker" to your docker/podman build command. -Brian

It looks like we're alone on this one.

You're likely having the same issue. I use other containers from CA that I didn't author and also have this issue.

I'm wondering if someone can help with a published Unraid+Docker app problem. I've built 2 containers and published them to CA. One of the containers (phvalheim-server) show updates "not available". The other (intel-gpu-telegraf) works fine. The .xml templates are very similar and I can't seem to figure out how to fix this. I'm getting complaints from people using Unraid that this new container (phvalheim-server) is showing "not available" on everyone's installation. Including mine and two of my test systems. The only search results I find are related to all containers having this issue which is DNS related or a bug prior to 6.9. I'm on 6.11.5 and all versions since creating this container have had this issue. Template for phvalheim-server: https://github.com/brianmiller/docker-templates/blob/master/phvalheim-server/phvalheim-server.xml Template for intel-gpu-telegraf: https://github.com/brianmiller/docker-templates/blob/master/intel-gpu-telegraf/intel-gpu-telegraf.xml Here is a screenshot showing the issue. My other container works fine. Any help is appreciated. -Brian

I would like this too.

I'm seeing the same issue with one of my containers that I built. I have another that has a similar unraid docker template that doesn't have this issue.

6.11.3 fix my issue.

Bummer... I just upgraded to 6.11.2 last night and attempted a new disk install... same issue. Unsupported partition layout. While it's easy to say downgrade--for those of us with a mature system, it's not so easy to just shutdown I'll be waiting for 6.11.3.

Same question here... we just installed it in two locations and love it, but noticed the UUD dashboard is waaaay behind. Should we continue using the container? It's pretty sweet...

Understood. V+ is a joke of assumptions and dependencies. BepInEx is critical though. I'll say, I'm nearing punting on everyone's containers and spinning my own because of this. I agree with you, the containers should allow for modding, but not have assumption built-in.