Repository navigation
downloading rustc component fails often on WSL2 #4837
Description
Verification
- I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
- I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.
Problem
Rustup fails often when trying to download the rustc component, while downloading the file from the url in the error message using wget succeeds without problems.
Steps
- Install rustup
- attempt to install a toolchain
Possible Solution(s)
No response
Notes
Rustup on the Windows 11 host does not appear to have the same problem.
Curl on the WSL2 guest appears to have the same problem.
Rustup version
rustup 1.29.0 (28d1352db 2026-03-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: the currently active `rustc` version is `rustc 1.94.1 (e408947bf 2026-03-25)`Installed toolchains
Default host: x86_64-unknown-linux-gnu
rustup home: /home/bennet/.rustup
installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu (active, default)
beta-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu
1.83-x86_64-unknown-linux-gnu
1.85-x86_64-unknown-linux-gnu
1.92-x86_64-unknown-linux-gnu
1.93-x86_64-unknown-linux-gnu
active toolchain
----------------
name: stable-x86_64-unknown-linux-gnu
active because: it's the default toolchain
installed targets:
s390x-unknown-linux-gnu
x86_64-unknown-linux-gnuOS version
$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.4 LTS
Release: 24.04
Codename: noble
Under WSL2 on Windows 11
Activity
rami3l commentedon Apr 27, 2026
@Skgland Thanks for reporting!
If curl in your same environment has the same problem, this is very possibly a connection issue of your WSL2 environment...
Being a true VM instead of utilizing API forwarding like WSL1 does, I think it's more likely that WSL2 could have such problems.
Skgland commentedon Apr 28, 2026
Possibly, but wget in the same environment doesn't appear to have the same issue.
rami3l commentedon Apr 28, 2026
@Skgland Wget implicitly has
--tries=20set; you can try to set it to 0 and see...Skgland commentedon Apr 28, 2026
As 0 appears to mean infinite retries I tried it with 1 instead. I haven't seen a single failure in over 22 attempts (didn't keep count initially).
Curl failed in 13/22 attempts.
rami3l commentedon Apr 28, 2026
@Skgland Thanks for the quick response! Would you mind trying with
curl --http1.1in the same environment to see if this is a problem in the default HTTP version being used?Both we and cURL are using HTTP2 by default if that explains.Also, under Ubuntu 24.04.4 LTS the default wget version is v1 which doesn't support HTTP2 at all.Erratum: In our
curlbinding we see this feature set:... so without the
http2feature explicitly set, even high libcurl versions are not using http2 by default.Skgland commentedon Apr 28, 2026
I am not experiencing any failures with
curl --http1.1wget version
curl version
apt list --installed curl wget
[-]downloading rustc component fails often[/-][+]downloading rustc component fails often on WSL2[/+]rami3l commentedon Apr 28, 2026
@Skgland Okay. So if both rustup and curl is failing with HTTP2 you can give
wget2 --http2-onlya try.If all three programs (
rustup,curlandwget2) are failing reproducibly then you might have better changes seeing this with WSL 🙏Also @ChrisDenton I'm not sure if you have been using WSL a lot, but have you heard of anything like this?
I do have a vague impression of WSL2 VMs having a bad time communicating with the host machine when I sold my last PC in 2020...I think there might have been something that HTTP2 sessions do more aggressively than HTTP1.1 ones that has broken this, maybe it's multiplexing?Skgland commentedon Apr 28, 2026
Not seeing any issues with
wget2 --http2-only --tries=1wget2 version
Skgland commentedon Apr 28, 2026
BTW, I don't think I have mentioned this bit the error I am getting for curl is
curl: (56) Recv failure: Connection reset by peerrami3l commentedon Apr 28, 2026
Thanks for confirming that #4695 has indeed worked :)
rami3l commentedon Apr 28, 2026
@Skgland It's quite unfortunate I cannot debug it myself, but in that case it's reasonable to suspect that this is related to the MTU setup on WSL2. You can try with lower either the buffer size or the MTU and see if the interruptions happen less often. Something like:
curl --http2 --buffer-size 4096... or:
sudo ip link set dev eth0 mtu 1350Adjust the values according to your setup. Either way, this is more likely a problem with your network stack rather than with rustup.
Skgland commentedon Apr 28, 2026
My curl version does not recognize the
--buffer-sizeflagLowering the mtu to 1350 appeared to reduce the failure rate slightly, at mtu 1000 I no longer see errors (didn't try other steps inbetween).
This appears to be indeed a network issue with WSL2 on my side.
Thank you for your patience and help.
rami3l commentedon Apr 28, 2026
@Skgland My apologies, it seems the buffer size can only be set with the libcurl option but not with a CLI parameter.
Anyway, glad to see that the root cause of your issue has been identified!
Skgland commentedon Apr 28, 2026
I still find it a bit odd that it only effects http2 traffic of curl and rustup.
wget, curl with http1.1 and wget2 with http2 were working fine.
I now tried to use ping to find the largest usable MTU but that didn't have any problems even with the default MTU of 1500 (ping icmp payload of 1472 + 28 bytes package headers icmp + ip).
Over 100 ping packages it had a package loss of 2% both at an MTU of 1500 and 1000.
rami3l commentedon Apr 28, 2026
@Skgland It is possible that Wget2/GnuTLS has lower default max TLS record size so it will help in this issue. This is also why previously I mentioned reducing the buffer size.
Skgland commentedon Apr 28, 2026
I can no longer reproduce the problem even at the original/default MTU of 1500.