rust-lang-deprecated / rustup.sh Goto Github PK

I am trying to provision a Vagrant machine, but have ran into problems with the provision of Rustup, partially caused (I think), because it isn't non-interactive.

I have tried curl ... | sh -- -y, however that doesn't work either. What would be preferable would be a generated script that assumes non-interactive.

For example rustup-noninter.sh.

To reproduce:

curl https://sh.rustup.rs -sSf | sh
info: downloading installer
sh: line 250: 16025 Segmentation fault      (core dumped) "$@"
rustup: command failed: /tmp/tmp.0hp65M1orc/rustup-init

The system:

Linux rh-power-vm49 4.4.6-300.fc23.ppc64le #1 SMP Wed Mar 23 19:27:26 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux

The actual version:

/tmp/tmp.XdYY5WgBxH/rustup-init -V
rustup-init 0.6.1 (71f7482 2016-08-24)

The backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000205f0c38 in je_huge_dalloc ()
Missing separate debuginfos, use: dnf debuginfo-install libgcc-5.3.1-6.fc23.ppc64le
(gdb) bt
#0  0x00000000205f0c38 in je_huge_dalloc ()
#1  0x00000000205cd7f0 in sdallocx ()
#2  0x00000000205c5e4c in __rust_deallocate ()
#3  0x00000000200e1300 in rustup_init::self_update::do_anti_sudo_check::home_mismatch::heb4fde5439976c13 ()
#4  0x00000000200dbfac in rustup_init::self_update::install::h5c8318effea204c9 ()
#5  0x00000000200f0fe8 in rustup_init::main::he9ea588d309e0baa ()
#6  0x00000000205b73a4 in std::panicking::try::do_call::h9d5ad283de22edbd ()
#7  0x00000000205c1f48 in __rust_maybe_catch_panic ()
#8  0x00000000205b6220 in std::rt::lang_start::h352a66f5026f54bd ()
#9  0x00000000200f2cf8 in main ()

I would like to use rustup and cargo on a machine without direct internet connection. For that I need to tunnel all their traffic via ssh.

It would be great if there was a list somewhere of all the urls, protocols (http, https, ssh), and ports, that rustup and cargo use. That would help me set up an appropriate tunnel much faster.

Many systems don't have /usr/local/lib in their LD_LIBRARY_PATH. On those systems rustc cannot find its libraries right after installation.

To change LD_LIBRARY_PATH only temporarily solves the problem, to change .profile (or similar files) restricts rust to the installing user. So the preferable solution would be to run sudo ldconfig right after the current installation routine, iff the current libdir is not in LD_LIBRARY_PATH.

There's a lot of code here that would not need to run as root if rustup.sh did the sudo invocation itself, and ~/.rustup would not need to be owned by root.

Some considerations:

• How to detect when sudo is needed
• What to do when there's no tty
• Needs to accommodate non-interactive tools

It would be great if the signing key were published on keybase.io (under the name "rustlang"). That way people like me who aren't particularly comfortable with GPG can use the Keybase process to determine whether the key should be trusted.

Just installed Rust and see that all files with documentation have executable bit. Why installers did it? I'm on Fedora 22 if it matters.

Since the arm-linux-gnueabihf target will fail a cargo build --target=arm-unknown-linux-gnueabihf without an appropriate linker, I think the linker should be automatically checked / included in the target install.

The issue is that sudo is not available. Should not be necessary since docker user is usually root during the build phase. Simple check if we are root and ommit sudo should work fine.

FROM buildpack-deps:jessie

RUN apt-get update && apt-get install sudo -y \
     && curl -sSf https://static.rust-lang.org/rustup.sh | sh \
     && cargo install ... \
     && SUDO_FORCE_REMOVE=yes apt-get remove sudo -y \
     && rm -rf /var/lib/apt/lists/*

I could save 3 LOC.

Our build is broken since earlier today because the rust-up installer exits with a faulty status code despite all going fine. You can find the logs here: https://travis-ci.org/ligthyear/clippy-service/builds/114785173#L141

The last build that ran the script successful was 23h ago, before the big merge of #33, so the bug was presumably introduced in that change. We did not do any changes to the code in that time frame.

I am not at all familiar with the code base but a quick look lets me suspect that not returning anything from install_toolchain_from_dist and then checking that return value for != 0 might be at fault here – but I am not a Bash expert.

The official website says the current nightly is 1.15 but 1.14 is downloaded when using the script.

Original issue was filed at rust-lang/rust#24546 but it should probably be tracked here.

After running rustup.sh today, I have several hundred executable HTML and JS (and some more) files below /usr/local/share/doc/rust/html/. I don't think this is intentional.

Affected versions:

• rustup.sh from static.rust-lang.org from today, with today's nightly for x86_64 linux systems
• rustup.sh from end of may, with nightly from mid-june

curl is a single thread downloader, sometime it is so slow.
I think using a custom downloader environment is good idea!
For example:

$export RUSTUP_DOWNLOADER="axel -n 5 --alternate" 
$multirust update nightly

$ multirust update nightly
multirust: installing toolchain 'nightly'
rustup: gpg available. signatures will be verified
/home/vi/home/rust/prefix/bin/rustup.sh: 1512: [: 1: unexpected operator
rustup: downloading manifest for 'nightly'
^C

$ checkbashisms /home/vi/home/rust/prefix/bin/rustup.sh
possible bashism in /home/vi/home/rust/prefix/bin/rustup.sh line 84 ('command' with option other than -p):
    if command -v gpg2 > /dev/null 2>&1; then
possible bashism in /home/vi/home/rust/prefix/bin/rustup.sh line 88 ('command' with option other than -p):
    if command -v "$gpg_exe" > /dev/null 2>&1; then
possible bashism in /home/vi/home/rust/prefix/bin/rustup.sh line 1388 ('command' with option other than -p):
    if command -v "$sha256sum_cmd" > /dev/null 2>&1; then
possible bashism in /home/vi/home/rust/prefix/bin/rustup.sh line 1390 ('command' with option other than -p):
    elif command -v shasum > /dev/null 2>&1; then
possible bashism in /home/vi/home/rust/prefix/bin/rustup.sh line 1407 ('command' with option other than -p):
    if command -v "$sha256sum_cmd" > /dev/null 2>&1; then
possible bashism in /home/vi/home/rust/prefix/bin/rustup.sh line 1409 ('command' with option other than -p):
    elif command -v shasum > /dev/null 2>&1; then
possible bashism in /home/vi/home/rust/prefix/bin/rustup.sh line 1512 (should be 'b = a'):
            if [ $? == 0 ]; then
possible bashism in /home/vi/home/rust/prefix/bin/rustup.sh line 1787 (read with option other than -r):
    read -p "Continue? (y/N) " _yn < /dev/tty

Maybe it should be #!/bin/bash?

As mentioned in brson/multirust#76

Having run a few newbs through their first rustup process, the feedback I got was: "I don't know what it just did or why... It would nice if it told me what it installed so I could kick the tires on my new tools"

Perhaps 2 lines for each binary:

Tool name :  
/path/to/file -
Brief description of tool

e.g.

Rustup completed successfully.
The following tools were installed : 
Cargo - Your Command-Line gateway into the Rust Ecosystem!
/usr/local/bin/cargo

Rustc - The Infamous Rust Compiler
/usr/local/bin/rustc

...

A related feature for power users then, might a --quiet option.

rustup-init (whatever is current as of 2016-08-22) segfaulted failed on 2 different mbp models, both running 10.10.5.

lldb output:

23Process 1740 launched: '/Users/qdot/Downloads/rustup-init' (x86_64)
23Process 1740 stopped
* thread #1: tid = 0x2890, 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176
rustup-init`je_huge_dalloc:
->  0x10024cbf0 <+176>: movq   (%r8,%rdx,8), %r14
    0x10024cbf4 <+180>: movq   (%r14), %rbx
    0x10024cbf7 <+183>: movq   %rbx, -0x30(%rbp)
    0x10024cbfb <+187>: movq   %rsi, %rdi
(lldb) bt
* thread #1: tid = 0x2890, 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010024cbf0 rustup-init`je_huge_dalloc + 176
    frame #1: 0x000000010023624f rustup-init`je_sdallocx + 1087
    frame #2: 0x000000010002cbd2 rustup-init`rustup_init::self_update::install::h7237ab7ae2a2da9d + 5154
    frame #3: 0x000000010003df21 rustup-init`rustup_init::main::h4ad9acfe630cd1dd + 5857
    frame #4: 0x0000000100230beb rustup-init`__rust_maybe_catch_panic + 27
    frame #5: 0x000000010022f2ff rustup-init`std::rt::lang_start::h352a66f5026f54bd + 399
    frame #6: 0x0000000100001484 rustup-init`start + 52
(lldb)

I needed to install a few things in my minimal docker env to make rustup work (sudo, tar, file). It would be nice if I knew everything that was missing up-front, instead of having to re-run rustup and re-run yum install three times each.

Just getting back into rust and installed rustup. Tried to install the nightly build and encountered the following error:

$ rustup install nightly
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: installing component 'rustc'
info: rolling back changes
error: failed to extract package
info: caused by: failed to unpack `rustc-nightly-x86_64-unknown-linux-gnu/rustc/share/man/man1/rustdoc.1` into `/home/david/.rustup/tmp/wnj79prt3m8vg6f2_dir/rustc/share/man/man1/rustdoc.1`
info: caused by: No such file or directory (os error 2)

Not sure if this is a nightly issue, a rustup issue, or my own lack of experience with rustup. Currently running Linux Mint 18

I am not sure where I should report this, but

The Book https://doc.rust-lang.org/book/getting-started.html#installing-rust says to install rust as:

curl https://sh.rustup.rs -sSf | sh

But, sh.rustup.rs has wrong ssl certificate as:

$ wget https://sh.rustup.rs
--2017-05-25 14:38:34--  https://sh.rustup.rs/
Resolving sh.rustup.rs... 54.215.0.2
Connecting to sh.rustup.rs|54.215.0.2|:443... connected.
ERROR: certificate common name “*.rust-lang.org” doesn’t match requested host name “sh.rustup.rs”.
To connect to sh.rustup.rs insecurely, use ‘--no-check-certificate’.

or

$ openssl s_client -connect sh.rustup.rs:443 -showcerts
...
---
Server certificate
subject=/OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.rust-lang.org
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4999 bytes and written 375 bytes

Currently, Travis-CI invokes rustup.sh to download the requested rust toolchain.
This enabled it to also support channels next to specific versions.

There is one drawback however. The output of curl -# is very verbose as you can see in this log.

It would be nice if rustup could handle this issue some way. I can think of:

• Add a flag to suppress all progress output
• Add a flag to switch to the 'normal' curl progress (this has an output of just once per second)
• Always show the normal curl progress

I'm running in a minimal docker container, as root.

Rustup fails with sudo: command not found, even though I'm root and sudo is not necessary.

Rust-by-example is failing on travis at rustup. I've tried to figure out the issue here but haven't had any success. I'm not sure what the problem is. This was the original error.

[EDIT] The important part from the console

 $ curl -L https://static.rust-lang.org/rustup.sh | sudo sh -s -- --channel=nightly
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 37166  100 37166    0     0  79838      0 --:--:-- --:--:-- --:--:--  107k
rustup: gpg available. signatures will be verified
rustup: downloading manifest for 'nightly'
gpg: WARNING: unsafe ownership on configuration file `/home/travis/.gnupg/gpg.conf'
rustup: downloading toolchain for 'nightly'
######################################################################## 100.0%
gpg: WARNING: unsafe ownership on configuration file `/home/travis/.gnupg/gpg.conf'
gpg: WARNING: unsafe ownership on configuration file `/home/travis/.gnupg/gpg.conf'
gpg: Signature made Mon 13 Apr 2015 10:27:08 AM UTC using RSA key ID 7B3B09DC
gpg: Good signature from "Rust Language (Tag and Release Signing Key) <[email protected]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 108F 6620 5EAE B0AA A8DD  5E1C 85AB 96E6 FA1B E5FE
     Subkey fingerprint: C134 66B7 E169 A085 1886  3216 5CB4 A934 7B3B 09DC
rustup: extracting installer
rustup: installing toolchain for 'nightly'
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'cargo'
install: installing component 'rust-docs'
    Rust is ready to roll.
0.01s
$ rustc --version
rustc: error while loading shared libraries: librustc_driver-4e7c5e5c.so: cannot open shared object file: No such file or directory
The command "rustc --version" exited with 127.

 db48x  ~  sh rustup.sh 
info: downloading installer
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 9500k  100 9500k    0     0  14744      0  0:10:59  0:10:59 --:--:-- 33938
warning: it looks like you have existing multirust metadata
warning: rustup cannot be installed alongside multirust
warning: delete `/home/db48x/.multirust` before installing rustup
error: cannot install while multirust is installed
rustup: command failed: /tmp/tmp.FDRmWtDAD3/rustup-init

Much better to fail early. Doesn't help either that it deleted the temporary directory. BTW, have you thought about making an rpm/deb instead of reinventing the wheel?

Patchelf is a project from Nix which modifies the rpath of shared objects and executable binaries to include a static modification of the runtime load path for shared objects. Nix uses this to a great extent to allow for multiple non-conflicting versions of packages to be installed on a single system.

Using patchelf to modify the rust binaries and libraries to set each file's rpath to the $PREFIX/lib location seems to work seamlessly for making rust work with non-sudo installs.

Is anyone aware of an issue with this?

Would it be reasonable to add a flag that checks if patchelf is available and automatically takes care of running it when --prefix has been set?

If I run rustup.sh one day after the nightly was published, and again the next day before the nightly was published, it downloads the nightly and installs it even though I already have it installed. I'd much prefer it if it could detect that it matches my existing nightly and tell me instead.

One way to do this might be to record the date of the most recently-installed nightly, along with a hash of the installed rustc binary. When asked to install again, if the most recent nightly (or the specified version) matches what rustup thinks it last installed, it can then hash the rustc binary again, and if it matches, decide that it means it has no work to do. A flag could be added, such as --force, to make it skip the version check and install the requested version anyway (in case the user damaged their install and wants a fresh one).

$ ./rustup-init
error: it looks like you have an existing installation of Rust at:
error: /usr/bin
error: rustup cannot be installed alongside Rust. Please uninstall first
error: if this is what you want, restart the installation with `-y'
error: cannot install while Rust is installed

This should probably be an interactive question instead, so inexperienced users have a chance to install rustup without removing the systems rust installation. (Which I would consider a bad idea.)

Currently rustup support only for --uninstall flag when rust have been already installed on user's machine. Same way it's better if we can have an update flag. Same way installers and rustc have to support update the language

I want to install rust in a Dockerfile in a way that is reproducible, and future proof. The apt install rustc is too old, so I'm trying rustup.

I was reading the --help for rustup. It has this example:

rustup.sh --revision=1.0.0-beta

But I cannot find any way to enumerate valid options for revision. Here's a dockerfile that mentions "1.4.0".. In fact, "1.4.0" worked for me, but "1.0.0-beta" from the docs did not. Nor did "1.13.0-beta".

I was able to get "1.12.0" to work, which is fine for my purposes, but:

1. it would be great to have a page to visit to enumerate these, ideally linked from the docs
2. I don't know if this is intended to be a stable way to install rust that will work N years in the future.

I made a small PowerShell script for myself to grab the latest nightly and install it.

@retep998 suggested I submit it here, though I'm a bit reluctant to do so in its current state:

• It depends on 7z existing somewhere
• It depends on the structure of the tar files not changing

and finally

• PowerShell sucks, because by default PowerShell script execution is disabled. One could enable it in that shell session by Set-ExecutionPolicy Unrestricted Process though.

./rustup.sh --prefix /mnt/prefix --channel nightly --disable-sudo --save -y - installs stable into /usr/local...

tl;dr; Looks like the problem is related to improper handling of path delimiters:

$ rustup target add i686-pc-windows-msvc
info: downloading component 'rust-std' for 'i686-pc-windows-msvc'
info: installing component 'rust-std' for 'i686-pc-windows-msvc'
info: rolling back changes
error: could not copy file from '/home/korvin/.rustup/tmp/62v1xsw0ae7ppgnh_dir/rust-std-i686-pc-windows-msvc/lib\rustlib\i686-pc-windows-msvc\lib\arena-04cd199c7c4cce31.dll' to '/home/korvin/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib\rustlib\i686-pc-windows-msvc\lib\arena-04cd199c7c4cce31.dll'
info: caused by: the source path is not an existing regular file

Notice that the first part of the path uses / and after toolchain triple it gets switched to \ which obviously will not be treated as a valid path on Linux.

I'm running the recent rustup version: rustup 1.3.0 (124170c 2017-05-09)

Hello, i tried rustup.sh on NetBSD it fails with the following error message:

rustup: gpg available. signatures will be verified
rustup: unrecognized OS type: NetBSD

the appended patch resolved this error
rustup.patch.txt

This option is useful with racer as it requires a directory to the rust source.

rustup.sh should have a way to update itself.

I'm trying to run rustup in an ubuntu arm64 machine, and I'm getting this message:

rustup: unknown CPU type: aarch64

After uninstalling Rust I see that empty $prefix/share/doc/{cargo,rust} directories still here. I think that uninstaller should remove them (or at least try to do rmdir).

When I'm trying to follow instructions and install Rust I see the error that scares me:

gpg: assuming signed data in '/home/coder/.rustup/dl/be644b01552c9dba7a05/rust-1.11.0-x86_64-unknown-linux-gnu.tar.gz'
gpg: Signature made Tue 16 Aug 2016 01:35:16 PM CEST using RSA key ID 7B3B09DC
gpg: Good signature from "Rust Language (Tag and Release Signing Key) <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 108F 6620 5EAE B0AA A8DD  5E1C 85AB 96E6 FA1B E5FE
     Subkey fingerprint: C134 66B7 E169 A085 1886  3216 5CB4 A934 7B3B 09DC

I've canceled my installation because I'm not sure what's inside. Why we have problem with signature and if we can't fix it why we're using it?

Is there a way to define the default toolchain that installed when running rustup.sh? This is useful on slower networks to not have to download 2 toolchains, the stable when installing then the preferred one later. Specifically using this in docker so the smaller the image the better.

rustup.sh is currently failing on TravisCI, with no indication as to what the error is.
It has also been reported on the TravisCI bugtracker: travis-ci/travis-ci#6654

It may be related to changes made in #71.

Here is the full error message:

The command "sh /rust-installer/rustup.sh --prefix=/rust --spec=stable -y --disable-sudo 2> /dev/null" failed and exited with 1 during .

If you build the rls using the rustup rust nighty, it will build successfully, but it won't properly set up the rpath. This causes the resulting rls to fail to run correctly on at least macOS and Windows (and possibly other platforms).

Hi,

I tried to run install.sh (or rustup) from a dockerfile...

RUN curl -s https://static.rust-lang.org/rustup.sh > /home/install.sh
RUN chmod +x /home/install.sh
RUN sh /home/install.sh --disable-sudo

... but got the error:

/home/install.sh: line 1290: /dev/tty: No such device or address
rustup: failed to read from /dev/tty

When I run the docker container without running installation at image build, rustup works and run.

So, if I am right, it appears to be because it turns to be an interactive installation process and so, only doable when tty are present.

Does a not-interactive option could be added ?

Thanks.

I try to install rust from a mirror:

export RUSTUP_DIST_SERVER=https://mirrors.ustc.edu.cn/rust-static
rustup.sh --channel=beta  # Or --channel=nightly

But curl still downloads from https://static.rust-lang.org/

rustup.sh --channel=stable works as expected.

How to download the beta/nightly toolchain from a mirror?