RUSTC no output on WSL1

[bbulkow]

Hi!

This is not a report of the widely discussed RUSTUP issues last year on WSL1.

I am recently new to rust, and a big user of WSL. Rust installs according to the standard means just fine on WSL1 and WSL2, Ubuntu 20 LTS.

However, simply running 'rustc' with no arguments (not trying to compile, not trying to update, nothing) results in perfect actions in my WSL2 environment, and no output at all in my WSL1 environment. rustc --version outputs... nothing.

rustc is 1.54.0 stable, Windows is Win 11 beta as of 9/8/21 (can dredge up exact latest KB applied). WSL is Ubuntu 20 from the app store, but run in WSL1 mode. uname is: Linux SUPERFLY 4.4.0-22000-Microsoft #1-Microsoft Fri Jun 04 16:28:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux Hardware is a Dell XPS 17.

All my usual tests of the WSL1 install work fine (my embedded toolchain, python), the same exact install path in WSL2 of rust works fine.

This happened in two different installs, one fresh, one not fresh (long story). The fresh install is fairly minimal (required compilers but not all the cruft I've accumulated in prior installs.... you know how it goes :-)....)

Please let me know what further information I can provide.

There are no backtraces or panic, just no output, which rather limits most standard bug reports. Even 'rustc --version' emits silence. Doesn't hang - the command returns promptly - but outputs literally nothing.

Background:

You might ask why I'm using WSL1. In other testing (ESP-IDF compiles for ESP32), I found that WSL1 was nearly 10x faster for compiling embedded projects. This is because NTFS is faster, much faster, because WSL1 isn't running through Linux's NTFS system. I want/need to use NTFS files because the point is I need my editing tools to work. And, WSL1 gives access to the serial port, drop dead necessary for embedded programming as well. But, WSL2 now has graphics, and I would like to test its compile speed, so I have both installed. I might end up using WSL2 more if I can sort the serial issue, and WSL2 does work with Rust, but I think WSL1 is unfairly maligned because it has a lower number - this causes me to like to help make WSL1 work :-)

Soapbox - WSL1 is closer to the true promise of WSL - it's a command shell for windows and doesn't bring along its own requirements for file systems or anything else - which does expose "edges" like dd not working and no real path to graphics working. WSL2 is much closer to a docker container, works best on its own local files, but it doesn't have the manageability or ecosystem or cross-platform nature of Docker. WSL keeps improving, I see WSL1 and WSL2 are now exporting their local file systems into the main Windows area, so some of these reasons are vanishing, but I find WSL1 fills a critical desire in my development environment at the moment.

Powershell 7 works great with rust on this same machine, and is super fast. I'm using that more substantially now, regardless of the lousy '.exe' required all over the place.

[workingjubilee]

This may actually still be a Rustup problem, somehow, because I assume by "standard means" you mean Rustup, and Rustup tries to proxy things... could you run strace rustc --version?

Regarding WSL, I would like to offer my (limited) understanding, without judgement of your needs (and my apologies if you already know all this):
WSL, regardless of version, promises to answer Linux syscalls. For WSL1, this uses Windows API calls, which are handled by the NT kernel. Eventually this was found... challenging because of the different API surface the two kernels offer. It would require defining the NT kernel in terms of Linux, essentially. So they introduced the Virtual Machine Platform (often referred to as Hyper-V, since it is mostly a subset of that) and thus WSL2 was born. So you are correct that WSL2 is more like a Docker container on Windows, where it introduces a virtualized Linux kernel. Docker does not necessarily need a kernel on Linux because it can use Linux Containers, using the existing Linux kernel.

The two WSL platforms are essentially different species, as you noted. I am not sure about what editing tools you are referring to, as files can normally be transferred between filesystems (governed by OS, anyways) without breaking. I must admit I would not be surprised if WSL2 could handle an ext4 filesystem more directly, competently, and quickly... at least one WSL developer suggests working in an ext4 root in a related bug.

[bbulkow]

"well, that's interesting"

re: philosophy of WSL, I still think it's reasonable, until windows really understands "containerized data", to have NTFS as my core file system, use editors in the Windows graphical environment on those files, and my different "containers" / command shells access the same store. When I do that, WSL1 is 10x faster than WSL2. Or at least was using the ESP-IDF toolchain (llvm based) about 6 months ago, and I was looking forward to seeing if there were differences still, and in rust - and could be compared against Powershell execution. Such different code paths all around.

So, I did the strace and had the output, and I noticed a lot of "command not supported" errors to the statx call. I then looked at the difference between WSL1 and WSL1 ~/.rustup directories, and WSL1 was very incomplete. So slightly before hitting Post I decided to rm the ~/.rustup and try again. That would mean 1.55 because that's today and 1.54 was so Tuesday, yknow?

Now, every time I run the standard curl rustup incantation on WSL1, I get a full windows kernel panic Green Screen Of Death. 100% of the time. I have now automagically sent 3 different GSOD dumps to microsoft so hopefully they're on the issue :-)

Clearly no user program should generate a GSOD so Rust is not the problem and this can be closed.

And I lost the strace output because I had just pasted it, and can't generate it again b/c GSOD.

For future reference:
Microsoft Windows [Version 10.0.22000.176]
which is:
2021-08 Cumulative Update for Windows 11 for x64-based Systems (KB5006050)
and that includes:
Windows Subsystem for Linux Update - 5.10.43

Fun, no?

Sometime today, it looks like KB5005642 patch was released, I'll update this in a sec with the result of that.
Same GSOD. Looks like my enjoyment of WSL1 might be coming to a close.

[workingjubilee]

...Alas!

Yes, since, at the moment, there seems to be no rustc issue per se, I am going to close this issue. Feel free to reopen it or open a new issue if more data comes in that can be addressed, er, at a level below the kernels in question. For what it is worth, the Linux 5.15 kernel will include a new, much more capable NTFS driver, which will be released sometime later this year, so you have that much to look forward to.

[bbulkow]

KB5005635 : still GSOD with WSL1 .

[bbulkow]

Another update of the WIndows kernel: and still the kernel crashes with a rustup.