Beta testing rustup.rs


#108

I get this error when trying to install rustup on AArch64:

info: syncing channel updates for 'stable-aarch64-unknown-linux-gnu'
error: some components unavailable for download: 'rustc', 'rust-docs', 'cargo'
rustup: command failed: /tmp/tmp.6O56q7aU5O/rustup-init

It seems that aarch64 rustc is only available on nightly. I worked around it by installing the nightly toolchain manually, however it would be nice if this was done automatically at installation time (when first running the script from curl), If a stable toolchain for the current architecture is not available then it should automatically fall back to a beta or nightly toolchain.


#109

@themax your default and override commands need to be passed the toolchain name stable-x86_64-pc-windows-gnu. Note the ‘stable’.

Thanks for the details about the hanging issue. I’ve tried just doing some normal rustup commands and looking for zombie instances in task manager, but so far haven’t reproduced what you are seeing.

It certainly sounds related. This isn’t a bug that I’ve heard of. Does cargo update hang consistently or just sometimes?

@Amanieu Thanks for the report about aarch64. I agree this error needs to be a lot better. So many people have hit it testing out the new platforms.


#110

Any cargo command hangs, even cargo without any extra argument. In Process Explorer I can see multirust.exe seem to actually call cargo so I think it’s actually multirust.exe that has an issue. No idea how multirust.exe is involved in the whole chain.

I did some more tests and I am pretty sure it has something to do with the 32 bit binaries as all the issues disappear if I manually download and use 64 bit rustup-init.exe to install the toolchain.

EDIT:

I was too quick to say that everything works when using the 64 bit binaries only. cargo build still hangs (actually rustc seem to hang). cargo update works fine.

Last strace lines for cargo build :

--- Process 9208 loaded C:\Windows\System32\shell32.dll at 000007FEFE450000
--- Process 9208 loaded C:\Windows\System32\shlwapi.dll at 000007FEFD8E0000
--- Process 9208 loaded C:\Windows\System32\userenv.dll at 000007FEFD180000
--- Process 9208 loaded C:\Windows\System32\profapi.dll at 000007FEFD040000
--- Process 9208 loaded C:\Windows\System32\ws2_32.dll at 000007FEFDD20000
--- Process 9208 loaded C:\Windows\System32\nsi.dll at 000007FEFE010000
--- Process 9208 loaded C:\Windows\System32\dbghelp.dll at 000007FEF836
--- Process 9208 loaded C:\Windows\System32\shell32.dll at 000007FEFE450000
--- Process 9208 loaded C:\Windows\System32\shlwapi.dll at 000007FEFD8E0000
--- Process 9208 loaded C:\Windows\System32\userenv.dll at 000007FEFD180000
--- Process 9208 loaded C:\Windows\System32\profapi.dll at 000007FEFD040000
--- Process 9208 loaded C:\Windows\System32\ws2_32.dll at 000007FEFDD20000
--- Process 9208 loaded C:\Windows\System32\nsi.dll at 000007FEFE010000
--- Process 9208 loaded C:\Windows\System32\dbghelp.dll at 000007FEF836

Later edit:

I see that rustc gets immediately suspended (visible in System Monitor -> Analyze Wait Chain). There are no more details on why it is suspended. I guess the antivirus (Symantec) has something to do with it even if I cannot find any info in the logs.

I don’t have these issues if I manually download and install Rust. I guess it has something to do with how rustup is downloading the binaries.

Could it be that Symantec does not like binaries that suddenly pop up on the file system without being connected to an installation process?

cc @retep998


#111

Yikes. I hope if that’s the case that it is solvable. Perhaps you can try one more kind of test. Instead of calling just cargo can you call C:\Users\$YOURNAME\AppData\Local\.cargo\toolchains\stable\bin\cargo (or something like that) and confirm that that behaves correctly?


#112

I guess you mean to run /c/Users/<user>/.multirust/toolchains/nightly-x86_64-pc-windows-gnu/bin/cargo.exe.

I tried it and it worked every time!

Then I realized the binaries under ~/.cargo/bin are some sort of wrappers or something which are actually calling the ones in ~/.multirust/toolchains/<toolchain>/bin. Maybe this indirection is causing all the problems.

Edit: fix typos


#113

rustup 0.1.9 is out. This release includes a critical security fix, so please upgrade.

In this case rustup wasn’t doing TLS hostname verification, which is absolutely required for TLS to be secure. Hyper uses OpenSSL for TLS by default but at this point doesn’t implement hostname verification.

To solve this I used @sfackler’s new rust-native-tls crate. This provides TLS backed by the most appropriate implementation for each platform, including Windows’ schannel and OS X’s security framework. Most importantly it includes a hostname verifier for OpenSSL. Here’s where it’s wired up to Hyper.

For those using Hyper this is probably the right way to set up TLS at the moment. It’s so important to this get right I expect it will get easier to do quickly.

Thanks @seanmonstar and @sfackler for helping me sort this out.

0.1.9


#114

rustup self update <-- this is the best feature! It’s so easy :slight_smile:

Thanks for all the hard work!


#115

Getting back to my rustup install problems a bit later. The latest installer gives more of a hint by saying

error: toolchain ‘stable’ is not installed info: caused by: not a directory: ‘/Users/chrish/.multirust/toolchains/stable-x86_64-apple-darwin’

I renamed away ~/.multirust, and now the install succeeds. I’ve kept the old directory, so if you want me to run tests, let me know. At least I feel that if rustup doesn’t like old multirust installs, it’d be nice if it detected them and complained in a even more specific way. But otherwise, things seem to work fine so far for me, now.


#116

Yeah, I’m sorry about that. I put some defensive code in the installer this time to catch the most common cases where old rust tools are in the way. It would still not catch this though. Issue. This will also stop being a problem when the directory is finally renamed to .rustup.

Thank you for the code offer but I don’t need it at this time.


#117

But then people will have an obsolete ~/.multirust directory and it wouldn’t be obvious that it doesn’t serve any purpose anymore. Actually I would expect multirust to delete that directory when I uninstall, but I guess it makes no sense to add this “functionality” now since a lot of users have already started migrating to rustup.rs.

Once the directory changes to ~/.rustup it would be nice to at least have an option during install to delete the obsolete files from former multirust.


#118

It’s due to technical limitations in rust-installer that multirust doesn’t clean up its metadata.

Agreed.


#119

rustup 0.1.9 has major networking problems on Windows that I’m investigating.


#120
C:\msys64\home\Peter> rustup update x86_64-gnu-nightly
error: toolchain 'x86_64-gnu-nightly' is not installed

C:\msys64\home\Peter> rustup update nightly-x86_64-gnu
info: syncing channel updates for 'nightly-x86_64-pc-windows-gnu'

The first target triple is the kind I’d use with multirust-rs, so to change the triple ordering and then give me such an unhelpful error message isn’t very nice.

Furthermore, while I can choose where to install rustup during the installation procedure, it then goes ahead and installs the toolchains wherever it feels like, not giving me any control over that.


#121

In the readme it has two commands listed rustup toolchain install nightly and rustup install nightly, neither of which work.

I can’t figure out how to add targets.

C:\msys64\home\Peter> rustup target add nightly-i686-gnu
error: toolchain 'x86_64-msvc-nightly' is not installed
info: caused by: not a directory: 'C:\Users\Peter\.multirust\toolchains\x86_64-msvc-nightly'

C:\msys64\home\Peter> rustup target add i686-pc-windows-gnu
error: toolchain 'x86_64-msvc-nightly' is not installed
info: caused by: not a directory: 'C:\Users\Peter\.multirust\toolchains\x86_64-msvc-nightly'

C:\msys64\home\Peter> rustup target add nightly-i686-gnu --toolchain nightly-x86_64-gnu
error: toolchain 'nightly-x86_64-pc-windows-gnu' does not contain component 'rust-std' for target 'nightly-i686-gnu'

C:\msys64\home\Peter> rustup target add nightly-i686-pc-windows-gnu --toolchain nightly-x86_64-pc-windows-gnu
error: toolchain 'nightly-x86_64-pc-windows-gnu' does not contain component 'rust-std' for target 'nightly-i686-pc-windows-gnu'

#122

You’re right.

What control are you expecting? And what do you mean that you can choose where to install rustup? There aren’t any options to configure the installation location.

These commands were just added in 0.1.10 which was just published minutes ago. I’ve filed a PR to make the README more consistent.

Your second command is the right one, but it looks like it’s being affected by the bug in your first report where the toolchain naming scheme changed. Probably if you run rustup default nightly it will fix the name of the default toolchain and make this work again. If it continues to be broken I’d just delete ~/.multirust.

Thanks for the report.


#123

rustup 0.1.10 is out.

This contains fixes for the most egregious problems with the new TLS stack on Windows, particularly the long hangs during download. I’m going to try to get another build out later today that converts from hyper to curl to solve the Windows TLS problem better.

0.1.10


#124

Oh, I used the CARGO_HOME environment variable to tell Rustup where to install itself.


#127

rustup 0.1.11 is out. This fixes the Windows networking bustage. It’s fine to just reinstall over the existing broken installation.

0.1.11


#128

I haven’t read most of this thread, but I think no one tested it with the new Linux subsystem in Windows. I just tried it, but sadly it doesn’t really work. When running the installer sh script, everything is still working pretty nicely, except for one warning:

warning: could not delete temp directory: /home/lukas/.multirust/tmp/r9wblabla_dir

The installer ends with a green “stable installed (error reading rustc version)”. Trying to run rustc -V doesn’t print anything and ends with error code 1. This makes cargo unusable because it apparently always checks rustc -vV on startup. rustup -V works, though.

I know, the Windows Ubuntu bash is still beta (just like rustup), but here is the information. If I can help somehow by testing something, just tell me :slight_smile:


#129

So it looks like I tricked myself into believing that rustup would allow me to host different versions side by side. :slight_smile:

I started rustup out of curiosity (I’m on Windows in case that matters) and saw that it has this toggle for setting the path (or not). So I thought to myself that since my current installation from MSI is in c:\rust18 then I’m safe to grab nightly since it goes into %USERPROFILE%\.cargo. So as long as my “nightly console” goes through a script that updates my %PATH% from default installation to rustup one, I should be fine.

This wasn’t the case and now I’m inclined to believe that this wasn’t rustup’s intention to begin with. Cargo registry is now common for both installations which bit me a moment ago. I guess I have three questions as a consequence of this experience:

  1. Shouldn’t MSI installation end up entirely in the path provided by the user? Yes, I know, this isn’t directly rustup related (unless it is).
  2. Was my expectation of SxS rust installations inflated?
  3. Would it be possible to teach rustup to set the SxS builds up?

Thanks!