no matching manifest for linux/arm64/v8 in the manifest list entries

[Rascalov]

Can't seem to pull images for my ARM device. Is ARM no longer supported? only issue on ARM i've seen was https://github.com/binhex/arch-privoxyvpn/issues/7

[samsawyer]

I just ran into the same issue after upgrading to macOS Sequoia 15 on an M3 MacBook Pro today — a privoxyvpn set up that had been running perfectly with a colima virtual machine using the arm64 architecture suddenly started reporting "no matching manifest for linux/arm64/v8" when I tried to bring it up with docker compose.

Would appreciate any help or advice for working on this.

[binhex]

you will need to define the architecture you want if it's not amd64, so add --platform linux/arm64 to your run command.

[samsawyer]

I added platform: linux/arm64 to the docker-compose.yml file and got: no matching manifest for linux/arm64 in the manifest list entries

Also, a docker manifest inspect binhex/arch-privoxyvpn results in:

{
   "schemaVersion": 2,
   "mediaType": "application/vnd.oci.image.index.v1+json",
   "manifests": [
      {
         "mediaType": "application/vnd.oci.image.manifest.v1+json",
         "size": 2949,
         "digest": "sha256:93f56246444d2894456f10e2d0aff6a69e9e56ff21515970398b03a6aa72cd57",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.oci.image.manifest.v1+json",
         "size": 567,
         "digest": "sha256:7b4c6dd963c7cb156f653497ca9fa70ff6e9c1ed0a04622388afb7a2ea7a6479",
         "platform": {
            "architecture": "unknown",
            "os": "unknown"
         }
      }
   ]
}

However, docker manifest inspect binhex/arch-privoxyvpn:3.0.34-3-03 does show that arm64 architecture is available, but it vanishes from docker manifest inspect binhex/arch-privoxyvpn:3.0.34-3-04.

And if I remove the platform: arm64 line from my docker-compose.yml but add in the 3.0.34-3-03 tag for the image, then everything works as it did previously.

So maybe something got broken or misconfigured in the image build process?

[Updated to add after some investigation: Looks like the commit de0623eac2da0880d237a533a8e8d001ea89879e removed the linux/arm64 platform from workflow-docker-manual.yml and ccc3ae19e0a6fe43c5d8230185ce3d8dcc7f79d7 removed it form workflow-docker-release.yml ]

[samsawyer]

Updating to add: actually, binhex/arch-privoxyvpn:3.0.34-3-03 will launch, but does not work as it did previously — its output stops at [info] Script finished to assign incoming port because I was not using a PIA server that supported port forwarding. Once I switched to a server that supported port forwarding then the image was able to continue and actually get privoxy started.

binhex/arch-privoxyvpn:3.0.34-3-02 worked without requiring a port-forwarding server.

So something changed between 3.0.34-3-02 and 3.0.34-3-03 that meant the image would never launch privoxy if the remote server did not port forward, and then something changed between 3.0.34-3-03 and 3.0.34-3-04 that removed arm64 as an available platform.

[binhex]

So something changed between 3.0.34-3-02 and 3.0.34-3-03 that meant the image would never launch privoxy if the remote server did not port forward

OK so this was an on purpose change to include port forwarding functionality to the privoxyvpn image, if you want to connect to endpoint that does not support port forwarding then set STRICT_PORT_FORWARD to 'no' or alternatively if you do want a incoming port assigned then set it to 'yes'.

and then something changed between 3.0.34-3-03 and 3.0.34-3-04 that removed arm64 as an available platform.

So this was due to a refactor of the workflows caused by npm version bump in the actions, I have now put the additional arm64 platform back and a new image has been built, please pull down binhex/arch-privoxyvpn:3.0.34-3-06, you will still need to specify --platform linux/arm64 for your docker run/compose in order to force the correct architecture.

[samsawyer]

Thanks for fixing the image. It works fine for me now, even without specifying the platform explicitly — at least on my setup, Docker can figure out the matching image automatically.

Re: STRICT_PORT_FORWARD, thanks for explaining that. Maybe worth putting that in the documentation, or adding a more visible log message to explain what happens when it doesn't work? Right now, the only log message is:

PIA endpoint 'servername.privacy.network' is NOT in the list of endpoints that support port forwarding shown below:-

and then a long list of port-forwarding supported servers, making that first message easy to miss, even if it was readily understood as communicating that it causes failure of the whole system rather than just failure of port-forwarding. It would be really helpful to have a log message after the server list that says:

To use 'servername.privacy.network' without port forwarding, set STRICT_PORT_FORWARD=no.
Otherwise privoxy and microsocks will not be started.

Otherwise, it amounts to an almost silent breaking change, and — at least what I would have expected for behavior here — is that the image would work fine without port forwarding unless I specifically told it that I wanted to require port forwarding. (I.e., it seems like the saner, non-breaking default for STRICT_PORT_FORWARD would have been "no" rather than "yes".)

[binhex]

Thanks for fixing the image. It works fine for me now, even without specifying the platform explicitly — at least on my setup, Docker can figure out the matching image automatically.

That's interesting!, ony my Odroid N2+ Arm64 box i need to specify the platform, i assume its due to an older version of docker on that device that perhaps does not do the clever working out of the architecture for you, good to know!.

Re: STRICT_PORT_FORWARD, thanks for explaining that. Maybe worth putting that in the documentation, or adding a more visible log message to explain what happens when it doesn't work? Right now, the only log message is:

I do have all the variables documented here, as well as a plethora of FAQ's here, but i take your point that the in log message could be clearer and should point out the option of switching STRICT_PORT_FORWARD to 'no' if no incoming port is required.

is that the image would work fine without port forwarding unless I specifically told it that I wanted to require port forwarding. (I.e., it seems like the saner, non-breaking default for STRICT_PORT_FORWARD would have been "no" rather than "yes".)

I totally get where you are coming from but this image is layered and is built from the intermediate image arch-int-vpn, this is then used to build multiple other vpn enabled images, so its tricky to set to 'no' for this image and 'yes' (torrent images mainly so having a working incoming port is important) for the others, i shall have a think about it - just FYI, for UNRAID users in the privoxyvpn template the default is 'no', i assume you are not using UNRAID though.