rustup: `rustup-init.sh` fails to detect platform correctly under `docker buildx` which lacks `/proc`

rustup-init.sh installs the incorrect rustc and other binaries because of a failure to detect arch. Problems: /proc/self/exe does not exist during docker build, so i686/386 etc is detected incorrectly as x86_64 due to failure on line 153. mips64 likely suffers the same issue because it also uses get_bitness

grep '^Features' /proc/cpuinfo | grep -q -v neon fails and ARMv6 is incorrectly detected as arm7 on line 367 Running the downloaded binary fails with /lib/ld-linux-armhf.so.3: No such file or directory (because it isnt armhf, it is armel at /lib/ld-linux.so.3 )

Logs and example code to produce the container and error: https://gist.github.com/miigotu/2a0b80677420d806c96d8e792ae6652e

Note: gcc inside the container reports the correct info, kernel reports x86_64

root@386c88edfbc5:/# uname -m
x86_64
root@386c88edfbc5:/# gcc -dumpmachine | sed "s/-/-$(uname -p)-/"
i686-unknown-linux-gnu

and

root@dac44b74e4c0:/# uname -m
armv7l
root@dac44b74e4c0:/# gcc -dumpmachine | sed "s/-/-$(uname -p)-/"
arm-unknown-linux-gnueabi

About this issue

Original URL
State: open
Created 3 years ago
Comments: 18 (5 by maintainers)

Commits related to this issue

ci: try working around rust-lang/rustup#2700 — committed to ctron/trunk-container by ctron a year ago

Most upvoted comments

This is my temporary solution that works (building python cryptography):

# rust installer needs patched to get the correct binaries for ARMv6 and i686
RUN sed -i -e's/ main/ main contrib non-free/gm' /etc/apt/sources.list
RUN apt-get update -q && \
 apt-get install -yq build-essential curl git libssl-dev libffi-dev libxml2 libxml2-dev libxslt1.1 libxslt-dev libz-dev mediainfo python3-dev unrar nano && \
 pip install -U pip wheel && \
 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > rustup-init.sh && \
 sed -i 's#/proc/self/exe#$(which head)#g' rustup-init.sh && \
 sed -i 's#/proc/cpuinfo#/proc/cpuinfo 2> /dev/null || echo ''#g' rustup-init.sh && \
 sed -i 's#get_architecture || return 1#RETVAL=$(gcc -dumpmachine | sed "s/-/-unknown-/") #g' rustup-init.sh && \
 sh -x rustup-init.sh -y --default-host=$(gcc -dumpmachine | sed 's/-/-unknown-/') && \
 rm rustup-init.sh && \
 PATH=$PATH:$HOME/.cargo/bin pip install --no-cache-dir --no-input -Ur requirements.txt && \
 PATH=$PATH:$HOME/.cargo/bin rustup self uninstall -y && \
 apt-get purge -yq --autoremove build-essential libssl-dev libffi-dev libxml2-dev libxslt-dev libz-dev python3-dev && \
 apt-get clean -yq && rm -rf /var/lib/apt/lists/*

miigotu on Mar 26, 2021

I am getting this on macOS Monterey:

vscode ➜ ~ $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
/usr/bin/head: error reading '/proc/self/exe': Bad file descriptor
/usr/bin/head: failed to close '/proc/self/exe': Bad file descriptor
rustup: unknown platform bitness
/bin/sh: 358: [: Illegal number: 
info: downloading installer

I am inside of a container built on: FROM --platform=linux/amd64 mcr.microsoft.com/vscode/devcontainers/cpp:0-debian-11. I am running linux/amd64 under Docker’s built-in QEMU emulation. The container build process is fairly involved, so it definitely functions in general. I also can run other x86_64 applications in general in the container.

Cargo does install correctly though, so it doesn’t hurt anything. Originally I thought this was a problem, but it still installs as expected. I figured this was still worth reporting here as another example of this occurring.

vadixidav on Dec 4, 2021

@miigotu I actually managed to get it running! I tried your command from the previous comment, but it seems that the SHELL env var was undeclared, so I just replaced it with “/bin/sh” and voilà!

RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sed 's#/proc/self/exe#\/bin\/sh#g' | sh -s -- -y

For transparency: I was running the build through compose, with the following adjustments:

Command COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build
Dockerfile has FROM --platform=linux/amd64 ubuntu:20.04 at the beginning
docker-compose has platform: linux/amd64 on the container (probably superfluous)

kerberjg on Dec 29, 2022

In my case it turned out that a podman system reset (deletes all containers, images, etc.) did the trick; possibly the container was bugged and a new version fixed the problem.

cschwan on Apr 28, 2024

Maybe I am misreading, but I can’t quite tell: What CPU architecture is the host? AArch64? AMD64? PowerPC?

aarch64-apple-darwin

vadixidav on Dec 4, 2021