dotnet restore fails in Arm-based container on an x64 host machine #12227
Comments
|
See the original issue at dotnet/sdk#28971 for more details. |
|
Issue is missing Type label, remember to add a Type label |
|
@benvillalobos @rainersigwald |
donnie-msft
added
Type:Bug
Platform:Docker
|
@mthalman to help me be able to repro and investigate, could you please send the docker file and the project that you show above? Thanks! |
donnie-msft
added
the
WaitingForCustomer
|
That's not my project. It's from @zimbres that originally logged this that I copied it from. I'm posting my repro project. I don't get the same exception stack as the OP but I get a crash. To repro, just run |
ghost
added
WaitingForClientTeam
|
Hello, no need specific code do reproduce, in my case, from VS17.4, creating a Worker Service for .NET7.0 with Docker support and try to build with:
Docker file is the one auto generated by VS template: |
|
Same problem happening in Github Actions when we use QEMU to build ARM64 images. |
|
@donnie-msft I have not, I'm attempting to repro now using @mthalman 's repro and I do see the NRE related to regex's. In fact, repro'ing the scenario two comments up shows the same regex NRE. @zimbres what's the dockerfile associated with seeing |
donnie-msft
added
WaitingForCustomer
|
Dockerfile is the one provided by VS template like this: |
|
Interesting, I don't see the intrinsic function failing so there's no call stack to gather there. If I can get a reliable repro for that, I'm happy to drop in custom bits to log extra details about what's going wrong with My repro: cmd: my slightly modified Dockerfile: FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY ["webapi/webapi.csproj", "src/webapi/"]
RUN dotnet restore "src/webapi/webapi.csproj"
COPY . .
WORKDIR "/src/src/webapi"
RUN dotnet build "webapi.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "webapi.csproj" -c Release -o /app/publish /p:UseAppHost=false
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "webapi.dll"]My fail stack: |
What am I missing here? I'm trying to repro your issue on my local. |
|
You need to be on .sln folder:
docker buildx build --platform linux/arm64 -t zimbres/espupdater -f MyApp\Dockerfile --push . --no-cache |
I can repro it. I'll try to diagnose root cause later this week. |
|
@zimbres |
|
Problem persist: Dockerfile: |
Retracting this... it does work as intended. When replacing the image, I removed the |
|
--platform=$BUILDPLATFORM |
|
same problem, I'm not sure which issue is getting tracked actively. you can check the debug here: I don't want to use 8.0-preview or nightly for production. thank you for your understanding |
|
Can't build any ARM images. Either it eats all 32 GiB of RAM and crashes, or gives errors like this: Simple reproducer from scratch:
Environment
|
|
@ptupitsyn as posted previously in this issue, the .NET 7 SDK does not work in qemu. You need to use the .NET 8 SDK. |
|
@zivkan the latest SDK does work in qemu (arm). This is how we do it. |
|
@turowicz the official .NET 7 release notes have a qemu heading, which explicitly states that it's not supported: https://github.com/dotnet/core/blob/main/release-notes/7.0/supported-os.md#qemu I don't know how to reconcile you saying it works, compared to @ptupitsyn's logs showing the same error as before (and the SDK version is the one released yesterday), and the release notes saying qemu is not supported (although .NET 8's release notes also says qemu is not supported). Are there any active issues in dotnet/runtime regarding this issue? The link posted last week was also closed last week as being an unsupported qemu issue. NuGet runs on the runtime, so when the runtime doesn't work, I don't know what NuGet can change to resolve the issue. Of all the stack traces I've seen reported, NuGet has never even been on the call stack. This issue is still useful to find links to other issues, but additional reports of it not working isn't providing the NuGet team with anything actionable. I hope that people from the runtime team are watching this issue and getting notifications about new comments, but issues in dotnet/runtime (and also to qemu directly) are closer to the teams who can actually fix the problem. |
|
@zivkan and yet I run docker builds on a x86 computer for multiarch platforms (amd64/arm64) and it all works fine since version of the sdk 7.0.304. It has been stated even in this thread that once the new 7 SDK comes out that workflow will be supported. I have posted here on 19th of May that the new SDK is out in confirmation that it started to work. I then changed my dockerfiles to use 7.0-dev instead of 8.0-preview. |
Two things are true: .NET doesn't support QEMU and you can get this workflow to work with 7.0.304. The reason this workflow can work is because the pattern described in https://devblogs.microsoft.com/dotnet/improving-multiplatform-container-support offers build-time improvements that allow you to run the SDK in the native architecture (no emulation) to produce an application intended for another architecture. But the application container cannot be run on the host system because it would require emulation. |
|
yes correct. actually they answered already on the issue I've linked. so for me this can stay closed |
@zivkan same problem on .NET 8: Reproducer here: https://gist.github.com/ptupitsyn/d9d7930c4f0d1840919ced5367bffc5e |
|
@ptupitsyn Have you taken a close look at the blog post linked above? I only glanced over it, but I don't see anything obviously different between what it suggests and your repro. @mthalman @turowicz are either of you able to help? The exception stack posted is exactly the same as the stack when hitting the qemu bug. It's also before any of NuGet's assemblies are on the call stack, so the NuGet team isn't in a position to fix the issue. Personally, I'm more interested in the out of memory scenario, since that's something I make changes to improve, but I need a memory dump. Does anyone know how we can get a crash dump out of a docker image? @ptupitsyn by any chance, if you restore on a host machine (so, not in docker), does it also use 30+ GB of RAM? That will make it easier to get a memory dump |
|
My process is as follows, I build several docker images on my CI and deliver the last one to the deployment host. The CI agents are x86 with QEMU enabled. ALL STEPS BELOW take 1) Build SDK (for engineers to work with "VS Code Remote Containers" and for the initial CI Build) 2) Build Runtime (for the CI to put the packaged dotnet apps on to so they can be deployed to hosts) 3) Build & test my application 4) Package a shippable container (using images from 2. and 3.) 5) Result images from step 4. work on AMD64, ARM64 and L4T (Jetson) NOTICE In step 3. I am enforcing amd64 platform ( |
|
@zivkan the blog post helped! Thank you, I should have paid more attention. The difference is in |
|
We created a totally new .net webapplication and it does not work.
This is the error we get, any help will be appreciated.
|
|
@stealthAngel the error message is about running some container, not You'll have more luck getting support at https://github.com/dotnet/dotnet-docker |
|
Has anyone solved the issue? why this issue has been closed? runs from Mac M2, which arm64 and I need to push both arm64 and amd64 images to my docker hub. |
|
I've stiched up a solution from numerous answers. Below is my setup, which works on Mac M1 And I run the build like so: Hope this helps! |
and others
Copied from post by @zimbres at dotnet/sdk#28971:
When try to build arm64 containers using .Net7 results in a error on restore step.
Just create a new web api for example with .Net7 as target framework and try to build it with buildx. For amd64 build works just fine.
Docker Version
Docker Info
The text was updated successfully, but these errors were encountered: