Build fails with sh: 1: cargo: not found
#260
Comments
|
I am also encountering this issue. Using NixOS 19.03 on 4.19.24 |
|
I checked the image and I didn't find the installation of |
|
I am encountering the same problem. I have just tried running like @evanjs I am also running on NixOS ( |
|
I'm also hit by On Linux, NixOS 19.03 |
|
Same problem here. It appears to be limited to executing |
|
The problem is that the image uses the host's own Rust install, which in some cases (e.g. NixOS) cannot be run on Ubuntu. You can work around it by building an image with its own Rust install, for example: FROM japaric/x86_64-unknown-freebsd:v0.1.4
RUN apt-get update && apt-get install -y wget
RUN mkdir -m777 /opt/rust /opt/cargo
ENV RUSTUP_HOME=/opt/rust CARGO_HOME=/opt/cargo PATH=/opt/cargo/bin:$PATH
RUN wget --https-only --secure-protocol=TLSv1_2 -O- https://sh.rustup.rs | sh /dev/stdin -y
RUN rustup target add x86_64-unknown-freebsd
RUN printf '#!/bin/sh\nexport CARGO_HOME=/opt/cargo\nexec /bin/sh "$@"\n' >/usr/local/bin/sh
RUN chmod +x /usr/local/bin/shRust is installed outside |
|
Using something from the host breakes many of the otherwise strong guarantees alike "runs fine with me, will run fine with you" docker has to offer. IMO this should be at least considered to be changed. |
|
Have you tried installing |
|
I had still to make some workaround for using This probably does not apply for nixOS users. But for the OP surely :) |
|
Same issue was found on circle-ci build: https://circleci.com/gh/shadowsocks/shadowsocks-rust/5 Could that be fixed by your script, too? @AluisioASG |
I tried to install cargo from master but running into the same issue. I'm using WSL. Any suggestions on how to troubleshoot further? |
|
Did run into a similar issue with development containers and Docker in Docker setup. I created a small POC (PR #387) that tries to find the corrects paths on the host machine when spinning up the child container. |
|
I can confirm this issue, it also happens on shouldn't rust be installed in those container images ? or I misunderstood the way this tool works |
|
same problem, for some reason it worked a while ago. but not now (macOS) |
|
I can confirm as well, started happening a couple of days ago. Here I'm not even using an official rustembedded docker image, but a relatively simple Alpine linux one (see rust-bio/rust-htslib#193 if you need more details to reproduce and/or context): $ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home: /home/limsadmin/.rustup
installed targets for active toolchain
--------------------------------------
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl
active toolchain
----------------
stable-x86_64-unknown-linux-gnu (default)
rustc 1.42.0 (b8cedc004 2020-03-09)
$ cat Cross.toml
[target.x86_64-unknown-linux-musl]
image = "brainstorm/rust-htslib-musl-alpine:latest"
$ cat docker/Dockerfile.alpine
FROM alpine:edge
RUN apk add --update wget git g++ build-base automake autoconf openssl openssl-dev curl-dev bzip2-dev xz-dev zlib-dev rustup && \
rm -rf /var/cache/apk/*
WORKDIR /root
RUN rustup-init -y
ENV PATH "/root/.cargo/bin:$PATH"
RUN rustup target add x86_64-unknown-linux-musl
$ cross build --target x86_64-unknown-linux-musl
sh: cargo: not found |
|
@reitermarkus Tagging you, as there seems to be official status on this, I hope you can provide more info. Why is this issue still unfixed? @AluisioASG solution is a workaround that works, but it is rather inconvenient. How does Would it be possible to have a |
|
I am hitting this issue as well, running on MacOS 10.15 and docker-in-dockering it. If I change cross to the master branch, it fails out with "Could not find directory of OpenSSL installation," but openssl-dev is installed. |
|
I have the same problem running on |
ghost
mentioned this issue
|
I also ran into the problem on nixOS while trying to cross compile for |
|
For those running An example of doing this interactively using the official |
|
While working on this pull request (#467), I started encountering this message. I had just recently changed the path configuration for P.S. I'll also add I had two versions of Rust installed. One via |
|
I am having trouble to get cross to work with circleci. And I get error that Maybe there is some obvious error in this docker command? |
|
@andresv |
|
defining variable CROSS_DOCKER_IN_DOCKER=true inside of container helped me |
|
It appears to be added in this commit f2c70b3 (present in v0.2.1) Does it mean this ticket could be closed ? |
|
@ndusart No. I've had this issue without running docker in docker, so fixing docker in docker does not solve the entirety of this issue. |
|
this solution worked FROM ghcr.io/cross-rs/arm-unknown-linux-gnueabihf:main
RUN apt-get update && apt-get install -y wget
RUN mkdir -m777 /opt/rust /opt/cargo
ENV RUSTUP_HOME=/opt/rust CARGO_HOME=/opt/cargo PATH=/opt/cargo/bin:$PATH
RUN wget --https-only --secure-protocol=TLSv1_2 -O- https://sh.rustup.rs | sh /dev/stdin -y
RUN rustup target add arm-unknown-linux-gnueabihf
RUN printf '#!/bin/sh\nexport CARGO_HOME=/opt/cargo\nexec /bin/sh "$@"\n' >/usr/local/bin/sh
RUN chmod +x /usr/local/bin/sh |
|
@IllustratedMan-code good that it worked for you, but that solution is not how cross is supposed to work (as I alluded to here and mentioned here), cross is supposed to mount your system sysroot for x86_64-unknown-linux-gnu into For nix specifically, the issue should have been fixed with #524 We have to continue and look into this, but its hard when we're not able to reproduce the issue |
|
I have the same issue in WSL2 (Ubuntu 20.04) running in Windows 11. Running Docker via Rancher Desktop in Windows and confirmed DinD works with Reproducing it like this: Start build container that includes Docker docker run --rm -it --entrypoint bash \
-e CROSS_DOCKER_IN_DOCKER=true \
-v /var/run/docker.sock:/var/run/docker.sock \
gcr.io/cloud-builders/dockerInstall Rust and apt update && apt install build-essential -y
curl https://sh.rustup.rs -sSf | sh -s -- -y --default-toolchain stable
source $HOME/.cargo/env
cargo install cross
cargo init hello-world && cd hello-worldTry to build with cross cross build
info: downloading component 'rust-src'
info: installing component 'rust-src'
sh: 1: cargo: not foundEDIT: The exact same steps works on Windows 11 and Manjaro 21.2.6 with Linux 5.17. |
The docker images use the host |
|
@Emilgardis I just took a look at #524 . It seems to rely on a |
|
Aha, that was not my understanding |
|
Running cross with the |
|
Some more context to the WSL issue without really having a solution. I had a look at the code for when However, when running Rancher Desktop (and I think Docker Desktop as well?) in combination with WSL, it sets up two different distros to host Docker: $ wsl --list -v
NAME STATE VERSION
* Ubuntu Running 2
rancher-desktop Running 2
rancher-desktop-data Running 2The container data volume does not exist in I usually don't use Windows or WSL so I need to read up more on how volume mounts + Windows + WSL + Docker in Docker works but right now it looks as simple as that the This feels like a very WSL specific issue so let me know if you want me to open a new issue to track this. |
Yes please do! |
No, although we will be shipping an image with I believe the only issue left is running cross in Rancher Desktop and WSL2. We've fixed:
|
Yeah, the images do not come with cross-installed, you are supposed to use the host tooolchain and you are trying to use The actual mount point seems to be |
|
The remaining issues for |
|
Just created a pull request that should fix the NIX_STORE problem. |
989: added default nix_store value r=Alexhuszagh,otavio a=IllustratedMan-code This pull request fixes the nix related issues described in #260. Its super simple, I just made the nix_store match statement default to `/nix/store` if the NIX_STORE variable is not set. There might be some edge cases where this won't fix the problem, but should be fine for any normal NixOS installation. Co-authored-by: lew2mz <david.lewis@cchmc.org>
|
I'm seeing these issue on mac. |
|
@bnheise please open a new issue for your issue. For us to best help you/identify the problem, include the output of the |
|
Hi @Emilgardis Thanks for the direction. The issue is no longer occurring for me. I'm not sure why yet though. |
|
I have an idea why this is happening on Docker in Docker runs. If If you run the container above and drop into a shell, you can examine the paths available in I don't have a solution to this yet. It should be possible to bind mount |
|
cross reuses the hosts rust tools so that you can specify what rust version to run, and so that we don't have to follow the 6 week releases of rust. For docker in docker, are you using the correct env vars as mentioned in the readme ( |
|
Hmm. I think it creates a dependency that might be more easily folded into a single container or deriving from rust:latest. For people running CI servers, it means having to install Rust on the server directly or fiddling with this Docker in Docker situation. I purposefully don't install Rust in the outermost host system I use for development. And I'm not sure how many corporate users are aiming for anything newer than the stable release anyways, it's usually the opposite 😼. I am indeed using |
|
If you experience this, please see the other issues mentioned in the first comment, open a new issue or reach out on our matrix chat! Thank you! |
and others
Maintainer's Note: This has become a meta-issue of multiple bugs all causing the host toolchain to not be mounted in the container, and includes:
crossin Docker in Docker in WSL #728)sh: 1: cargo: not found#496)The build fails on a Docker container with
sh: 1: cargo: not found, the Docker container is run with a custom image that contains Docker with a wrapper to have DinD working, and Rust nightlydocker run -it -vpwd:/var/tmp -v /var/run/docker.sock:/var/run/docker.sock kariae/docker-rust-nightly shthe command fails withsh: 1: cargo: not foundThe text was updated successfully, but these errors were encountered: