Rustup: toolchain in incorrect state after failed install

Created on 18 Mar 2016  ·  6Comments  ·  Source: rust-lang/rustup

Even though the file-level rollback works correctly when installation fails, there are still directories left behind. This looks to rustup like a real installation, but it's broken.

bug

Most helpful comment

$ rustup toolchain remove nightly
$ rustup default nightly
$ rustup target add x86_64-unknown-linux-musl

"fixed" it

All 6 comments

Probably related. Today, I've arrived at an incorrect state for the x86_64-unknown-linux-musl target though I'm not sure how I got there -- I may have Ctrl-Ced a rustup target add command:

$ rustup target remove x86_64-unknown-linux-musl
error: toolchain 'nightly-x86_64-unknown-linux-gnu' does not contain component 'rust-std' for target 'x86_64-unknown-linux-musl'
info: backtrace:

stack backtrace:
   0:     0x55b4acba542d - backtrace::backtrace::trace::h36e5966500ba9bd9
   1:     0x55b4acba5b42 - backtrace::capture::Backtrace::new::h3a3d5e9defd7d407
   2:     0x55b4aca35c32 - rustup::toolchain::Toolchain::remove_component::h991d75622cd0813c
   3:     0x55b4ac9ee17e - rustup_init::rustup_mode::target_remove::h4b96f85946a50ea9
   4:     0x55b4ac9db8b1 - rustup_init::rustup_mode::main::h3d9166ae73c6fc5f
   5:     0x55b4aca0414f - rustup_init::main::habce3d2a29c7553b
   6:     0x55b4acd95277 - std::panicking::try::call::h5df3ac2979db3c90
   7:     0x55b4acd9d946 - __rust_maybe_catch_panic
   8:     0x55b4acd946e9 - std::rt::lang_start::hfe9ab243c60ffb9b
   9:     0x7f624e5db290 - __libc_start_main
  10:     0x55b4ac9c4cd4 - <unknown>

$ rustup target add x86_64-unknown-linux-musl
info: downloading component 'rust-std' for 'x86_64-unknown-linux-musl'
  8.1 MiB /   8.1 MiB (100 %) 1020.8 KiB/s ETA:   0 s
info: installing component 'rust-std' for 'x86_64-unknown-linux-musl'
info: rolling back changes
error: failed to install component: 'rust-std-x86_64-unknown-linux-musl', detected conflict: '"lib/rustlib/x86_64-unknown-linux-musl/lib/crt1.o"'
info: backtrace:

stack backtrace:
   0:     0x55b75eab542d - backtrace::backtrace::trace::h36e5966500ba9bd9
   1:     0x55b75eab5b42 - backtrace::capture::Backtrace::new::h3a3d5e9defd7d407
   2:     0x55b75e980d97 - rustup_dist::component::transaction::Transaction::copy_file::h5a0056d2ff4e41ca
   3:     0x55b75e98f4a2 - rustup_dist::component::components::ComponentBuilder::copy_file::h603553d690fa0eb0
   4:     0x55b75e987005 - _<rustup_dist..component..package..DirectoryPackage as rustup_dist..component..package..Package>::install::h62c90beb0a6562af
   5:     0x55b75e9990c5 - rustup_dist::manifestation::Manifestation::update::h693ee9e140d33154
   6:     0x55b75e9430ce - rustup::toolchain::Toolchain::bare_add_component::h88b55606aea5d939
   7:     0x55b75e941992 - rustup::toolchain::Toolchain::add_component::he3e2dd1682bf32e5
   8:     0x55b75e8fdc3e - rustup_init::rustup_mode::target_add::h0a5c91d969e73dd4
   9:     0x55b75e8eb835 - rustup_init::rustup_mode::main::h3d9166ae73c6fc5f
  10:     0x55b75e91414f - rustup_init::main::habce3d2a29c7553b
  11:     0x55b75eca5277 - std::panicking::try::call::h5df3ac2979db3c90
  12:     0x55b75ecad946 - __rust_maybe_catch_panic
  13:     0x55b75eca46e9 - std::rt::lang_start::hfe9ab243c60ffb9b
  14:     0x7fd1ade85290 - __libc_start_main
  15:     0x55b75e8d4cd4 - <unknown>

$ tree $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-musl
/home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl
└── lib
    ├── crt1.o
    ├── crti.o
    ├── crtn.o
    ├── liballoc-6eb85298.rlib
    ├── liballoc_jemalloc-6eb85298.rlib
    ├── liballoc_system-6eb85298.rlib
    ├── libcollections-6eb85298.rlib
    ├── libcompiler_builtins-6eb85298.rlib
    ├── libcore-6eb85298.rlib
    ├── libgetopts-6eb85298.rlib
    ├── liblibc-6eb85298.rlib
    ├── libpanic_abort-6eb85298.rlib
    ├── libpanic_unwind-6eb85298.rlib
    ├── librand-6eb85298.rlib
    ├── librustc_bitflags-6eb85298.rlib
    ├── librustc_unicode-6eb85298.rlib
    ├── libstd-6eb85298.rlib
    ├── libterm-6eb85298.rlib
    ├── libtest-6eb85298.rlib
    └── libunwind-6eb85298.rlib

1 directory, 20 files
$ rustup toolchain remove nightly
$ rustup default nightly
$ rustup target add x86_64-unknown-linux-musl

"fixed" it

Killing rustup partway through installation _will_ leave the directory in an inconsistent state, but it's not related to this issue.

Can NOT fixed this issue. GCP unbuntu 18.04.

root@g:~# rustup default nightly
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2020-06-30, rust version 1.46.0-nightly (0ca7f74db 2020-06-29)
info: downloading component 'cargo'
  5.0 MiB /   5.0 MiB (100 %)   2.9 MiB/s in  1s ETA:  0s
info: downloading component 'clippy'
info: downloading component 'rust-docs'
 12.7 MiB /  12.7 MiB (100 %)   3.2 MiB/s in  2s ETA:  0s
info: downloading component 'rust-std'
 16.1 MiB /  16.1 MiB (100 %)   3.2 MiB/s in  2s ETA:  0s
info: downloading component 'rustc'
 49.2 MiB /  49.2 MiB (100 %)  13.5 MiB/s in  4s ETA:  0s
info: downloading component 'rustfmt'
  3.4 MiB /   3.4 MiB (100 %)   2.8 MiB/s in  1s ETA:  0s
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-docs'
 12.7 MiB /  12.7 MiB (100 %)   1.1 MiB/s in  9s ETA:  0s
info: installing component 'rust-std'
 16.1 MiB /  16.1 MiB (100 %)   6.4 MiB/s in  2s ETA:  0s
info: installing component 'rustc'
 26.7 MiB /  49.2 MiB ( 54 %)   9.2 MiB/s in  3s ETA:  2sKilled
root@g:~# 

@ssrlive Your issue does not look to be directly related to this issue. Please file a fresh issue and ensure you include the exit code after this failure because knowing why rustup was killed will be critical to our determining how to fix the issue.

This is another instance of missing/corrupt manifest data. Without knowledge of the installed file, rustup cannot remove it prior to installing the updated version, and then hits a conflict due to the file already existing, and you get the error.

We've got a bunch of these bugs scattered all over the place, I'm closing them all to bring order. See #2417.

Was this page helpful?
0 / 5 - 0 ratings