Docker "Run Dotnet restore" returning returned a non-zero code: 132 on Raspberry Pi when trying to build my asp.net core apps

[liukonen]

I am using the same dockerfiles from 3.1 and 5.0, except I've upgraded my projects to 6.0 and updated my dockerfile to also use 6.0
My script looks something like this.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["APP/APP.csproj", "APP/"]
RUN dotnet restore "APP/APP.csproj" # <- line breaking on
COPY . .
WORKDIR "/src/APP"
RUN dotnet build "APP.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "APP.csproj" -c Release -o /app/publish -r linux-arm

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "APP.dll"]

I've tried pointing to both the most specific Alpine and Debian-based images with no luck. Running the same script, minus the -r Linux-arm in WSL2 Ubuntu compiles and generates a new image just fine. Am I missing something with the new framework with my script?

[mthalman]

You'll need to include -r linux-arm on the dotnet restore command as well. The RID impacts which packages will be restored.

[liukonen]

Thanks for the suggestion, however it still appears to occur with "-r linux-arm" appended to the dot net restore command. Error code is "returned a non-zero code: 134

[mthalman]

It may be related to #3253. Can you try the workaround suggested at #3253 (comment)?

[liukonen]

Attempted the fix... Still no luck (yet)
Added the Testing branch to my sources.list.... attempted to set the priority of my branches, which did not work, however, installed the latest (2.5.2-2+rpi1) of libseccomp2. No luck. Since I couldn't get my sources prioritized, I didn't push forward on any updates since is my primary box, so reverted my sources.list back to main. One note is that I am only running Debian Buster on my machine. I can work this weekend on getting bullseye up and running on it. One other note is that I saw that Alpine SDK was giving me a 132 while Debian SDK was returning a 134...which is why my numbers may not be matching up above (one point I reference 132, and another 134.)

[liukonen]

After upgrading from Buster to Bullseye, my build finally worked... thank you so much @mthalman for the help with this.