thanks for reporting this, we will check how to fix this in upcoming versions
Hmm. I recently trying to use ghcr,io as the "Container Registry" to pull /containers (e.g. /container/config/registry-url=
https://ghcr.io) with GitHub's CI for my own images.
Ran into this problem when building an image through GitHub's Actions however...
But I bet it be similar with the adguard image too.
GitHub's CI builder, by default uses "attestations" (metadata) and adds theses to the docker buildx:
docker buildx build --sbom=true --provenance=true ...
However, those options cause "fake platform" of "unknown/unknown" in the package (that must store them I guess) for download in the registry (e.g. GitHub's DockerHub).
And RouterOS gets the same 404 and "error" status as reported for adguard.
Removing those explicitly disabling in the GitHub workflow.yaml "build-and-push-docker-images" action fixed my custom package:
# ... - name: Build and push uses: docker/build-push-action@v4 with: context: . push: true sbom: false provenance: false platforms: linux/arm64,linux/arm/v7
But that's not so easily done for other people's packages. But default are "true" for both "sbom" and "provenance", and that breaks RouterOS's /container pull it seems... so that effect most public images built on GitHub I'd imagine.
This never would happen when using "docker save" locally, since the tar file doesn't support Docker's attestation AFAIK.