Skip to content
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

[WSL2] "rustup update" causes "getrandom not ready" when run on initial VM boot #4416

brion opened this issue Aug 17, 2019 · 3 comments


Copy link

commented Aug 17, 2019

  • Your Windows build number: (Type ver at a Windows Command Prompt)

  • 10.0.18963.1000

  • What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

Running Rust programming language environment's "rustup update" command immediately on first boot of a WSL2 environment, either by typing into the terminal during bootup or by running directly as a command:

C:\Users\brion>wsl --shutdown

C:\Users\brion>ubuntu run /home/brion/.cargo/bin/rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
thread 'main' panicked at 'could not initialize thread_rng: All entropy sources failed (permanently unavailable); cause: getrandom not ready (not ready yet); cause: Resource temporarily unavailable (os error 11)', /cargo/registry/src/
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
  • What's wrong / what should be happening instead:

Command should run to completion, checking for toolchain updates and installing them if necessary. It runs fine if run a few seconds after the VM boots, just not immediately.

  • Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).


This comment has been minimized.

Copy link

commented Aug 28, 2019

There are no repro steps here but it looks like you are hitting variation this and this, which I guess triggers on WSL2 as well. There is no reason to expect /dev/random to have a particular number of bytes available. You'll get the same behavior on Real Linux too if you exhaust the entropy (say something else eats it all).


This comment has been minimized.

Copy link

commented Sep 24, 2019

Added more boot entropy in 18990.


This comment has been minimized.

Copy link

commented Sep 25, 2019

Can confirm that in build 18990 I no longer get the low-entropy panic from rustup called in this way. (The command eventually does fail in a different way, but I'll track that down separately if it continues...) Thanks for the update!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.