Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet binary fails on Docker multiarch #47280

Closed
rickardp opened this issue Jan 21, 2021 · 7 comments
Closed

dotnet binary fails on Docker multiarch #47280

rickardp opened this issue Jan 21, 2021 · 7 comments
Milestone

Comments

@rickardp
Copy link
Contributor

rickardp commented Jan 21, 2021

When running the dotnet binary under Docker multiarch (host is aarch64):

docker run --platform linux/amd64 mcr.microsoft.com/dotnet/sdk:5.0-alpine dotnet --info   
Failed to resolve full path of the current executable [/proc/self/exe]

It appears the non-Apline version has a different problem, though I did not test it very much

docker run --platform linux/amd64 mcr.microsoft.com/dotnet/sdk:5.0 dotnet --info 
Failed to create CoreCLR, HRESULT: 0x8007FF06

Possibly it could be due to the fact that the process is wrapped by the qemu-x86_64 binary.

In this case, /proc//exe points to /usr/bin/qemu-x86_64, which does not exist on the file system (i.e. not in the Docker image)

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Jan 21, 2021
@dotnet-issue-labeler
Copy link

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.

@ghost
Copy link

ghost commented Jan 21, 2021

Tagging subscribers to this area: @vitek-karas, @agocke
See info in area-owners.md if you want to be subscribed.

Issue Details

When running the dotnet binary under Docker multiarch, it fails with the following error message

Failed to resolve full path of the current executable [/proc/self/exe]

Possibly it could be due to the fact that the process is wrapped by the qemu-x86_64 binary.

I was not able to reproduce the problem on the official images, but it can be reproduced by downloading the Alpine binaries on a clean Alpine image.

In this case, /proc//exe points to /usr/bin/qemu-x86_64, which does not exist on the file system (i.e. not in the Docker image)

Author: rickardp
Assignees: -
Labels:

area-Host, untriaged

Milestone: -

@djlawhead
Copy link

This happens to me as well, running Apple's new M1 chip. Is there a workaround?

@vitek-karas
Copy link
Member

The docker one is probably due to the qemu layer - we would need to figure out how to determine the current process path which would work (if /proc/self/exe is not the right thing - what else).

As for Apple M1 - is it the same problem as in "running in docker using qemu emulation"?, or is it that running x64/arm64 on macOS directly is currently problematic? For the latter - we're working on it - there's a design discussion here: dotnet/designs#217

@djlawhead
Copy link

I should’ve been more specific with my reply. I receive the following

Failed to create CoreCLR, HRESULT: 0x8007FF06

When running dotnet inside of an x86_64 docker image on my Apple M1 silicon. /prof/self/exe also points to /usr/bin/qemu-x86_64 which doesn’t exist in the container. So I suspect it has more to do with docker than the M1 chip.

@vitek-karas vitek-karas added this to the 7.0.0 milestone Jul 9, 2021
@vitek-karas vitek-karas removed the untriaged New issue has not been triaged by the area owner label Jul 9, 2021
@deeprobin
Copy link
Contributor

Both mentioned examples work on my system (host: x86-amd64-Windows).
I think we could label this arch-arm32 and arch-arm64?

@agocke
Copy link
Member

agocke commented Jan 14, 2025

I can't seem to repro this anymore. Closing.

@agocke agocke closed this as completed Jan 14, 2025
@github-actions github-actions bot locked and limited conversation to collaborators Feb 13, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

No branches or pull requests

6 participants