Docker update/version "not available"


TheBrian
Go to solution Solved by TheBrian,

Recommended Posts

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.

image.png.0aa5b593672c62839c1e4d6c13c8b63c.png

 

My other container works fine.

image.png.05f3b65c04634f5cd5c88698002aaf04.png

 

Any help is appreciated.

 

 

 

-Brian

Link to comment

Without trying to hijack your thread...  I'm having multiple containers that do this and I don't have the answer. I can find the 'broken link' on dockerhub and can't say it is always a specific docker over another (I have several that do this and several that don't).  However I have found if you 'force update' the container it returns to an up to date status.  I haven't seen any commonalities and I'm just starting to research the problem here in the forums when I found your thread.

Link to comment
  • Solution

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

image.png.3123cff5eeb58e63bbeab43d1e230d91.png

 

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":

image.png.c2e1f5241f4d300d17c71a29480772e7.png

 

After clicking "apply update":

image.png.97fde7b211e860c3be28fc66d40bc6a2.png

 

After clicking "apply update" and "check for updates:"

image.png.70c233db7ccb50f6bb18a1cd989d35f8.png

 

 

TL;DR: add "--format=docker" to your docker/podman build command.

 

-Brian

 

 

 

 

Edited by TheBrian
  • Like 4
  • Thanks 3
  • Upvote 1
Link to comment
  • 4 weeks later...

Just to note that I'm having the same issue on a few dockers. At first I thought it was because I had an issue with my DNS (pihole) but changing unraid DNS to use 1.1.1.1 and 8.8.8.8 didn't fix.

 

To add assault to injury, when I try to add --format=docker as an extra parameter as suggested above, the docker don't compile anymore :( I receive the following error message: 

  -u 99:100

  --format=docker 'coderaiser/cloudcmd'

unknown flag: --format

 

Any assistance will be appreciated!

Link to comment
5 hours ago, Guesch said:

Just to note that I'm having the same issue on a few dockers. At first I thought it was because I had an issue with my DNS (pihole) but changing unraid DNS to use 1.1.1.1 and 8.8.8.8 didn't fix.

 

To add assault to injury, when I try to add --format=docker as an extra parameter as suggested above, the docker don't compile anymore :( I receive the following error message: 

  -u 99:100

  --format=docker 'coderaiser/cloudcmd'

unknown flag: --format

 

Any assistance will be appreciated!

 

 

I don''t think we can change this for running containers:
see here

 

I have not yet tried the solution offered by @m33ts4k0z

 

He changes this line:

Quote

$header = ['Accept:application/vnd.docker.distribution.manifest.list.v2+json,application/vnd.docker.distribution.manifest.v2+json'];

 

to

 

Quote

$header = ['Accept:application/vnd.docker.distribution.manifest.list.v2+json,application/vnd.docker.distribution.manifest.v2+json,application/vnd.oci.image.index.v1+json'];


But I cannot oversee the possible implications for changing a main docker file, as other systems might be depending on it?

Edited by PaulV86
Link to comment
1 hour ago, PaulV86 said:

 

 

I don''t think we can change this for running containers:
see here

 

I have not yet tried the solution offered by @m33ts4k0z

 

He changes this line:

 

to

 


But I cannot oversee the possible implications for changing a main docker file, as other systems might be depending on it?

This wont affect anything else. I suppose it will also be integrated by the Unraid team.

Edited by m33ts4k0z
Link to comment
  • 5 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.