beonic-rufus
commented
6 months ago have the same issue on m3 mac
Open lculibrk opened 7 months ago
beonic-rufus
commented
6 months ago have the same issue on m3 mac
md-scalgo
commented
6 months ago I can consistently reproduce this with:
docker build --platform linux/amd64 --no-cache . -f-<<EOF
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3-pip
EOF
```
% docker build --platform linux/amd64 --no-cache . -f-<
M2 Max. Sonoma 14.3.1. ``` Client: Cloud integration: v1.0.35+desktop.13 Version: 26.0.0 API version: 1.45 Go version: go1.21.8 Git commit: 2ae903e Built: Wed Mar 20 15:14:46 2024 OS/Arch: darwin/arm64 Context: desktop-linux Server: Docker Desktop 4.29.0 (145265) Engine: Version: 26.0.0 API version: 1.45 (minimum version 1.24) Go version: go1.21.8 Git commit: 8b79278 Built: Wed Mar 20 15:18:02 2024 OS/Arch: linux/arm64 Experimental: false containerd: Version: 1.6.28 GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0 ``` ``` Client: Version: 26.0.0 Context: desktop-linux Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc.) Version: v0.13.1-desktop.1 Path: /Users/md/.docker/cli-plugins/docker-buildx compose: Docker Compose (Docker Inc.) Version: v2.26.1-desktop.1 Path: /Users/md/.docker/cli-plugins/docker-compose debug: Get a shell into any image or container. (Docker Inc.) Version: 0.0.27 Path: /Users/md/.docker/cli-plugins/docker-debug dev: Docker Dev Environments (Docker Inc.) Version: v0.1.2 Path: /Users/md/.docker/cli-plugins/docker-dev extension: Manages Docker extensions (Docker Inc.) Version: v0.2.23 Path: /Users/md/.docker/cli-plugins/docker-extension feedback: Provide feedback, right in your terminal! (Docker Inc.) Version: v1.0.4 Path: /Users/md/.docker/cli-plugins/docker-feedback init: Creates Docker-related starter files for your project (Docker Inc.) Version: v1.1.0 Path: /Users/md/.docker/cli-plugins/docker-init sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.) Version: 0.6.0 Path: /Users/md/.docker/cli-plugins/docker-sbom scout: Docker Scout (Docker Inc.) Version: v1.6.3 Path: /Users/md/.docker/cli-plugins/docker-scout Server: Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 9 Server Version: 26.0.0 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Using metacopy: false Native Overlay Diff: true userxattr: false Logging Driver: json-file Cgroup Driver: cgroupfs Cgroup Version: 2 Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog Swarm: inactive Runtimes: io.containerd.runc.v2 runc Default Runtime: runc Init Binary: docker-init containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc version: v1.1.12-0-g51d5e94 init version: de40ad0 Security Options: seccomp Profile: unconfined cgroupns Kernel Version: 6.6.22-linuxkit Operating System: Docker Desktop OSType: linux Architecture: aarch64 CPUs: 12 Total Memory: 46.97GiB Name: docker-desktop ID: f68b8506-6f06-4401-848b-e21e2580d14c Docker Root Dir: /var/lib/docker Debug Mode: false HTTP Proxy: http.docker.internal:3128 HTTPS Proxy: http.docker.internal:3128 No Proxy: hubproxy.docker.internal Labels: com.docker.desktop.address=unix:///Users/md/Library/Containers/com.docker.docker/Data/docker-cli.sock Experimental: false Insecure Registries: hubproxy.docker.internal:5555 127.0.0.0/8 Live Restore Enabled: false WARNING: daemon is not using the default seccomp profile ```
abregar
commented
5 months ago Reporting the exactly issue with M3pro(Sonoma 14.5.0) and Docker Desktop 4.30.0 (Server Version: 26.1.1). Interesting fact is, that with trial/failure loop, image build actually succeeds - but need to retry the same build in average ~6-8 times.
There are no other hints logged at any verbosity log level.
Is there anyone already figured potential issue and maybe any workaround?
abregar
commented
5 months ago Digging a bit more into this and since Ubuntu jammy has some nice debuginfo support. So, enabling coredump generation inside running container actually gives this log
Setting up ca-certificates (20230311ubuntu0.22.04.1) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 /usr/lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.34 /usr/share/perl/5.34 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.)
debconf: falling back to frontend: Teletype
Illegal instruction (core dumped)
Updating certificates in /etc/ssl/certs...
Illegal instruction (core dumped)
dpkg: error processing package ca-certificates (--configure):
installed ca-certificates package post-installation script subprocess returned error exit status 132
Errors were encountered while processing:
ca-certificates
E: Sub-process /usr/bin/dpkg returned an error code (1)and brief looking into the coredump with gdb unfortunatelly not showing full bt (I am not so keen in gdb .. hints appreciated!):
...
warning: Can't open file which was expanded to during file-backed mapping note processing
warning: core file may not match specified executable file.
warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
warning: Architecture rejected target-supplied description
warning: Couldn't find general-purpose registers in core file.
warning: Unexpected size of section `.reg2' in core file.
Core was generated by `/run/rosetta/rosetta /usr/bin/sed sed -e s/^[[:space:]]*//'.
warning: Couldn't find general-purpose registers in core file.
warning: Unexpected size of section `.reg2' in core file.
#0 <unavailable> in ?? ()
(gdb) bt
#0 <unavailable> in ?? ()
Backtrace stopped: not enough registers or memory available to unwind furtherbut at least it does tell what the culprit for this ticket is, meaning Core was generated by /run/rosetta/rosetta /usr/bin/sed sed -e s/^[[:space:]]*//'.
Does anyone here has some knowledge how to proceed with this further to solve?
shanesmith
commented
5 months ago I was able to work around the issue by disabling Rosetta in Docker Desktop.
huipengzhao
commented
5 months ago docker run --platform linux/amd64 -it ubuntu:22.04 /bin/bash
apt update && apt install ca-certificatesThis will reproduce the same issue on my M3 pro Macbook, but it's OK on a M1 pro Macbook. So it's like a rosetta bug.
m33ts4k0z
commented
3 months ago Hello same issue on M2 Pro Ventura/Sonoma. Disabling Rosetta indeed solves it but the build times are like double 😞
It does work if I try some times after it had failed. This is on Sonoma 14.6 and Docker Desktop 4.33
Solution: After spending hours on this. I finally figured it out. I was running Orbstack but trying Docker Desktop didn't make significant difference. So In the end what worked was to delete all files and directories manually for both platforms and reinstall one of them. Now I can compile with Rosetta without any errors.
This solved the issue for about a day or two. The problem still remains and the only solution right now is to disable Rosetta and run with qemu
genegoykhman
commented
3 months ago I just did a clean re-install of Docker Desktop 4.33.0 (160616) on Sonoma 14.6 and, fingers crossed, so far I'm able to buildx amd64 images on an M3 MacBook Pro. I'm using Rosetta as well as the Virtualization framework. Not sure if this is going to last but I'll post again if it starts failing.
drakon
commented
3 months ago Not sure how relevant this is here, but even if you get a an linux/amd64 image built, it might not run properly with Rosetta as it doesn't support for example AVX extensions (see also discussion here). When the underlying code doesn't handle/check for this, it might just crash the app. When this happened I got (python) just a non descriptive "Illegal instruction".
Disabling Rosetta and running with qemu then might work but be considerably slower.
EthanJStark
commented
2 months ago M3 user here, also experiencing this bug.
Clean Docker Install did not resolve it, deselecting Use Rosetta for x86_64/amd64 emulation on Apple Silicon in Docker Desktop settings did.
ShaMan123
commented
1 month ago Thank you for this thread. It was hard to find. I can confirm that disabling rosetta works for M2
gawainedwards
commented
1 month ago This worked for me too (on an M3 Pro).
You can turn the Rosetta emulation back on again once you have a cached docker layer containing the already installed ca-certificates. It is only the initial installation of the apt "ca-certificates" package that is a problem.
Description
I'm running Docker for mac version 25.0.3 on an M2 (arm64) machine.
When trying to build some relatively simple images using buildx on linux/amd64 arch, I get illegal instruction errors installing the ca-certificates package in the image. These happen only some of the time.
Reproduce
My
Dockerfile:docker buildx build --platform linux/amd64 --platform linux/arm64 --tag lculibrk/dupcaller --push ./The linux/arm64 build works just fine, however the linux/amd64 fails. The apt-get stdout is pretty verbose but the relevant bit is below:
Some other logs, then finally:
Expected behavior
The build should probably not error here, especially since rerunning the command sometimes does build the container successfully and sometimes does not.
docker version
docker info
Diagnostics ID
10E48443-2E93-4CA4-B95F-BD8B7126CFF9/20240416135437
Additional Info
No response