Skip to content

Out of space behaviour can be improved #330

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vi opened this issue Apr 17, 2016 · 13 comments
Closed

Out of space behaviour can be improved #330

vi opened this issue Apr 17, 2016 · 13 comments

Comments

@vi
Copy link

vi commented Apr 17, 2016

Tried running rustup.rs's installer with 200M limit on $HOME:

Continue? (Y/n) y

info: syncing channel updates for 'stable-i686-unknown-linux-gnu'
info: downloading component 'rustc'
41.64 MiB / 41.64 MiB (100.00%) 444.80 KiB/s ETA: 0s                 
info: downloading component 'rust-std'
54.73 MiB / 54.73 MiB (100.00%) 534.40 KiB/s ETA: 0s                 
info: downloading component 'rust-docs'
5.88 MiB / 5.88 MiB (100.00%) 774.40 KiB/s ETA: 0s                  
info: downloading component 'cargo'
3.62 MiB / 3.62 MiB (100.00%) 594.71 KiB/s ETA: 0s                  
info: installing component 'rustc'
info: rolling back changes
error: could not copy file from '/home/vi/home/rust2/.multirust/tmp/au245chz58q1gy9q_dir/rustc/lib/librustc-4fda350b.so' to '/home/vi/home/rust2/.multirust/toolchains/stable-i686-unknown-linux-gnu/lib/librustc-4fda350b.so' (No space left on device (os error 28))

I think installer should check for free disk space and warn user before continuing.

P.S. Why the file is copied, not moved or linked BTW?

@brson
Copy link
Contributor

brson commented Apr 19, 2016

Related to #275

There's not a great reason these files are copied and not moved, though it's important that the installation code does not assume that the temporary directory is on the same mount point as the destination. I don't know offhand if there are gotchas moving files across mount points.

@ghost
Copy link

ghost commented Oct 19, 2016

I just did a normal rustup update and it took me a while to figure out the error was due to not having enough free space, since the errors don't make mention of this. I tried it twice, and it failed slightly differently:

bram@durian% rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
 45.4 MiB /  45.4 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 42.1 MiB /  58.2 MiB ( 72 %)   6.0 MiB/s ETA:   3 s                error: component download failed for rust-std-x86_64-unknown-linux-gnu
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
 43.4 MiB /  92 B (49453995 %)   6.0 MiB/s ETA:  -7 s                
info: downloading component 'rustc'
 37.1 MiB /  37.1 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 44.5 MiB /  44.5 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'rust-docs'
  6.1 MiB /   9.3 MiB ( 66 %)   0 B/s ETA: Unknown                error: component download failed for rust-docs-x86_64-unknown-linux-gnu
info: checking for self-updates
info: downloading self-update

   stable-x86_64-unknown-linux-gnu update failed - rustc 1.10.0 (cfcb716cf 2016-07-03)
  nightly-x86_64-unknown-linux-gnu update failed - rustc 1.12.0-nightly (1bf5fa326 2016-08-16)

bram@durian% rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
 45.4 MiB /  45.4 MiB (100 %)   6.0 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 48.7 MiB /  58.2 MiB ( 84 %)   6.1 MiB/s ETA:   2 s                error: component download failed for rust-std-x86_64-unknown-linux-gnu
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
 50.8 MiB /  92 B (57870221 %)   6.1 MiB/s ETA:  -8 s                
info: downloading component 'rustc'
 37.1 MiB /  37.1 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 44.5 MiB /  44.5 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'rust-docs'
  9.3 MiB /   9.3 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'cargo'
info: installing component 'rustc'
info: rolling back changes
error: failed to extract package
info: checking for self-updates

   stable-x86_64-unknown-linux-gnu update failed - rustc 1.10.0 (cfcb716cf 2016-07-03)
  nightly-x86_64-unknown-linux-gnu update failed - rustc 1.12.0-nightly (1bf5fa326 2016-08-16)

bram@durian% df -h
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4  457G  433G   95M 100% /
/dev/sda1      vfat  487M   26M  461M   6% /boot/efi

Note that both times the download calculation is corrupted: 43.4 MiB / 92 B (49453995 %) 6.0 MiB/s ETA: -7 s. Is this also due to no free space?

EDIT: Forgot to mention that after making space, everything upgrades fine:

bram@durian% df -h
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4  457G  429G  4.3G 100% /
/dev/sda1      vfat  487M   26M  461M   6% /boot/efi
bram@durian% rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
 45.4 MiB /  45.4 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 58.2 MiB /  58.2 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'rust-docs'
  7.4 MiB /   7.4 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'cargo'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'rust-docs'
info: installing component 'cargo'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
 37.1 MiB /  37.1 MiB (100 %)   6.0 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 44.5 MiB /  44.5 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'rust-docs'
  9.3 MiB /   9.3 MiB (100 %)   6.1 MiB/s ETA:   0 s                
info: downloading component 'cargo'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'rust-docs'
info: installing component 'cargo'
info: checking for self-updates

   stable-x86_64-unknown-linux-gnu updated - rustc 1.12.0 (3191fbae9 2016-09-23)
  nightly-x86_64-unknown-linux-gnu updated - rustc 1.14.0-nightly (e0111758e 2016-10-17)

@clarfonthey
Copy link

Update on this, I keep getting even more unhelpful errors on the latest version: error: component download failed for rustc-x86_64-unknown-linux-gnu

@dbrgn
Copy link

dbrgn commented Jun 22, 2017

Same issue here. I was confused for a while.

$ rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256' to '/home/user/.rustup/tmp/zpfwsr85noo7uw___file'
info: syncing channel updates for '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/user/.rustup/tmp/e6izolmb6ko_aw8r_file'

   stable-x86_64-unknown-linux-gnu update failed - rustc 1.18.0 (03fc9d622 2017-06-06)
  nightly-x86_64-unknown-linux-gnu update failed - rustc 1.19.0-nightly (f062832b2 2017-06-07)

Maybe the actual error when downloading fails should be analyzed?

@jwarley
Copy link

jwarley commented Feb 5, 2018

Different but related problem for me. I just tried to install via rustup on a shared school computer with a 700mb/user quota. I didn't get any error messages at all: rustup appeared to download and install everything successfully. Uninstalling and reinstalling both rustup and the stable toolchain never produced any errors, however it appears that rustup ran out of space mid-install, as many files in ~/.rustup/toolchains/[target]/lib/rustlib/[target]/lib/ have zero size. This didn't manifest as a problem until I tried compiling something, at which point rustc simply reported that it couldn't find core.

I'm not sure exactly when in the installation it ran out, but hopefully the attached list of zero-size files in .../[target]/lib provides some indication?

rustup_zero_size_list.txt

@jakob-fischer
Copy link

I just run into a similar problem. (Or the same one still not handled.)
There seems to be a hint when unpacking fails because of full disk. But none when it happens while downloading:

info: downloading component 'rust-std'
info: downloading component 'cargo'
2.1 MiB / 6.0 MiB ( 35 %) 887.7 KiB/s in 2s ETA: 4s
info: retrying download for 'https://static.rust-lang.org/dist/2021-03-25/cargo-1.51.0-x86_64-unknown-linux-gnu.tar.xz'
2.1 MiB / 6.0 MiB ( 35 %) 937.4 KiB/s in 2s ETA: 4s
info: retrying download for 'https://static.rust-lang.org/dist/2021-03-25/cargo-1.51.0-x86_64-unknown-linux-gnu.tar.xz'
2.1 MiB / 6.0 MiB ( 36 %) 868.6 KiB/s in 3s ETA: 4s

I first thought I was having a bad connection and took a while to find the actual problem.

@suvayu
Copy link

suvayu commented Oct 15, 2021

I don't know if this is the right issue to report, but I get the exact same error, but I have plenty of space!

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
...
info: profile set to 'default'
info: setting default host triple to x86_64-unknown-linux-gnu
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2021-09-09, rust version 1.55.0 (c8dfcfe04 2021-09-06)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
 17.0 MiB /  17.0 MiB (100 %)   8.2 MiB/s in  2s ETA:  0s
info: downloading component 'rust-std'
 22.3 MiB /  22.3 MiB (100 %)   8.0 MiB/s in  2s ETA:  0s
info: downloading component 'rustc'
 51.0 MiB /  51.0 MiB (100 %)   8.0 MiB/s in  6s ETA:  0s
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-docs'
info: rolling back changes
error: failed to extract package (perhaps you ran out of disk space?): Bad address (os error 14)
$ df -h /home/
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  930G  322G  609G  35% /home

I was having this issue when I tried to update. Then I nuked everything under ~/.rustup and ~/.cargo to start afresh. But the fresh attempt also led to same issue.

I'm on Fedora, and my file system is btrfs, in case that matters.

$ uname -r
5.14.11-200.fc34.x86_64
$ btrfs version 
btrfs-progs v5.14.2

@vi
Copy link
Author

vi commented Oct 16, 2021

@suvayu I expect this "perhaps you ran out of disk space?" to appear just because of std::io::ErrorKind::StorageFull was not added when rustup was created, so it assumed any ErrorKind::Other (or just unhandled cases) mean "storage full".

Actual error is "Bad address (os error 14)" - not a typical error to come from a filesystem. Maybe you should check dmesg output for anything suspicious. Filesystem may be not in a good shape, you may want to check it.

@suvayu
Copy link

suvayu commented Oct 16, 2021

@vi Thanks, that helped. I have been having some stability problems on this machine. I was logged in remotely, Looks like there was a kernel panic. Rustup worked fine after I rebooted the system.

@iaverypadberg
Copy link

I ran into this issue recently while using the rustup default stable command on my coral devboard. dh -h showed that I had 2gb/7gb of free space. I've concluded that that is not enough space to make this work. Unfortunate but I guess the error was right.

@djc
Copy link
Contributor

djc commented Dec 11, 2023

I think the behavior has probably improved quite a bit since this issue was filed (in 2016), so I'm going to close this. Please feel free to file new issues if run into a concrete situation where you think rustup can/should do better.

@djc djc closed this as not planned Won't fix, can't repro, duplicate, stale Dec 11, 2023
@clarfonthey
Copy link

FWIW @djc, since the reason for closing is that the behaviour was improved, it makes more sense to mark this as completed rather than not planned. I did a double-take in my notifications since the marking made it seem like the response was "we shouldn't improve this behaviour, actually" rather than "we probably already did, file an issue if you have any specific problems still"

@djc djc closed this as completed Dec 12, 2023
@djc
Copy link
Contributor

djc commented Dec 12, 2023

@clarfonthey fair enough!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants