search

rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.77k stars 2.42k forks source link

Cargo build failed with spurious network error #6513

Open weiby3 opened 5 years ago

weiby3 commented 5 years ago

Problem error: failed to load source for a dependency on rand

Steps

$ cargo run --verbose
    Updating registry `https://github.com/rust-lang/crates.io-index`
warning: spurious network error (2 tries remaining): failed to send request: 无法与服务器建立连接
; class=Os (2)
warning: spurious network error (1 tries remaining): failed to send request: 无法与服务器建立连接
; class=Os (2)
error: failed to load source for a dependency on `rand`

Caused by:
  Unable to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to send request: 无法与服务器建立连接
; class=Os (2)

The chinese sentences above are "Unable to establish connection to server". I have check my firewall, cargo isn't blocked, and there is personal CA installed by Adguard, no proxy.

Notes OS: Windows 7 64bit, mingw64 with MSYS2 Output of cargo version: cargo 1.29.0

manaskarekar commented 4 years ago

Borked install on MacOS, I suppose, but running

sudo cargo build solved it.

I'll reinstall rust with correct permissions, but this hasn't been an issue on Linux.

kingofthebongo2008 commented 4 years ago

So cargo is not usable now on first try on windows behind windows proxy. I have got these also. Start digging

Miserlou commented 4 years ago

+1 for this error even though git connectivity is available. Suggest this may be an SSL error.

whoizit commented 4 years ago

partly blocked in Russia. I've had this problem for about two or three weeks. https://isitblockedinrussia.com/?host=crates.io

~ $ curl -L https://crates.io
{"errors":[{"detail":"Not Found"}]}
whoizit commented 4 years ago

I fix it, I just forgot that I used to set the environment variable and the proxy port has changed.

$ env | rg proxy
CARGO_HTTP_PROXY=socks5://localhost:1080
luishdosreis commented 4 years ago

Any news on this? I am getting a similar error when trying to build. http parser error: stream ended at an unexpected time; class=Http (34)

jamesmcl113 commented 4 years ago

I am getting the same error, tried deleting everything in the registry and that didn't work. I set up a mobile hotspot on my phone and tried cargo update over 4G and it worked. So for me it's a problem with my network. I recently switched ISPs so I'll have to try turning off some of the restrictions on the network and seeing if that fixes it.

Miserlou commented 4 years ago

Solution that worked for me was updating my /etc/hosts file with new IP addresses for GitHub.

inpactnosakae commented 4 years ago

Write permissions seems like a cause as well. I got this error using docker centost:8 mounting my app to /root. Even though I try to cargo build as root I get those Could not write data: Permission denied;... errors. I fixed it by simply mounting to another location.

pashinin commented 4 years ago

I can only tell that it started to work after I configured route for 52.84.214.0/24 (crates.io) through VPN. I'm from Russia, Beeline ISP. dig crates.io gives different results for different regions.

Actually it is static.crates.io - 52.84.214.8 blocked:

image

Taywee commented 3 years ago

PSA for people coming to this without any proxies in the mix (especially those who are on Gentoo like I am). This kind of issue can be caused by updating between the library http-parser versions 2.9.2, 2.9.3, and 2.9.4, as they apparently broke ABI compatibility. For me, rebuilding and reinstalling libgit2 fixed the issue.

JohnCoconut commented 3 years ago

@Taywee Hi, fellow Gentoo user. Thanks for telling me here. Does this affect other packages too? I have been very confused by the error message. Was it discussed in the gentoo forum? I have not see it unfortunately.

Taywee commented 3 years ago

@JohnCoconut This hadn't broken anything else for me, but I don't have any other packages that depend on http-parser, other than libgit2, and rust is the only thing that depends on libgit2 for me. I had just updated http-parser earlier that day. I don't remember exactly what led me to it, but I tracked it into libgit2 through some of the error messages, looked through my recent updates, and found this arch linux bug that mentioned something of the sort, and then a quick rebuild of libgit2 sorted me out. I didn't find anything in searches related to Gentoo, but I figured I'd put a PSA in here. Maybe somebody should open something in the Gentoo bug tracker. I'll see if I can do that now. edit: Gentoo ticket opened now. Thanks for reminding me that the Gentoo community deserves a heads up.

zhaohuxing commented 3 years ago

I found that it was indeed a network problem and solved it. If you do not have alternative choice to fetch what you want, you can try using SS or SSR, just go Option Settings (选项设置)->Local Proxy (本地代理), tick "Allow connections from LAN" (允许来自局域网的连接) and set Local Port (本地端口) = 1080. Then append the following to your .zshrc or .bashrc file:

alias proxy="git config --global http.proxy http://127.0.0.1:1080"
alias unproxy="git config --global --unset http.proxy"

Then cargo starts fetching successfully.

Yes, I do!

kontsaki commented 3 years ago

same behavior on docker alpine 3.13.0 installed with rustup-init running something like cargo install exa while tshark is capturing shows the following in case it helps:

/ # tshark -i eth0
Capturing on 'eth0'
    1 0.000000000   172.17.0.2 → 192.168.65.1 DNS 70 Standard query 0xfd24 A github.com
    2 0.000075222   172.17.0.2 → 192.168.65.1 DNS 70 Standard query 0x0482 AAAA github.com
    3 0.017005554 192.168.65.1 → 172.17.0.2   DNS 102 Standard query response 0xfd24 A github.com A 140.82.121.4 A 140.82.121.4
    4 0.019393212 192.168.65.1 → 172.17.0.2   DNS 70 Standard query response 0x0482 No such name AAAA github.com
    5 0.020063148   172.17.0.2 → 192.168.65.1 DNS 70 Standard query 0x1876 A github.com
    6 0.020141652   172.17.0.2 → 192.168.65.1 DNS 70 Standard query 0x1e30 AAAA github.com
    7 0.021371590 192.168.65.1 → 172.17.0.2   DNS 102 Standard query response 0x1876 A github.com A 140.82.121.4 A 140.82.121.4
    8 0.062178507 192.168.65.1 → 172.17.0.2   DNS 70 Standard query response 0x1e30 No such name AAAA github.com
    9 0.062981494   172.17.0.2 → 192.168.65.1 DNS 70 Standard query 0xbd3d A github.com
   10 0.063091636   172.17.0.2 → 192.168.65.1 DNS 70 Standard query 0xcde1 AAAA github.com
   11 0.064341130 192.168.65.1 → 172.17.0.2   DNS 102 Standard query response 0xbd3d A github.com A 140.82.121.4 A 140.82.121.4
   12 0.164843838 192.168.65.1 → 172.17.0.2   DNS 70 Standard query response 0xcde1 No such name AAAA github.com

/ # cargo install exa
    Updating crates.io index
warning: spurious network error (2 tries remaining): failed to resolve address for github.com: Name does not resolve; class=Net (12)
warning: spurious network error (1 tries remaining): failed to resolve address for github.com: Name does not resolve; class=Net (12)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  network failure seems to have happened
  if a proxy or similar is necessary `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  failed to resolve address for github.com: Name does not resolve; class=Net (12)

adding github IP in /etc/hosts solves the issue as peeps already mentioned

jeroen commented 3 years ago

I am seeing this same error. I think in my case it has to do with cargo trying to connect over ipv6, which doesn't work properly on the server isp.

Is there a variable or setting to force rustup to only use ipv4?

rottenpen commented 3 years ago

The source blocked in China. And i fix it by:

NightMachinery commented 3 years ago 
❯ RUST_LOG=trace command cargo install --git https://github.com/ajeetdsouza/zoxide/ -f --verbose          

    Updating git repository `https://github.com/ajeetdsouza/zoxide/`
  Installing zoxide v0.6.0 (https://github.com/ajeetdsouza/zoxide/#7d9ca0de)
    Updating crates.io index
 Downloading 2 crates                                                                                        
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `libc v0.2.93` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `bincode v1.3.3` within 30s)
 Downloading 2 crates                                                                                        

warning: spurious network error (1 tries remaining): [28] Timeout was reached (download of `bincode v1.3.3` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (1 tries remaining): [28] Timeout was reached (failed to download any data for `libc v0.2.93` within 30s)
 Downloading 2 crates                                                                                        

error: failed to compile `zoxide v0.6.0 (https://github.com/ajeetdsouza/zoxide/#7d9ca0de)`, intermediate artifacts can be found at `/var/folders/5v/g3zxt_7d64g3sd_56bzpqbvh0000gn/T/cargo-install5kMhqX`

Caused by:
  failed to download from `https://crates.io/api/v1/crates/libc/0.2.93/download`

Caused by:
  [28] Timeout was reached (download of `libc v0.2.93` failed to transfer more than 10 bytes in 30s)

As you can see, the connection doesn't seem to be the problem, as aria2 can download the file easily. I do have a Wireguard VPN active (the local connection is from Iran, the Wireguard VPN is located in London), if that matters. Using the Chinese mirror works fine though, so it seems that cargo is somehow escpaping the Wireguard VPN?

❯ aria2c 'https://crates.io/api/v1/crates/libc/0.2.93/download'                   

04/22 16:28:09 [NOTICE] Downloading 1 item(s)
[#df7395 0B/0B CN:1 DL:0B]                                                                                    
04/22 16:28:10 [NOTICE] CUID#7 - Redirecting to https://static.crates.io/crates/libc/libc-0.2.93.crate
[#df7395 464KiB/498KiB(92%) CN:1 DL:205KiB]                                                                   
04/22 16:28:15 [NOTICE] Download complete: /Users/evar/TMP/libc-0.2.93.crate

Download Results:
gid   |stat|avg speed  |path/URI
======+====+===========+=======================================================
df7395|OK  |   140KiB/s|/Users/evar/TMP/libc-0.2.93.crate

Status Legend:
(OK):download completed.
shoober420 commented 3 years ago

If anyone on gentoo comes across this error, its apparently by design with portage. I dont even have a .cargo folder in my home directory so gentoo and librsvg-9999 git master cant be a thing on gentoo as of this post.

https://forums.gentoo.org/viewtopic-t-1134891-highlight-.html

EDIT: You can use "FEATURES="-network-sandbox" in your make.conf file to bypass the emerge network sandbox and avoid this error.

mikzuit commented 3 years ago

Yesterday i had the same issue which lead me to digg into the problem . I just wanted to point out @weiby3 @alexcrichton the possibility that this may happens when cargo try to write into cache folder and because:

  1. you are working on docker container
  2. you are working in a remote development ide (which use docker mostly)
  3. the user you are using does not belong to sudo group
  4. you had a different/weird installation which lead to a improper permissions on cache folder

and the user you work with won't have the required permissions under the cache folder i.e /usr/local/cargo/registry/cache (this would depends on you cargo installation). so. giving the right permission with i.e

  1. sudo chown -R $(whoami) /usr/local/cargo/registry/cache
  2. also you could use mode to give writing permission to the user
  3. add the working user to a sudo group.

Possibly should we consider a relation with this issue too https://github.com/rust-lang/cargo/issues/6757

Gr3at commented 3 years ago

Possible solution for git bash users

Had the same issue, while trying to add rand = "0.8.3" as the rust-book instructs. I was getting the following error: failed to get `rand` as a dependency of package" `guessing_game v0.1.0`

Found a workaround online. Turns out i had to create the config file under ~/.cargo (wasn't created automatically) and add a network configuration.

  1. Add required configuration 
    #  config file: ~/.cargo/config.toml
[net]
git-fetch-with-cli = true
  2. Test if it works.

OS: Windows 10

cargo: 1.53.0 (4369396ce 2021-04-27) rustc: 1.53.0 (53cb7b09b 2021-06-17) git: 2.31.1.windows.1

ximon18 commented 3 years ago

Posting here in case this helps anyone else.

I seem to have "solved" this problem in my situation by using CARGO_HTTP_MULTIPLEXING=false cargo build. The issue was occurring mainly on when running cargo build as part of building a Docker image on Docker Hub and the same issue occurred when we tried using GitHub Actions build machines instead. Disabling HTTP/2 multiplexing forcing fallback to HTTP/1.1 seems to have "solved" the problem, repeated builds of two different affected Docker images have succeeded every time since the change.

The kind of issues I was seeing were of the form:

#12 52.13 Downloading crates ...
#12 202.3 warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `aho-corasick v0.7.18` failed to transfer more than 10 bytes in 30s)
#12 202.3 warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `adler32 v1.2.0` within 30s)
#12 292.3 warning: spurious network error (2 tries remaining): [92] Stream error in the HTTP/2 framing layer (HTTP/2 stream 53 was not closed cleanly before end of the underlying stream)

After lots of delays and retries the build would eventually fail with something like:

#12 1013.2 error: failed to download from `https://crates.io/api/v1/crates/tinyvec/1.4.0/download`
#12 1013.2
#12 1013.2 Caused by:
#12 1013.2 [92] Stream error in the HTTP/2 framing layer (HTTP/2 stream 59 was not closed cleanly before end of the underlying stream)
#12 ERROR: executor failed running [/bin/sh -c cargo build --target x86_64-alpine-linux-musl --release --locked]: exit code: 101

For context the base image was Alpine Linux 3.13.x with cargo installed using RUN apk add rust cargo which installed packages with version (1.47.0-r2). The docs for the Cargo setting are at https://doc.rust-lang.org/cargo/reference/config.html#httpmultiplexing.

danieleades commented 3 years ago

seeing loads of failing github actions in the last day or so due to these network issues

jiguantong commented 3 years ago

My situation is because my git proxy is configured, and I temporarily turned off the git proxy to fix it.

git config --global --unset http.proxy  
git config --global --unset https.proxy
TheFern2 commented 3 years ago

Solution that worked for me was updating my /etc/hosts file with new IP addresses for GitHub.

This worked for me too. Such of pain working behind corporate networks.

Edit: I also had to run a vpn.

diligentaf commented 2 years ago

None of the solutions fixed my issues.

ysiivan commented 2 years ago

In a corp net. First, the windows crypto (apparently being used by cargo) wanted to check the cert revocation, which our MITM cert fails. After disabling the revocation check, started getting these.
Changing user agent didn't help. GitHub IP appears to resolve correct. Long story short - had to use a socks proxy outside of the corp network to get it working.

GBBx commented 2 years ago

Hi, I had a similar issue recently. cargo build failed with this spurious network error message. I figured out that it was trying to clone a git repository as git://.... I tried git clone git://... manually and it really failed, however, git clone https://... worked. I added 

[url "ssh://"]
    insteadOf = git://

to ~/.gitconfig as described here and then finally cargo worked, too.

vitcra commented 2 years ago

Hm interesting! So this probably isn't a firewall/antivirus issue if you've disabled all those and it still didn't work. It works on Windows though and not the WSL? What we use on Linux is far more bog-standard I think than the Windows implementation, so I'm surprised it wouldn't work there if it works on Windows... I wonder if that's a WSL bug?

In my case, while crates.io was resolving in WSL, static.crates.io was not. As a workaround, I have added the respective entry in /etc/hosts and this fixed cargo being able to download crates.

OxfordStreet commented 2 years ago

I had the same issue redently. Thank for@sikinmettugi 's inspiration. I had solved it by close my VPN proxy service. A word of warning: If you're using a VPN proxy software in mainland China, it may cause the same spurious network error. All you need to do is turn off the system proxy.

briteming commented 2 years ago

@weiby3 你好。 我也遇到这个问题，你解决该问题没有？ 我至今未能解决。能否给点提示？ 非常感谢你的回复

briteming commented 2 years ago

hello, every body: i set a proxy for cargo as follows: i take the project https://github.com/xutianyi1999/fubuki as an example.

git clone https://github.com/xutianyi1999/fubuki cd fubuki mkdir .cargo cd .cargo nano config.toml cat config.toml it shows: [build] rustflags = "-C target-cpu=native"

[net] retry = 2 # network retries git-fetch-with-cli = true

[http] debug = false # HTTP debugging proxy = "http://127.0.0.1:3080"

then, cd .. cargo build --release it shows:

Updating crates.io index error: failed to get aes as a dependency of package fubuki v0.4.2 (/Users/ym/fubuki)

Caused by: failed to load source for dependency aes

Caused by: Unable to update registry crates-io

Caused by: failed to fetch https://github.com/rust-lang/crates.io-index

Caused by: process didn't exit successfully: git fetch --force --update-head-ok 'https://github.com/rust-lang/crates.io-index' '+HEAD:refs/remotes/origin/HEAD' (exit status: 128) --- stderr fatal: write error: No space left on device fatal: index-pack failed

how to fix the errors? thank u very much.

here, 127.0.0.1:3080 is a http proxy on my mac os. i can set it to be my brower's proxy and my brower can normally visit the blocked websites such as youtube.com in china.

OxfordStreet commented 2 years ago

hello, every body: i set a proxy for cargo as follows: i take the project https://github.com/xutianyi1999/fubuki as an example.

git clone https://github.com/xutianyi1999/fubuki cd fubuki mkdir .cargo cd .cargo nano config.toml cat config.toml it shows: [build] rustflags = "-C target-cpu=native"

[net] retry = 2 # network retries git-fetch-with-cli = true

[http] debug = false # HTTP debugging proxy = "http://127.0.0.1:3080"

then, cd .. cargo build --release it shows:

Updating crates.io index error: failed to get aes as a dependency of package fubuki v0.4.2 (/Users/ym/fubuki)

Caused by: failed to load source for dependency aes

Caused by: Unable to update registry crates-io

Caused by: failed to fetch https://github.com/rust-lang/crates.io-index

Caused by: process didn't exit successfully: git fetch --force --update-head-ok 'https://github.com/rust-lang/crates.io-index' '+HEAD:refs/remotes/origin/HEAD' (exit status: 128) --- stderr fatal: write error: No space left on device fatal: index-pack failed

how to fix the errors? thank u very much.

here, 127.0.0.1:3080 is a http proxy on my mac os. i can set it to be my brower's proxy and my brower can normally visit the blocked websites such as youtube.com in china.

@weiby3 你好。 我也遇到这个问题，你解决该问题没有？ 我至今未能解决。能否给点提示？ 非常感谢你的回复

有没有开代理？ 如果开的话 把代理软件退出试试

weiby3 commented 2 years ago

@weiby3 你好。 我也遇到这个问题，你解决该问题没有？ 我至今未能解决。能否给点提示？ 非常感谢你的回复

@briteming 后面没事了，我也不知道怎么解决的

leberknecht commented 2 years ago

It would be very much appreciated If you could comment in english :)

briteming commented 2 years ago

now i fixed it. in china, we need to set a china source for the crates: cd $HOME/.cargo nano config cat config

it shows:

[net] retry = 2 # network retries git-fetch-with-cli = true

[source.crates-io] registry = "https://github.com/rust-lang/crates.io-index" replace-with = 'ustc'

[source.ustc] registry = "git://mirrors.ustc.edu.cn/crates.io-index"

cd /path/to/some-rust-project/ cargo build --release

then u are set.

hmvp commented 2 years ago

Yesterday i had the same issue which lead me to digg into the problem . I just wanted to point out @weiby3 @alexcrichton the possibility that this may happens when cargo try to write into cache folder and because:

1. you are working on docker container

2. you are working in a remote development ide (which use docker mostly)

3. the user you are using does not belong to sudo group

4. you had a different/weird installation which lead to a improper permissions on cache folder

and the user you work with won't have the required permissions under the cache folder i.e /usr/local/cargo/registry/cache (this would depends on you cargo installation).

For future reference. I had this happen when using the default Rust devcontainer as created by VSCode after I tried to add a RUN cargo install <program> to the Dockerfile. That command runs as root and in the devcontainers the default user is vscode. For some reason both users use the same cache and index folders and the added command resulted in improper permissions for the vscode user..

My workaround was adding USER vscode to the docker file before the RUN cargo install command

Rohmilchkaese commented 2 years ago

Possible solution for git bash users

Had the same issue, while trying to add rand = "0.8.3" as the rust-book instructs. I was getting the following error: failed to get `rand` as a dependency of package" `guessing_game v0.1.0`

Found a workaround online. Turns out i had to create the config file under ~/.cargo (wasn't created automatically) and add a network configuration.

  1. Add required configuration
#  config file: ~/.cargo/config.toml
[net]
git-fetch-with-cli = true
  1. Test if it works.

OS: Windows 10 cargo: 1.53.0 (4369396 2021-04-27) rustc: 1.53.0 (53cb7b09b 2021-06-17) git: 2.31.1.windows.1

This was the fix for me! Thank you very much. I experienced the problems when building with Docker (Alpine Base). It was a cross ARCH build. Interestingly when I was build native there was not an issue. If anyone points that into a direction that helps.

Thesoul20 commented 2 years ago

now i fixed it. in china, we need to set a china source for the crates: cd $HOME/.cargo nano config cat config

it shows:

[net] retry = 2 # network retries git-fetch-with-cli = true

[source.crates-io] registry = "https://github.com/rust-lang/crates.io-index" replace-with = 'ustc'

[source.ustc] registry = "git://mirrors.ustc.edu.cn/crates.io-index"

cd /path/to/some-rust-project/ cargo build --release

then u are set.

This worked for me. But in the $HOME/.cargo directory, i have create a file named config.toml and write those command in the file. OS: ubuntu 20.04 China.

gingdotgithub commented 1 year ago

not sure exactly what finally did it for me, but i plugged my laptop into ethernet and it worked fine first time after that. i wonder if its packet loss on the streams over my wifi. try it somewhere reliable and fast...

rikonaka commented 1 year ago

My situation is because my git proxy is configured, and I temporarily turned off the git proxy to fix it.

git config --global --unset http.proxy  
git config --global --unset https.proxy

It's save my life. 😘

asears commented 1 year ago

It's amazing this is still open in 2023! My fix was to allow the crate.exe through Windows Defender Firewall.

In my case I am setting up a new rust-up cargo install on a Windows 10 machine with latest git cli installed. I used the 64-bit Windows installer from the downloads page because the chocolatey installer appeared out of date with 1.25.1 instead of 1.25.2 and flagged with some scan warnings.

https://community.chocolatey.org/packages/rustup.install

Was testing the setup using the examples crate.

cargo install mdbook --vv

The --vv command didn't show any additional details.

Windows Firewall was not blocking the git client and was able to run both the inbuilt cargo git and use git cli git fetch options.

This worked fine both inside and outside of cargo, turning on and off the git fetch with cli option. Note the newer gh cli might be a good option to add to the list.

git fetch --force --update-head-ok https://github.com/rust-lang/crates.io-index +HEAD:refs/remotes/origin/HEAD -v

It was not the git step which was failing, it was the accessing of crates.io URL via a dynamic 6xxxx port.

Tested with curl and got following error

curl -vvv https://crates.io/api/v1/crates/mdbook/0.4.26/download

curl: (7) Failed to connect to crates.io port 443: Bad access

Allow an app through Windows Firewall might work, though I went the port route. https://support.microsoft.com/en-us/windows/risks-of-allowing-apps-through-windows-defender-firewall-654559af-3f54-3dcf-349f-71ccd90bcc5c

I am using Malwarebytes Windows Firewall which added this pretty broad rule: %USERPROFILE%.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\crate.exe Allow Out Local ports: Any Remote addresses: Any Remote Ports: Any Protocol: Any

Adding add rule to Windows Defender Firewall to the Windows installer or finding alternative approach might solve this particular issue.

williamdes commented 1 year ago

The only workaround that worked for me on my Dockerfile was

ENV CARGO_NET_GIT_FETCH_WITH_CLI=true

I tried all other workarounds but they did not work Commit : https://github.com/sudo-bot/docker-rustpython/commit/283fdda7f5f01aa111683d541f77bc965f1b10e2

Create-Peace commented 1 year ago

Hi, I had a similar issue recently. cargo build failed with this spurious network error message. I figured out that it was trying to clone a git repository as git://.... I tried git clone git://... manually and it really failed, however, git clone https://... worked. I added

[url "ssh://"]
    insteadOf = git://

to ~/.gitconfig as described here and then finally cargo worked, too.

Thannks. It works.

randall-coding commented 1 year ago 
#  config file: ~/.cargo/config.toml
[net]
git-fetch-with-cli = true
  1. Test if it works.

OS: Windows 10 cargo: 1.53.0 (4369396 2021-04-27) rustc: 1.53.0 (53cb7b09b 2021-06-17) git: 2.31.1.windows.1

This was the fix for me! Thank you very much. I experienced the problems when building with Docker (Alpine Base). It was a cross ARCH build. Interestingly when I was build native there was not an issue. If anyone points that into a direction that helps.

That solution helped me get through the initial download issue (listed by OP). But now it fails with "Peer certificate cannot be authenticated with given CA certificates (SSL certificate problem: certificate has expired)" on https://crates.io/api/v1/adler/1.0.2/download

MacOS 10.14.5 Cargo 1.70.0-nightly Firewall is off.

I have 0 issues with this on Windows or Linux, but for some reason MacOS can't build.

UPDATE: Calling cargo run multiple times resolves the new ssl issue. https://github.com/rust-lang/cargo/issues/11670 Still strange, and would be nice if that wasn't required.

jaques-sam commented 1 year ago

This happens to me as well with a clean WSL Debian installation. First got it together with a Read-only file system; error upon rust installation. This worked again after shutting down WSL and try again. Now I get the same for cargo install upon downloading the crates.io index.

samja@TLV-TCS-C-SJ:/mnt/c/Users/C_SJ$ cargo install cargo-deb cargo-audit toml-cli ; rustup component add clippy rustfmt
    Updating crates.io index
warning: spurious network error (2 tries remaining): failed to create locked file '/home/samja/.cargo/registry/index/github.com-1ecc6299db9ec823/.git/objects/pack/pack_git2_986700b47da4idx.lock': Read-only file system; class=Os (2)
warning: spurious network error (1 tries remaining): failed to create temporary file '/home/samja/.cargo/registry/index/github.com-1ecc6299db9ec823/.git/objects/pack/pack_git2_c134288f68f3f534': Read-only file system; class=Os (2)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to create temporary file '/home/samja/.cargo/registry/index/github.com-1ecc6299db9ec823/.git/objects/pack/pack_git2_ec833f83de951fc7': Read-only file system; class=Os (2)
Bus error
Bus error

The command seems to corrupt WSL's filesystem completely, even got -bash: rm: command not found after running cargo install :-o

vsTianhao commented 1 year ago

I also have this problem without using any proxy

$ cargo run --verbose
    Updating crates.io index
warning: spurious network error (2 tries remaining): failed to send request: A connection with the server could not be established
; class=Os (2)
warning: spurious network error (1 tries remaining): failed to send request: A connection with the server could not be established
; class=Os (2)
error: failed to get `serde` as a dependency of package `tauri-app v0.0.0 (demo\tauri-app\src-tauri)`

Caused by:
  failed to load source for dependency `serde`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to send request: A connection with the server could not be established
  ; class=Os (2)
helloninglei commented 1 year ago
image

i also meet this problem , and the version is 1.70.0

rustup 1.26.0 (5af9b9484 2023-04-05) info: This is the version for the rustup toolchain manager, not the rustc compiler. info: The currently activerustcversion isrustc 1.70.0 (90c541806 2023-05-31)`

then i fixed it by update version to 1.68.0 rustup install 1.68.0 && rustup default 1.68.0

ooooooops commented 1 year ago

@weiby3 你好。 我也遇到这个问题，你解决该问题没有？ 我至今未能解决。能否给点提示？ 非常感谢你的回复

@briteming 后面没事了，我也不知道怎么解决的

我是把网断了重连就好了

Hongqin-Li commented 1 year ago

Hi, I had a similar issue recently. cargo build failed with this spurious network error message. I figured out that it was trying to clone a git repository as git://.... I tried git clone git://... manually and it really failed, however, git clone https://... worked. I added

[url "ssh://"]
    insteadOf = git://

to ~/.gitconfig as described here and then finally cargo worked, too.

Thannks. It works.

I use a similar solution with an additional "git@github.com" (for accessing private repo on github). It seems like the daemon service of git protocol doesn't work well with my proxy.

$ cat ~/.cargo/config.toml
[net]
git-fetch-with-cli = true

$ cat ~/.gitconfig
[url "ssh://git@github.com"]
    insteadOf = git://github.com