runtime: [ARM32] `qemu: Unsupported syscall: 389` when running console app in Docker

While testing the new arm32v7 Docker images for .NET Core I’m seeing qemu: Unsupported syscall: 389 written to the output whenever I run a console application in an arm Docker container on a Windows 10 machine. I don’t see this if I run the same Docker image on a physical arm32 device (e.g. raspberry pi).

Steps to reproduce

From a Windows 10 machine with Docker installed (Docker version 17.06.0-ce, build 02c1d87)
Create a new console app - dotnet new console
Add the following Dockerfile to your project

FROM microsoft/dotnet-nightly:2.0-sdk AS build-env
WORKDIR /app

# copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore

# copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out

# build runtime image
FROM msimons/dotnet-nightly:2-runtime-stretch-arm32v7
WORKDIR /app
COPY --from=build-env /app/out ./
ENTRYPOINT ["dotnet", "arm.dll"]

Note: The Dockerfile for msimons/dotnet-nightly:2-runtime-stretch-arm32v7 is contained in https://github.com/dotnet/dotnet-docker-nightly/pull/328 3. Run the following from your project dir docker build -t armapp . 4. Run the image docker run --rm armapp

Expected Output of App

Hello World!

Output of App

qemu: Unsupported syscall: 389
Hello World!

Notes

The app’s return code is 0
I tried running the image with the --privileged and --security-opt="seccomp=unconfined" options but see no difference in behavior.

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 21 (11 by maintainers)

Commits related to this issue

Remove Tizen armel automatic PR triggered jobs These are failing almost every job with "qeumu: Unsupported syscall: 389". Issue: https://github.com/dotnet/coreclr/issues/12972. — committed to BruceForstall/coreclr by BruceForstall 6 years ago

Most upvoted comments

Any news?

eshvatskyi on Jan 24, 2019

Also seeing this issue on OSX 10.13.6 using image microsoft/dotnet:2.1-sdk-stretch-arm32v7 on step RUN dotnet restore -nowarn:msb3202,nu1503 -p:RestoreUseSkipNonexistentTargets=false. It gives the following output:

Step 9/18 : RUN dotnet restore -nowarn:msb3202,nu1503 -p:RestoreUseSkipNonexistentTargets=false
 ---> Running in 4cf6b676bcf0
qemu: Unsupported syscall: 389
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

Jacobh2 on Aug 7, 2018

@jkotas So, what you are saying is to build within x86/x64 container, target linux_arm and just copy published files to correct arm based image? That should work, thanks.

MihaMarkic on Dec 5, 2019

@janvorli - I am seeing a more severe variant of this with the new ARM SDK builds.

Steps to reproduce

Using Docker on a Windows 10 machine running in Linux container mode or a macOS.
Build the following Dockerfile - docker build -t dotnet-arm-sdk .

FROM arm32v7/buildpack-deps:stretch-scm

# Install .NET CLI dependencies
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        libc6 \
        libcurl3 \
        libgcc1 \
        libgssapi-krb5-2 \
        libicu57 \
        liblttng-ust0 \
        libssl1.0.2 \
        libstdc++6 \
        libunwind8 \
        zlib1g \
    && rm -rf /var/lib/apt/lists/*

# Install .NET Core SDK
ENV DOTNET_SDK_VERSION 2.1.300-preview2-008380

RUN curl -SL --output dotnet.tar.gz https://dotnetcli.blob.core.windows.net/dotnet/Sdk/$DOTNET_SDK_VERSION/dotnet-sdk-$DOTNET_SDK_VERSION-linux-arm.tar.gz \
    && dotnet_sha512='3f8276cd982f309236d5cac6656c9364cb190d1cb1ac0474acd67e16f35b8bb5d66fcb220342f0edb80c548a073d5e7f7330ceeeebdc88bceb8ea4836cd1abc6' \
    && echo "$dotnet_sha512 dotnet.tar.gz" | sha512sum -c - \
    && mkdir -p /usr/share/dotnet \
    && tar -zxf dotnet.tar.gz -C /usr/share/dotnet \
    && rm dotnet.tar.gz \
    && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet

# Configure Kestrel web server to bind to port 80 when present
ENV ASPNETCORE_URLS=http://+:80 \
    # Enable detection of running in a container
    DOTNET_RUNNING_IN_CONTAINER=true \
    # Enable correct mode for dotnet watch (only mode supported in a container)
    DOTNET_USE_POLLING_FILE_WATCHER=true \
    # Skip extraction of XML docs - generally not useful within an image/container - helps perfomance
    NUGET_XMLDOC_MODE=skip

# Trigger first run experience by running arbitrary cmd to populate local package cache
RUN dotnet help

Results:

...
Step 10/10 : RUN dotnet help
 ---> Running in ae71e039abc8
qemu: Unsupported syscall: 389

Welcome to .NET Core!
---------------------
Learn more about .NET Core: https://aka.ms/dotnet-docs
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs

Telemetry
---------
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn't include command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
qemu: Unsupported syscall: 345

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate (Windows and macOS only) first install the dev-certs tool by running 'dotnet install tool dotnet-dev-certs -g --version 2.1.0-preview1-final' and then run 'dotnet-dev-certs https --trust'.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
The command '/bin/sh -c dotnet help' returned a non-zero code: 139

You can also reproduce this on Linux when using qemu but the setup is more complex.

MichaelSimons on Mar 27, 2018

As @okodron suggested, try upgrading to latest qemu that should have the syscall implemented.

We do not test or support .NET Core on qemu. We have tried using qemu to run tests in CI for a while, but we have found quemu to be too unstable for what .NET Core needs.

If you are using docker just for building, .NET Core 3.1 tooling supports cross-compilation that allows dotnet publish linux arm32 binaries from linux x64.

jkotas on Dec 5, 2019

Also seeing this issue for microsoft/dotnet:2.1.500-sdk-bionic-arm32v7 + microsoft/dotnet:2.1.500-sdk-stretch-arm32v7

FROM microsoft/dotnet:2.1.500-sdk-bionic-arm32v7
...
RUN dotnet restore

Error :

Step 5/21 : RUN dotnet restore
 ---> Running in 657b266d8fb2
qemu: Unsupported syscall: 389

Extra info:

Client: Docker Engine - Community
 Version:           18.09.0
 API version:       1.39
 Go version:        go1.10.4
 Git commit:        4d60db4
 Built:             Wed Nov  7 00:47:51 2018
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.0
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.4
  Git commit:       4d60db4
  Built:            Wed Nov  7 00:55:00 2018
  OS/Arch:          linux/amd64
  Experimental:     false

stephenpope on Nov 23, 2018