Install Rust Error

help
1

Hi! I've just registered here, because 1st I'd like to learn Rust, and 2nd I have an error while using the command to install Rust found on the Rust website: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh.

Here is the error message:

error: component download failed for rustc-x86_64-unknown-linux-gnu: could not download file from 'https://static.rust-lang.org/dist/2025-02-20/rustc-1.85.0-x86_64-unknown-linux-gnu.tar.xz' to '/home/stephane/.rustup/downloads/7436f13797475082cd87aa65547449e01659d6a810b4cd5f8aedc48bb9f89dfb.partial': error decoding response body: request or response body error: operation timed out

What's wrong? How can I fix that? Is there a workaround?

For any additional information that might be needed, please ask me.

Thanks in advance for any help and advice, and also thank for the existence of the community!

2 Likes
2

the error message indicates your internet connection to rust server is not reliable. make sure you have a good internet connection and try again later.

or, are you behind some kind of corporation firewall, or do you need special proxy settings to access the internet? if so, ask the IT support team in your organization.

3 Likes
3

Hi nerditation,thanks a lot, it confirms what I was suspecting: my network connection...
I'm simply using WI-FI, this explains that. It's frustrating. I'll have to wait to have a better connection, and that's it. In the meantime, I'm going to start reading the Rust Book, and also Rust By Examples.

Thanks again!

4

I had the same issue and the result was the same after many retries.
What worked for me is installing rustup via pacman and then running "rustup default stable". The same download now ended without issue.
But package managers aren't mantained as an instalation method, i think, so your mileage may vary.

1 Like
5

Thanks QuartzKnight, yes that's why I was reluctant to install rustup through dnf, for that reason; the Fedora Rust install page tells about that: Fedora Rust Install; and in that case (using Fedora package manager) I'll be stuck with an un-upgradable (*) version of rustup.

(*) The life cycle of Fedora releases is rather short, and after some times most of the packages do not have upgrades when a release reaches its support end.

Is it a problem then? Can I still upgrade Rust safely, without issue?

6

even if you cannot upgrade rustup itself, you can still manage rust toolchains with it (until in the future the distribution schema on the server were no longer compatible, that is), so you are probably fine for a decent period of time.

that being said, it is still preferable if you can use an up to date version. if, for some reason, your ISP had issues with the rust download server, which is hosted on AWS (CDN provided by cloudfront, IIRC), you can try to workaround it, e.g. by changing your DNS server, or using a VPN.

there's also another method to workaround connectivity issues, that is using an mirrored download server.

rustup can be configured to download from different servers by setting the env variable RUSTUP_DIST_SERVER, so organizations can mirror the download server or host custom built toolchains. but in various regions, people have been set up public unofficial mirror servers, because certain global CDN providers are blocked (or intefered). you can find more information if you google RUSTUP_DIST_SERVER and country names.

SECURITY WARNING:

if you use unofficial servers, make sure to verify the checksum of the downloaded file. at least, you need to ensure the channel manifests are not modified, you don't need to do it for all downloaded artifacts though, rustup will check them automatically.

for example, the manifest of the stable channel and its checksum can be found on the official server:

https://static.rust-lang.org/dist/channel-rust-stable.toml

https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256

1 Like
7

Thanks a lot for the insight and the help! I've never had any problem of this kind with my ISP.
That's strange.

I think I'm going to install Rust and rustup via my package manager, in last resort.

Thanks again, I appreciate a lot!

8

Hi there, you might be having similar issue as me as I stated here. If yes, not only that you need to change your internet connection, you have to be sure it's quite fast.

2 Likes
9

Good … ah well not “good” but … interesting to hear that there’s (at least) one scenario – fresh installs – where retrying perhaps doesn’t help. (Sorry for being not super helpful in this regard, but I’m a bit hesitant to nuke my own whole installation, because I have a lot…[1] of different stable versions installed and no desire to re-download them all :sweat_smile:.)

Maybe as a thing to try and rule out, you could test if it makes a difference if the download doesn’t fail with the timeout but you abort it manually (Ctrl+C) before that happens.[2] It’s not impossible that continuing the partial download could end up actually working then.

One thing to maybe try out is to use an older version:

Documented here are the relevant URLs

To get a previous version, use https://static.rust-lang.org/rustup/archive/{rustup-version}/{target-triple}/rustup-init[.exe].

And here {rustup-version} would be 1.27.1 (from the changelog, appears to be the last release before the new 1.28.0) – and the target-triple is visible in the error message, e.g. for @Stephane that’d be x86_64-unknown-linux-gnu; so https://static.rust-lang.org/rustup/archive/1.27.1/x86_64-unknown-linux-gnu/rustup-init.

And here is some documentation about self-updates. Apparently it can be disabled e.g. via rustup set auto-self-update disable. (I’m not sure if rustup-init itself would already try to make a self-update though…).

Once the fix with 1.28.1 would be released (which hopefully/presumably happens within the next 24h), this setting can then be set enabled again.

  1. arguably, one could even say I have all of them ↩︎

  2. At least Ctrl+C aborting for rustup update … a bit of a different setting, admitted … was a case where I was able to validate that for me it does resume an aborted download from where it stopped ↩︎

1 Like
10

Thanks a lot for the answer and the help, and the links! With all these trails to follow, I should be able to get a usable installation of Rust, finally... I hope so at least.

11

Thanks for your answer too! As suggested here and in your thread, I think I'm going to wait for a fix; I have no possibility to change my internet connection, so... either I try a workaround, or I wait.
I'm not in a hurry, I have a lot to do else where (some projects in other languages for example), and even if I'm really wanting to learn Rust, I can patiently wait; as I said in another reply, starting to read the Rust Book, as well as Rust By Example, is a good thing to do in the meantime.
And since I start from zero in Rust, it's clear in my head that, no matter what, it's going to be a medium/long (but rather long) term journey.

12

No need to wait, the fix is already out for >20h :wink:

2 Likes
13

That's a sweet news! Thanks! I'm going to try the install right now! :face_with_tongue:

EDIT

Install: done!

The installer said:

stable-x86_64-unknown-linux-gnu installed - rustc 1.85.0 (4d91de4e4 2025-02-17)

Rust is installed now. Great!

It added . "$HOME/.cargo/env" in my .bashrc, my .bash_profile, and my .profile...
I think one in my .bashrc is enough`.

Anyway, I've done . ~/.cargo/env, and rustc --version returns:

rustc 1.85.0 (4d91de4e4 2025-02-17)

And rustup --version version returns:

rustup 1.28.1 (f9edccde0 2025-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.85.0 (4d91de4e4 2025-02-17)

I assume all is up to date...

14

.profile is useful to support sh as a shell as it’s the only startup file[1] that it knows. .bashrc is important as it’s the only sourced file for interactive non-login shells in bash. And .bash_profile – if it exists – is the only startup file[2] sourced by bash for login shells – though conventionally this file usually also loads .bashrc, it doesn’t really hurt either:

That’s because the script in $HOME/.cargo/env makes sure to stay idempotent, i.e. only add adds $HOME/.cargo/bin to $PATH if it isn’t part of $PATH already.

  1. in the home directory ↩︎

  2. in the home directory ↩︎

1 Like
15

nowadays, I use ~/.config/environment.d/ for most of my env variables.

although I'm mostly a bash user, sometimes, I wanted to try out the new shiny shells too, but I cannot bother to remember the syntax for every shell's startup scripts.

I know many people don't like systemd. it works great for me.

1 Like
16

Thanks, that's good to know, and useful!

17

Same for me, I've been attracted by these shiny new shells as you say, but I stick to the bass, sorry: to the bash powa :slight_smile:

About environment.d, is it a standard practice or something you've designed for your use case?
I'm also fine with systemd by the way.

P.S.: Speaking of bass, it made me think of this song -> Jump Up Pon It.

18

files under environment.d are configuration files used by the systemd environment-d generator.

config files there will be read and used to set the environment block for the user service manager, which is passed to all services started by it, this usually affects the entire desktop workspace.

this doesn't work if you login on the virtual console, though, since your login shell is spawn directly by login instead of the systemd user instance, but I rarely login from the console directly, and I can always do one liner in case I needed these variables:

eval $(systemctl --user show-environment | sed 's/^/export /')

side note:

technically, these generators are used to setup environment for "services", but there's not much "real" services in the user slice, and most "services" there are related to desktop environment. it is just convenient the desktop login manager is such a service, so I can use it to setup the "global" environment for the entire desktop. ("global", as opposed to the environment "local" to a single shell session set by the shell startup script).

when you launch a shell, these service environment variables are set before the shell process is spawned, and variables can be overwritten, so check the shell profile or scripts (e.g. the distro's /etc/profile) if some variable appeared to be not setup correctly.

19

Sorry for the late reply, I've too busy... Thanks for your message, that's very interesting; actually I've never deep dived in systemd, and btw it's the first time I hear about systemd environment-d generator, and what you're telling about it seems interesting, I'll have a look at the documentation, maybe I'll find something useful for particular needs.
Thanks for your answer and for explaining these things to me, it's very much appreciated! :+1: