Segmentation fault building project on dotnet/sdk:7.0 image with Apple M1 #4225
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
This can be verified by including the following instruction to be executed within the SDK container: RUN dotnet --infoThat will indicate the architecture in the output. If it's not getting the Arm64 image, that's related to Docker and not the > docker manifest inspect mcr.microsoft.com/dotnet/sdk:7.0
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 2009,
"digest": "sha256:77f18f87a309d53015601a388f0108e8e0742b98cade2ba5276605799e662b09",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 2009,
"digest": "sha256:a47ea685326c54067b7819d00bf0cb03e98e56c202bbbab22a4bb249cb2977d5",
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v7"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 2008,
"digest": "sha256:37062ef2dc44d9e3f4d82632c28702833d7578ae9da4cf40ff52a080e844bd48",
"platform": {
"architecture": "arm64",
"os": "linux",
"variant": "v8"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 3854,
"digest": "sha256:03f882c3dbb4ac697ff9fe4191d4892144318836986bf95f5b7dc67813b8861d",
"platform": {
"architecture": "amd64",
"os": "windows",
"os.version": "10.0.17763.3650"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 3855,
"digest": "sha256:4cff7618d17797f0e9bfe534890564a98326c98260f434a953ff340c5f8eb5d1",
"platform": {
"architecture": "amd64",
"os": "windows",
"os.version": "10.0.20348.1249"
}
}
]
}Is your M1 machine running Docker Desktop for Apple Silicon as opposed to Intel via emulation? See https://docs.docker.com/desktop/install/mac-install/. Note that you can explicitly configure which architecture is targeted when you pull an image as well by using |
|
HI! I have the same problem. My Settings Build Publish |
|
Hi @mthalman, Thanks for getting back to me, I get what you are saying although working with the 6.0 SDK image I didn't need to do configure docker to explicity only pull down the Arm64 variants of the image that is registered in the manifest where it would appear it resolves the correct one automatically although I'll need to prove this by what you suggest with getting what the dotnet --info outputs. I'll get back to you, thanks for your help. |
|
Also re-installed docker targeting Apple Silicon just to be on the safe side in case I mistakenly installed the intel based one just so you know. |
|
I use |
|
@PeterHagen - Can you include |
|
This writeup may help: #3848 |
Here you go: |
|
@PeterHagen - What gets output when you execute this command: |
|
I found my problem, using strace. I had included in my Dockerfile the Datadog APM Agent for alpine because my dotnet base image was alpine for ARM64, I changed it to the debian image and changed the Datadot APM Agent as well. It worked correctly. I'm using buildx to generate the image build. |
here you go: |
@PeterHagen - And what happens when you run this? |
This looks OK to me, but the issue happens when I use |
@PeterHagen - Oh, I didn't realize that. Then yes, there's a regression there. I believe it is NuGet/Home#12227. It's just the reverse architectures of what is described there. That issue describes arm64 container on a x64 host. But your scenario is x64 container on an arm64 host. In both cases, QEMU emulation is being used with different symptoms, but the underlying issue is identified by NuGet/Home#12227. Please follow up there. My original assumption was that you were having the same symptoms as @jon-mca which is somehow getting the incorrect architecture of the .NET SDK image. In the case of @jon-mca, it's getting a x64 container when an arm64 container is expected. That then leads to the regression of NuGet/Home#12227. But that regression can be avoided if you avoid emulation altogether and use an arm64 container on an arm64 host. @jon-mca - Do you have any update to give regarding your issue. Did the reinstall of Docker Desktop help? If not, can you follow up with results of the output from what I posted at #4225 (comment) and #4225 (comment). |
|
I'm also experiencing this issue on Mac M1 but I found a workaround. Using an arm64 image for building/publishing but using an amd64 image for the ASP runtime seems to work well. |
|
Apologies @mthalman, been swamped with work. I did re-install docker desktop and made sure it was tailored for Apple silicon as noted here: Here is a dump of the docker version and info related stuff as asked when submitting a ticket: Docker Info Running the commands suggested to get the relevant info from dotnet: I did re-try an existing project that was experiencing the segmentation fault using the basline 7.0 SDK image and failed (redacted with MyProject): @mthalman let me know if you need more info. |
|
@jon-mca - What's the |
|
@mthalman I'm using the build command like this: |
Ok. So I was confused because of this from your original post:
Based on that, I was thinking you were explicitly wanting the Arm64 version of the image. But by passing Can I ask why you're explicitly setting the platform of the docker build to Based on this, I'm going to close this issue because NuGet/Home#12227 is the underlying issue to be followed up on if you require the use of emulation. |
I use this to build a container to push to a x64 linux server, not to run it on the M1 machine. Without the platform instruction, it won't run on that server. Doing the same thing on an Intel Mac, it does work, so this is my fallback for now. |
If you have an explicit architecture that you're targeting, you can use that architecture in the tag of the runtime/aspnet image. For example, this sample Dockerfile uses a multi-arch tag for the SDK image but an architecture-specific tag for the runtime image. Here's a snippet showing the relevant pieces: FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
RUN dotnet publish -c Release -o /app -r linux-x64 --self-contained false --no-restore
FROM mcr.microsoft.com/dotnet/runtime:7.0-bullseye-slim-amd64If you build that on an M1 machine without specifying the |
|
Apologies @mthalman, I was responding after working a long day yesterday and neglected to give context. Probably too late now being the issue is closed but I'll eleborate nonetheless, for local development we have our of own instance an environment in Azure running applications using linux/x64 Container Apps but we use our M1 macs to build and push images to that environment rather than using a CI/CD process. The docker build steps are this for SDK 6.0:
For SDK 7.0, I'm having to explicity set to use the arm64 image for the publish step which we didn't need to when using SDK 6.0:
We can't change --platform to use arm64 as the destination, in Azure, is configured for x64. Fair enough if this ticket will remain closed and again I apologise for the confusion my previous response caused. Kind regards |
|
@jon-mca - See my recommendation here: #4225 (comment). That's the preferred pattern to follow because it has true multi-arch support. The same Dockerfile will be able to be built from an x64 or Arm64 machine without any use of the |
I got it to work, by using the Thanks for the info! |
If you do it that way do you end up with a linux/amd64 image? |
|
@PeterHagen can you please share your docker file? Appreciate the help. |
|
Sure. This is how I use it now: FROM mcr.microsoft.com/dotnet/sdk:7.0 AS BUILD-WEB-APP
ENV DEBIAN_FRONTEND noninteractive
ENV TZ=Europe/Amsterdam
ENV DOTNET_CLI_TELEMETRY_OPTOUT=1
WORKDIR /app
COPY NuGet.config /app/
COPY id_rsa /app/
COPY build-settings /app/
COPY build-setup /app/
RUN echo "Setup" && \
chmod +x /app/build-setup && \
/app/build-setup
# copy these files late to keep cache
COPY default-functions /app/
COPY build-dotnet /app/
COPY build-commithash /app/
RUN echo "Start build" && \
chmod +x /app/build-dotnet && \
/app/build-dotnet
# Create image
FROM mcr.microsoft.com/dotnet/aspnet:7.0-bullseye-slim-amd64
WORKDIR /app
ENV DEBIAN_FRONTEND noninteractive
ENV DOTNET_CLI_TELEMETRY_OPTOUT=1
ENV TZ=Europe/Amsterdam
ENV ASPNETCORE_URLS=http://+:5000
ENV ASPNETCORE_ENVIRONMENT="Production"
ENV CMS_PRIVATE_STORAGE=/opt/data/private
ENV CMS_PUBLIC_CACHE=/opt/data/cache
COPY appsettings.production.json /app/appsettings.json
COPY --from=BUILD-WEB-APP /opt/data/bin /app
EXPOSE 5000
ENTRYPOINT ["dotnet", "My.app.dll"]I build it like this, without specifying the platform. If I do use |
|
Thank you @PeterHagen . This is great. |
|
using this image in dotnet run time docker image and |
|
I was having this issue as well. It was solved by downgrading to dotnet sdk 6.0. |
|
I have to say that I am not very impressed when seeing that you guys just closed this issue. Leaving a potential segfault "in the wild" like this should not happen. |
|
@Peder2911 - The segfault is caused by .NET's interaction with QEMU which is not a supported configuration (see dotnet/core#8163). Please read through this blog post which provides the details on getting this to correctly work without using QEMU: https://devblogs.microsoft.com/dotnet/improving-multiplatform-container-support/ |
|
Hey! Sorry for my rash comment, I was really frustrated with this after many long hours yesterday. Thank you for your work on this! |
Worked for me ! |
Describe the Bug
Running into a problem where creating a docker image from mcr.microsoft.com/dotnet/sdk:7.0 on an M1 Apple MacBook Pro throws a segmentation fault from package qemu during publish.
The docker file looks like this, which worked previously with the .NET Core 6 SDK image (changed to point to 7.0 images):
My suspicion is that the SDK 7.0 base image that is being pulled from docker is not the ARM64 tagged variant, .i.e. Linux Arm64, and what is being used is not compatiable with the the M1.
Steps to Reproduce
Run dockerfile on an M1 equipped Apple Mac computer.
Other Information
A workaround for this issue is to explicity set the SDK base image to use the Linux Arm64 (7.0-bullseye-slim-arm64v8) tagged SDK image:
...or a better workaround example is to provide the tag to use via --build-arg and pass "7.0-bullseye-slim-arm64v8" as a value otherwise it'll default to "7.0":
Output of
docker versionOutput of
docker infoThe text was updated successfully, but these errors were encountered: