On M1 systems, commands for running amd64 images are corrupted

[thedadams]

Actual Behavior

Passing commands at the end of a docker run command doesn't work as expected.

Steps to Reproduce

Running the following command docker run --rm --platform linux/amd64 --entrypoint ls busybox -lR /.

Result

The output is: lR: applet not found

Expected Behavior

The output of running ls -lR / (which is a lot) should be produced.

Additional Information

Running docker run --rm --entrypoint ls busybox -lR / (without the --platform flag) works as expected.

Additionally, running docker run --rm --platform linux/amd64 --entrypoint ls busybox -lR / using Docker Desktop works as expected (just for reference as to why I see this as a bug).

Rancher Desktop Version

1.5.0

Rancher Desktop K8s Version

N/A

Which container engine are you using?

moby (docker cli)

What operating system are you using?

macOS

Operating System / Build Version

Monterey 12.5

What CPU architecture are you using?

arm64 (Apple Silicon)

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

No response

[jandubois]

I can confirm this.

The issue is with the cross-platform emulation, as docker run --rm --platform linux/arm64 --entrypoint ls busybox -lR / runs fine. And on an Intel Mac it is the other way around (the --platform linux/arm64 shows the error, but --platform linux/amd64 works fine).

[jandubois]

I've confirmed that this is a regression from Rancher Desktop 1.4.1.

It affects both docker and nerdctl.

When I copy the alpine-lima ISO from 1.4.1 over the basedisk (while RD 1.5.0 is stopped), then the commands work again after starting RD once again.

So I expected this to be related to the update of containerd from 1.5.1 to 1.6.6. But things work fine with 1.6.6 with pure Lima, both with the default Ubuntu VM, but also with the "standard" alpine-lima image. And this is with identical docker versions (20.10.16). So I don't know what might be causing this.

[jandubois]

but also with the "standard" alpine-lima image.

Actually no, I was running the amd64 image on an Intel mac, so that was expected to pass. Running the arm64 image failed with plain Lima and the standard alpine image:

$ limactl start template://alpine
[...]
$ limactl shell alpine sudo -i
lima-alpine:~# apk add docker
[...]
OK: 251 MiB in 81 packages
lima-alpine:~# rc-service docker start
 * Caching service dependencies ...                                                                                   [ ok ]
 * /var/log/docker.log: creating file
 * /var/log/docker.log: correcting owner
 * Starting Docker Daemon ...                                                                                         [ ok ]
lima-alpine:~# docker run --rm --platform linux/arm64 --entrypoint ls busybox -lR /
Unable to find image 'busybox:latest' locally
latest: Pulling from library/busybox
98b248744137: Pull complete
Digest: sha256:0e97a8ca6955f22dbc7db9e9dbe970971f423541e52c34b8cb96ccc88d6a3883
Status: Downloaded newer image for busybox:latest
lR: applet not found

[jandubois]

I was hoping to do some bisecting on the changes between alpine-lima 0.2.17 and 0.2.18. There are only a few changes there, and it very much looks like one of them is responsible for this regression.

[danganea]

Also affects previous images that have only an amd64 image but previously worked via emulation.

docker run --rm -it  mcr.microsoft.com/azure-storage/azurite

docker-entrypoint.sh: applet not found

[knkarthik]

Same for me. I could run mysql:5.7.37 on Mac M1 with Rancher 1.4 but not with 1.5

docker run --platform linux/amd64 docker.io/mysql:5.7.37
/usr/sbin/mysqld: /usr/sbin/mysqld: cannot execute binary file

[ericpromislow]

I'm WFH only on an amd64 macOS machine, but can't run

docker run --rm --platform linux/arm64 --entrypoint ls busybox -lR /

with both Rancher Desktop 1.4.1 and 1.5.0. I'm not sure if this is even supported. Is it possible that the emulation is only one way (for running an amd64 image on an arm64 host)?

[gaktive]

Might be related to the M1 chip.

[oidualc]

Is there a workaround to use Rancher Desktop 1.5.0 while this is getting fixed in the next release?

[mook-as]

Please see #2668 (comment) for a workaround.