Rustup seems unable to download files on my system:
$ ./rustup.sh -v --default-toolchain nightly
info: downloading installer
Welcome to Rust!
This will download and install the official compiler for the Rust programming
language, and its package manager, Cargo.
It will add the cargo, rustc, rustup and other commands to Cargo's bin
directory, located at:
/home/ajr/.cargo/bin
This path will then be added to your PATH environment variable by modifying the
profile file located at:
/home/ajr/.profile
You can uninstall at any time with rustup self uninstall and these changes will
be reverted.
Current installation options:
default host triple: x86_64-unknown-linux-gnu
default toolchain: nightly
modify PATH variable: yes
1) Proceed with installation (default)
2) Customize installation
3) Cancel installation
1
verbose: installing toolchain 'nightly-x86_64-unknown-linux-gnu'
verbose: toolchain directory: '/home/ajr/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
verbose: creating temp file: /home/ajr/.rustup/tmp/5ow4nv7ga952c6gd_file
verbose: downloading file from: 'https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256'
verbose: downloading with curl
verbose: removing toolchain directory: '/home/ajr/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256' to '/home/ajr/.rustup/tmp/5ow4nv7ga952c6gd_file
info: caused by: error during download
info: caused by: [6] Couldn't resolve host name (Couldn't resolve host 'static.rust-lang.org')
rustup: command failed: /tmp/tmp.1idI66A40j/rustup-init -v --default-toolchain nightly
However, I think the "Couldn't resolve host name" error is a red herring. I can download the file manually:
$ curl https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256 -o /home/ajr/.rustup/tmp/5ow4nv7ga952c6gd_file
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 92 100 92 0 0 619 0 --:--:-- --:--:-- --:--:-- 617
$ cat ~/.rustup/tmp/5ow4nv7ga952c6gd_file
cc1911a14ebe4b8c7cae05351c11072f605752d2dba7464d6ca69c861142edd0 channel-rust-nightly.toml
And I can definitely resolve the hostname "static.rust-lang.org":
$ dig static.rust-lang.org
; <<>> DiG 9.10.4-P4 <<>> static.rust-lang.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46648
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 13, ADDITIONAL: 16
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;static.rust-lang.org. IN A
;; ANSWER SECTION:
static.rust-lang.org. 9359 IN CNAME d3ah34wvbudrdd.cloudfront.net.
d3ah34wvbudrdd.cloudfront.net. 25 IN A 54.192.147.130
d3ah34wvbudrdd.cloudfront.net. 25 IN A 54.192.147.42
d3ah34wvbudrdd.cloudfront.net. 25 IN A 54.192.147.245
d3ah34wvbudrdd.cloudfront.net. 25 IN A 54.192.147.163
d3ah34wvbudrdd.cloudfront.net. 25 IN A 54.192.147.75
d3ah34wvbudrdd.cloudfront.net. 25 IN A 54.192.147.151
d3ah34wvbudrdd.cloudfront.net. 25 IN A 54.192.147.240
d3ah34wvbudrdd.cloudfront.net. 25 IN A 54.192.147.56
;; AUTHORITY SECTION:
net. 50427 IN NS k.gtld-servers.net.
net. 50427 IN NS i.gtld-servers.net.
net. 50427 IN NS h.gtld-servers.net.
net. 50427 IN NS a.gtld-servers.net.
net. 50427 IN NS c.gtld-servers.net.
net. 50427 IN NS g.gtld-servers.net.
net. 50427 IN NS j.gtld-servers.net.
net. 50427 IN NS f.gtld-servers.net.
net. 50427 IN NS l.gtld-servers.net.
net. 50427 IN NS e.gtld-servers.net.
net. 50427 IN NS m.gtld-servers.net.
net. 50427 IN NS b.gtld-servers.net.
net. 50427 IN NS d.gtld-servers.net.
;; ADDITIONAL SECTION:
h.gtld-servers.net. 50427 IN A 192.54.112.30
d.gtld-servers.net. 28232 IN A 192.31.80.30
i.gtld-servers.net. 50427 IN A 192.43.172.30
b.gtld-servers.net. 50427 IN A 192.33.14.30
k.gtld-servers.net. 50427 IN A 192.52.178.30
e.gtld-servers.net. 37229 IN A 192.12.94.30
m.gtld-servers.net. 50427 IN A 192.55.83.30
j.gtld-servers.net. 50427 IN A 192.48.79.30
g.gtld-servers.net. 39512 IN A 192.42.93.30
a.gtld-servers.net. 50427 IN A 192.5.6.30
l.gtld-servers.net. 50427 IN A 192.41.162.30
c.gtld-servers.net. 50427 IN A 192.26.92.30
f.gtld-servers.net. 50427 IN A 192.35.51.30
b.gtld-servers.net. 50427 IN AAAA 2001:503:231d::2:30
a.gtld-servers.net. 50427 IN AAAA 2001:503:a83e::2:30
;; Query time: 0 msec
;; SERVER: 10.10.0.2#53(10.10.0.2)
;; WHEN: Sat Jan 14 23:22:12 PST 2017
;; MSG SIZE rcvd: 705
Hmm, it certainly seems like curl (or, c-ares) is just not doing the right thing in trying to resolve DNS. The installer works correctly if I grab one of the IP addresses from "dig" and put it in /etc/hosts. However, because when I run curl on the command-line it works fine, I suspect that rustup is calling it somehow differently which causes it to break.
Thank you for the report @CmdrMoozy!
This is surprising. Haven't seen curl behave like this before.
I'll add that appveyor is currently displaying this behavior: https://ci.appveyor.com/project/droundy/fac/build/job/b51h59hqmqefx46f
I have no idea what causes it, or if it's happening across all appveyor tests at the moment.
This might be related to IPv6, in which case it would be a duplicate of #877.
On my system, curl https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256 hangs, while curl -4 https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256 works like a charm.
Same problem for me here too, but only on one computer.
Really weird. I can download directly from static.rust-lang.org (https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init) on other machines.
But when i try to download using that link in web browser on one machine I get "server not found".
Problem is if you have IPv6 enabled.
Disabling it solved the problem for me.
I've observed this issue on 2 newly installed ubuntu 14.04 machines on monday.
Disabling ipv6 (via kernel, nm, etc) didn't appear to fix things.
Found that editing /etc/resolv.conf to change the nameserver from nameserver 127.0.0.1 (which goes to dnsmasq run by NetworkManager) to nameserver 8.8.8.8 (likely any other would work too) resolved things.
Seems that something is going wrong with what ip addresses are returned from dnsmasq in some cases.
I found that disconnecting from WiFi and then connecting again worked.
Same thing happened to me when I was connected to a VPN from WSL Ubuntu. I fixed it by commenting out everything except nameserver 1.1.1.1 from /etc/resolv.conf for the duration of the install (or simply disconnect VPN).
I also have had the same issues over VPN for quite a while. I've worked around it by setting https_proxy. Same issue and workaround for cargo
Most helpful comment
I've observed this issue on 2 newly installed ubuntu 14.04 machines on monday.
Disabling ipv6 (via kernel, nm, etc) didn't appear to fix things.
Found that editing
/etc/resolv.confto change the nameserver fromnameserver 127.0.0.1(which goes to dnsmasq run by NetworkManager) tonameserver 8.8.8.8(likely any other would work too) resolved things.Seems that something is going wrong with what ip addresses are returned from dnsmasq in some cases.