FWIW, I just used the "advanced" installation, and while yes, it wasn't very stylish, it worked just fine. I wouldn't really worry about it much for right now.
I purposfully asked rustup not to modify my PATH envvar. At the end of the install I got this helpful reminder:
To get started you need Cargo's bin directory in your `PATH`
environment variable.
It would be even more helpful if it also reminded me what bin directory to add 
@themax Yes. What I intend to do is make the default host configurable during install. That would mean that the website would still tell you to download the same rustup-init.exe as today, and the install message would indicate that the default is i686-pc-windows-gnu (or msvc when we make it the default), and you can change it interactively.
We might further have rustup-init try to detect both the architecture and the native toolchain during install and set the default automatically.
In the meantime you can install the 64-bit toolchain with rustup default x86_64-pc-windows-gnu.
How does that sound @themax?
Nice observation. Issue.
The big change is that the website now looks like the rust-lang website. Give it a look and see what you think.
@peschkaj also landed some prelimenary telemetry infrastructure. The feature is turned off and still hidden in the UI, but it can log some simple events, including capturing rustc error numbers.
Thanks to everyone who contributed to this one:
This kind of issue typically occurs due to anti virus software. Can you confirm whether this still occurs when your anti virus is disabled?
Sounds good.
What about 64 bit binaries for rustup-init.exe itself? My suggestion is to change www.rustup.rs to a similar layout as the [main download page for rust] (https://www.rust-lang.org/downloads.html) so that it’s easier to find the available download options.
Do you rember what command it was running when it hanged? Issue.
@brson what am I doing wrong?
max@pc MSYS ~
$ rustup show
nightly-i686-pc-windows-gnu (default toolchain)
max@pc MSYS ~
$ rustup toolchain list
nightly-i686-pc-windows-gnu (default)
max@pc MSYS ~
$ rustup default x86_64-pc-windows-gnu
error: toolchain 'x86_64-pc-windows-gnu' is not installed
max@pc MSYS ~
$ rustup override add x86_64-pc-windows-gnu
error: toolchain 'x86_64-pc-windows-gnu' is not installed
Edit:
I can reproduce the issue. I can run rustup commands using the msys shell but I see 2 rustup.exe processes in the Task Manager which cannot be killed.
Also, cargo update hangs (not sure if it's related or maybe it's because I am using 32 bit binaries?)
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.
@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.
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
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?
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
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.
rustup self update <-- this is the best feature! It’s so easy 
Thanks for all the hard work!
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.
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.
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.
It's due to technical limitations in rust-installer that multirust doesn't clean up its metadata.
Agreed.
rustup 0.1.9 has major networking problems on Windows that I’m investigating.
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.