rustup: rustup panics with WSLv1 + glibc 2.31
Panics like:
info: installing component 'rust-std' for 'wasm32-wasi'
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `22`,
right: `4`', src/libstd/sys/unix/thread.rs:166:21
stack backtrace:
0: 0x7fad0b4dbc9c - backtrace::backtrace::libunwind::trace::h65597d255cb1398b
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
1: 0x7fad0b4dbc9c - backtrace::backtrace::trace_unsynchronized::hd4f479d7150ec4a0
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
2: 0x7fad0b4dbc9c - std::sys_common::backtrace::_print_fmt::h015072984a2b172c
Are caused by WSLv1 + glibc 2.31 which changed the implementation of nanosleep to depend on a different kernel codepath.
Verification:
- WSLv1 can be confirmed using the wsl command:
wsl --list --verbose
If --verbose is not supported, then WSL v2 is not installed on the machine.
If verbose is supported, the version of WSL being used for each WSL instance will be reported against the name of the instance.
Workarounds:
- use older linux versions
- some users report that exporting RUSTUP_IO_THREADS=1 mitigates the problem
- use WSLv2
=====
Performing rustup update on WSL1 results in panic:
info: syncing channel updates for ‘stable-x86_64-unknown-linux-gnu’ info: latest update on 2020-02-27, rust version 1.41.1 (f3e1a954d 2020-02-24)

Windows 10 Pro, 1909, OS Build 18363.657
Previous updates using rustup worked without problems
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 7
- Comments: 19 (6 by maintainers)
I accidentally discovered that
RUSTUP_IO_THREADS=1fixes things for me in WSL 1! (I thought I was ssh-ed into raspberry pi 🤦)I’d move to WSL2, but for some reason my desktop isn’t eligible for the update yet 🤷♂️
@leth
Confirmed. Great tip! Win 10 1909 OS 18363.836 WSL 1.
Since I had existing Ubuntu installed with WSL 1. And after updating WSL 1 to WSL2 I had to do below fix. And it works now
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shThis affects Arch Linux installation on WSL. The solution is to downgrade glibc:
https://github.com/paritytech/subport/issues/27#issuecomment-670586387
For
WSL1add this to the .bash_profile or .bashrc, works for meJust did a rustup self update + rustup update in a WSL 1 instance, no issues.
So I don’t think this is WSL1 per se causing the problem. Is it reproducible?