Udocker pulls image for the wrong processor architecture

[ddscentral]

udocker pull pulls image for the wrong processor architecture. When running under arm64, amd64 (aka. x86-64) image is pulled, even though a native arm64 image is available for that container. Correct behavior should match that of "docker pull" command: try to pull image for the host machine architecture first and if it isn't available, display a warning and pull image for a different architecture, usually amd64.

Platform: Android (Termux)

[dhanar10]

I am encountering the same problem trying to use udocker in termux. I tried to figure out what's wrong by running udocker -D pull hello-world. Looking at the debug output, it seems like udocker is fetching manifest v2 version 1 instead of version 2. I think this is probably the problem because according to docker docs I read, it looks like multi arch requires manifest v2 version 2. But CMIIW.

Edit: For clarity, my udocker is V1.3.8

[ddscentral]

I've noticed the manifest issue as well. Did some digging in the code but could not find a reason why manifest v1 is pulled. I work-arounded the wrong architecture issue by adding support for pulling images by their SHA256 hashes (Docker syntax: docker pull imagename@sha256:). This allows me to force udocker to request a specific image instead of a tag. Not the most convenient way, but it does the job. I can upload my patched version of udocker if anyone needs it (the code would require some cleaning-up for a proper PR).

[dhanar10]

@ddscentral Nice! I am interested with your patched version of udocker. I will be thankful if you can share it somewhere.

[ddscentral]

Link: udocker-1.3.7-patched-DDSC.tar.gz

Changes:

• Support for pulling images by sha256 hash.
• Support for QEMU user-mode emulation. Set QEMU_PATH environment variable to the path of your qemu-user binary (eg qemu-x86_64) before executing "udocker run" command.

I made this fork for my own uses and will not provide support for it. Code cleanup is welcome.

[dhanar10]

@ddscentral I have a couple of questions about your fork.

1. You added qemu multiarch stuff, so the use case is to run x86 image on arm, am i understanding it correctly?

2. Why did you add proot link2symlink here? What problem you are trying to solve here?

[ddscentral]

1. Yes, this allows to run images made for a different processor architecture (eg. x86 on ARM). This works similarly to https://github.com/tonistiigi/binfmt but in user mode and without requiring binfmt support.
2. Sorry, my comment probably isn't the clearest. Proot with link2symlink is required to workaround permission issues when extracting Docker images which contain hardlinks. This option converts them to symlinks. Without this, you would require root privileges to extract images which contain hardlinks.

[ddscentral]

Another note: when running udocker under Termux, you will need to replace the "proot" binary installed by Udocker with Termux version as the stock one will not work on Android.

[jorge-lip]

This issue should be fixed in release 1.3.9.

[mariojmdavid]

release 1.3.11 created