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

error: rustup is not installed at '/home/user/.cargo' when $RUSTUP_HOME is set to something other than the former #2886

Closed
bbros-dev opened this issue Oct 30, 2021 · 15 comments · Fixed by #3907

Comments

@bbros-dev
Copy link

bbros-dev commented Oct 30, 2021

Problem

  1. Rustup cannot update when CARGO_HOME is not the Linux default ~/.cargo
  2. Then rustup self uninstall fails to work
  3. At https://www.rust-lang.org/tools/install, there are no further instructions, or a link to those instructions, on how to uninstall rustup.

Steps

20:02 $ echo $RUSTUP_HOME
/home/<snip>/.rustup
✔ ~/src/<snip> [port ↑·2|✚ 2…1]
20:02 $ echo $CARGO_HOME
/home/<snip>/.local/share/cargo
^[[A✔ ~/src/<snip> [port ↑·2|✚ 2…1]
20:02 $ which rustup
/home/<snip>/.local/share/cargo/bin/rustup
✔ ~/src/<snip> [port ↑·2|✚ 2…1]
20:02 $ rustup self update
error: rustup is not installed at '/home/<snip>/.cargo'

Possible Solution(s)
No idea. We seem to be in a Mexican-standoff.

Notes

Output of rustup --version:

$ rustup --version
rustup 1.23.1 (3df2264a9 2020-11-30)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.56.0-nightly (5ad7389bd 2021-08-06)`

Output of rustup show:

20:14 $ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/<snip>/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.56.0-nightly (5ad7389bd 2021-08-06)
@bbros-dev bbros-dev added the bug label Oct 30, 2021
@kinnison
Copy link
Contributor

kinnison commented Nov 8, 2021

Our test suite sets those variables in order to operate, so I'm not sure how this could be happening to you. Can you confirm that CARGO_HOME is definitely exported to subshells? Also how did you install rustup? Did you install in those specific dirs, or did you move the installation later?

@rbtcollins
Copy link
Contributor

A month with no response - @bbros-dev please reply or we'll need to close this with insufficient information

@kennystrawnmusic
Copy link

kennystrawnmusic commented Dec 28, 2021

This happens on my end too — but only if run from a script. Works perfectly fine if run from the shell of any user — and this is if I put export RUSTUP_HOME=/opt/rust and export CARGO_HOME=/opt/rust in the system-wide /etc/bash.bashrc file.

Again, perfectly fine if run from a shell, but if I write something like /usr/bin/rustup-upgrade.sh and add the rustup self update and/or rustup update commands to said script, that’s when this problem is run into — and in that case, even adding source /etc/bash.bashrc to the top of the script in order to ensure that the imports defined in that file also make it into the script makes no difference. This problem likewise also occurs when I try to create something like /lib/systemd/system/rustup-update.timer to automatically run the rustup self update and/or rustup update commands in the background.

Re: @bbros-dev — it would help to add “when $RUSTUP_HOME is set to something other than the former” to the end of this bug report’s title to make this report more clear.

@rbtcollins — might want to remove the “inactive” label per this reproduction.

@bbros-dev
Copy link
Author

Thanks for taking the time to look at this.
@rbtcollins apologies for the delay - RL.

The following is a complete log of a new shell - @kinnison full setup details follow. You'll note that ~/.rustup does not exist, as expected, but then is created by rustup show, despite RUSTUP_HOME pointing to an existing location.
I expected rustup show to never create or delete anything on the system?
Not sure if this is related or a separate issue?

~$ ls ~/.rustup
ls: cannot access '/home/<user>/.rustup': No such file or directory

~$ echo $RUSTUP_HOME 
/home/<user>/.local/share/rustup

~$ echo $CARGO_HOME 
/home/<user>/.local/share/cargo

~$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/<user>/.rustup

no active toolchain

~$ ls ~/.rustup
settings.toml

~$ RUSTUP_HOME=$RUSTUP_HOME rustup show
Default host: x86_64-unknown-linux-musl
rustup home:  /home/<user>/.local/share/rustup

stable-x86_64-unknown-linux-musl (default)
(error reading rustc version)

~$ ls ~/.local/share/rustup
downloads  settings.toml  tmp  toolchains  update-hashes

Can you confirm that CARGO_HOME is definitely exported to subshells?

Yes, I believe so - see the above details from new bash shell. Setup details follow.

Also how did you install rustup? Did you install in those specific dirs, or did you move the installation later?

Setup is using Chef recipes:

  1. ~/.bashrc
#!/usr/bin/env bash

[ -f /etc/skel/.bashrc ] && source /etc/skel/.bashrc

for file in ~/.config/bash/bashrc.d/*.bashrc
do
  test -f "$file" || continue
  test -x "$file" || continue
  # shellcheck source=/dev/null
  source "$file"
done
  1. ~/.config/bash/bashrc.d/30-rustup.bashrc
CARGO_HOME=${XDG_DATA_HOME}/cargo
RUSTUP_HOME=${XDG_DATA_HOME}/rustup
PATH="${CARGO_HOME}/bin:${RUSTUP_HOME}/bin:$PATH"
  1. Rustup is installed by the following recipe:
# frozen_string_literal: true

pkgs = %w[
  musl-dev
  musl-tools
  musl
]

pkgs.each do |pkg|
  package pkg do
    action :install
  end
end

node['developer']['users'].each do |usr|
  bash "Create #{usr} Rust install" do
    code <<-EOCODE
    curl https://sh.rustup.rs -sSf | \
      sh -s -- \
            -y \
            --verbose \
            --default-host x86_64-unknown-linux-musl \
            --default-toolchain stable \
            --profile default \
            --no-modify-path
    EOCODE
    creates "/home/#{usr}/.local/share/rustup"
    environment ({ 'CARGO_HOME': "/home/#{usr}/.local/share/cargo",
                   'DISPLAY': ':0',
                   'HOME': "/home/#{usr}",
                   'RUSTUP_HOME': "/home/#{usr}/.local/share/rustup",
                   'USER': usr })
    user        usr
    not_if %([ -d "/home/#{usr}/.local/share/rustup" ])
  end

  link "/home/#{usr}/.local/bin/rustup" do
    to "/home/#{usr}/.local/share/cargo/bin/rustup"
  end

  execute "/home/#{usr}/.local/bin/rustup update --no-self-update stable" do
    environment ({ 'DISPLAY': ':0',
                   'HOME': "/home/#{usr}",
                   'USER': usr,
                   'CARGO_HOME': "/home/#{usr}/.local/share/cargo",
                   'RUSTUP_HOME': "/home/#{usr}/.local/share/rustup" })
    user        usr
  end

  ## Install components
  #
  %w[
    clippy
    rustfmt
    rust-src
  ].each do |c|
    execute "/home/#{usr}/.local/bin/rustup component add #{c}" do
      environment ({ 'DISPLAY': ':0',
                     'HOME': "/home/#{usr}",
                     'USER': usr,
                     'CARGO_HOME': "/home/#{usr}/.local/share/cargo",
                     'RUSTUP_HOME': "/home/#{usr}/.local/share/rustup" })
      user        usr
    end
  end
end

@bbros-dev bbros-dev changed the title error: rustup is not installed at '/home/hedge/.cargo' error: rustup is not installed at '/home/user/.cargo' Jan 26, 2022
@kennystrawnmusic
Copy link

kennystrawnmusic commented Jan 27, 2022

To further corroborate what @bbros-dev is saying, here's the full text of /etc/bash.bashrc on my end:

#
# /etc/bash.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

[[ $DISPLAY ]] && shopt -s checkwinsize

PS1='[\u@\h \W]\$ '

case ${TERM} in
  xterm*|rxvt*|Eterm|aterm|kterm|gnome*)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

    ;;
  screen*)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033_%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'
    ;;
esac

[ -r /usr/share/bash-completion/bash_completion   ] && . /usr/share/bash-completion/bash_completion

if [ -f /opt/rust/env ]; then
  source /opt/rust/env
fi

export RUSTUP_HOME=/opt/rust
export CARGO_HOME=/opt/rust

alias pacman='sudo pacman --noconfirm'

When I went on to create something like "rustup-update.sh" with the following content:

#!/bin/bash
rustup self update
rustup update

It would fail with this error when I tried to run it.

This, however, seems to have begun working fine a month later on my end for some reason ― not sure why I was able to reproduce this on December 28 but not now.

@krishnachittur
Copy link

@bbros-dev I think your issue might be in the file ~/.config/bash/bashrc.d/30-rustup.bashrc:

CARGO_HOME=${XDG_DATA_HOME}/cargo
RUSTUP_HOME=${XDG_DATA_HOME}/rustup
PATH="${CARGO_HOME}/bin:${RUSTUP_HOME}/bin:$PATH"

Bash doesn't export these variables to subshells, which is resulting in your problem where rustup isn't seeing $CARGO_HOME. (I made this same mistake myself today, except in fish, by writing set -U CARGO_HOME blah instead of set -Ux CARGO_HOME blah.) To fix it, use the export keyword to tell bash to export these environment variables to subshells, like this:

export CARGO_HOME=${XDG_DATA_HOME}/cargo
export RUSTUP_HOME=${XDG_DATA_HOME}/rustup
export PATH="${CARGO_HOME}/bin:${RUSTUP_HOME}/bin:$PATH"

@bbros-dev bbros-dev changed the title error: rustup is not installed at '/home/user/.cargo' error: rustup is not installed at '/home/user/.cargo' when $RUSTUP_HOME is set to something other than the former Mar 9, 2022
@bbros-dev
Copy link
Author

@krishnachittur, thank you that does appear to have resolved the error. IIUC then the issue is as follows:

Given the folder `~/.rustup` does not exist
  And the environment variable RUSTUP_HOME is not set
 When a user runs `rustup self update`
 Then the stderr output does not contain:
"""
error: rustup is not installed at '/home/<snip>/.cargo'
"""
  And the stderr output does contain:
"""
error: rustup is not installed at '/home/<snip>/.rustup' and RUSTUP_HOME is not set.  One is required.
"""

Does that sound correct?

@krishnachittur
Copy link

@bbros-dev In other words, you think the current error message is unclear? That seems like a reasonable complaint to me. Might be an easy PR as well.

@danieleades
Copy link

i'm running into this trying to get caching to work properly in gitlab CI. A quick search shows i'm not the only one getting stumped here

default:
  image: "rust:latest"

variables:
  CARGO_HOME: ${CI_PROJECT_DIR}/.cargo # Move cargo data into the project directory so it can be cached

cache:
  key: ${CI_COMMIT_REF_SLUG} # Share cache between all jobs on one branch/tag
  paths:
    - .cargo/bin
    - .cargo/registry/index
    - .cargo/registry/cache
    - target/debug/deps
    - target/debug/build
  policy: pull-push

before_script:
  - rustup update
  - rustup install stable

# ...

rustup update fails with "error: rustup is not installed at ..."

@kinnison
Copy link
Contributor

@danieleades I suggest you try out https://gitlab.com/rust-ci/rust-ci - I know the authors of that and they're pretty helpful.

@danieleades
Copy link

@Xenira
Copy link

Xenira commented Jun 24, 2024

Also ran into this problem in my gitlab pipeline. Cause is definitely the self update.

Resolved by running rustup set auto-self-update disable before my other commands.

@djc
Copy link
Contributor

djc commented Jun 24, 2024

Reminds me we should probably disable self updates when CI is set in the environment.

@Xenira
Copy link

Xenira commented Jun 24, 2024

Relevant issue: #3824

@king-11
Copy link

king-11 commented Oct 22, 2024

@Xenira thanks for the resolution.

jackronaldi pushed a commit to lightning-signer/validating-lightning-signer that referenced this issue Oct 23, 2024
remove rustfmt download step
cargo fmt
Changelog-None: ci changes for cache handling
disable rustup auto update as it fails: rust-lang/rustup#2886 (comment)

Signed-off-by: Lakshya Singh <lakshay.singh1108@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants