WSL2: Ubuntu 18.04 Serial devices are no longer mounted properly

[david-dumke]

• Your Windows build number: Microsoft Windows [Version 10.0.18932.1000]

• What you're doing and what's happening:

  1. run WSL2 Ubuntu 18.04
  2. plugin USB to serial device
  3. watch it mount under COM devices in device manager
  4. attempt to open the device in WSL2
  5. cat /dev/ttyS[X]

• What's wrong / what should be happening instead: This works under WSL1 flawlessy, it no longer works in WSL2 in WSL2 we can clearly see it is not connected or configured /dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3

[rubberduck203]

It’s clearly called out in the FAQ that there is currently no support for USB in WSL2.

I’d like to toss my voice in here that this should be a priority feature for WSL2.

One of the big benefits of WSL2 is the opportunity to run Docker natively instead of on Docker for Windows. It is notoriously hard to get access to USB devices in Docker on non-Linux systems.

I commonly use Docker for creating tool-chain images, but this falls apart when you’re working with embedded devices, where you need to connect to a USB device or serial port in order to flash/debug on device. If I can run a docker container natively and access USB ports with WSL2, I can make an extremely strong argument for switching from Mac to Windows.

[linweifu]

up

[zawawimanja]

so that why I cannot see my usb device in ubuntu.hurmmm

[rubberduck203]

It would be really nice if someone could chime in letting us know if this is even technically feasible.

[sebbean]

would love to know

[chenhu66]

what a pity! i gotta roll back to wsl 1. Hopefully, usb support comes up soom for wsl2

[tleroy-dev]

what a pity! i gotta roll back to wsl 1. Hopefully, usb support comes up soom for wsl2

Can I have the detailed step to roll back from WSL2 to WSL1 ? I found under https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-18917 that WSL2 was introduced at build version 18917. Now, how can I re-install WSL from a specific build number ? Thank you.

EDIT my current build number is below 18917 and should be WSL1, right ? But the USB COM PORT is not recognized in WSL env.

My current os version:

PS C:\Users\nxf43719> [System.Environment]::OSVersion.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      17134  0

[rubberduck203]

I thought you could have WSL1 and WSL2 installed side by side?

[tleroy-dev]

@rubberduck203 it's not clear to me how to check which WSL version we are running. It is not described in the app store. From online information I have found:

We need to run Windows Build 16215 or later to install WSL 1.

WSL 2 is only available in Windows Builds 18917 or higher.

You can install both version if your build is higher than 18917. So in my case I am running a 17134 build, I should only have WSL1 available, correct ? In my case I still have troubles accessing serial USB device from my linux terminal under /dev/. They don't show up but are dettected in Windows Device Manager.

[bburky]

@tleroy-dev If your system supports WSL2, you can choose WSL1 or WSL2 per distro.

VERSION from wsl --list --verbose shows if you're using WSL1 or WSL 2:

> wsl --list --verbose
  NAME                   STATE           VERSION
* docker-desktop-data    Stopped         2
  docker-desktop         Stopped         2
  Ubuntu-18.04           Stopped         2
  Fedora-32              Stopped         2
  Ubuntu                 Stopped         1

The normal recommendation is to use WSL2 for installation of all new WSL distros. Note, this doesn't affect your current installed WSL distros, if you have any already they will stay on WSL1.

wsl --set-default-version 2

If you want to manually upgrade a distro to WSL2 or "downgrade" it to WSL1, you can use --set-version. I keep a WSL1 distro around to have functioning /dev/ttyS* devices.

wsl --set-version Ubuntu 1

[tleroy-dev]

@bburky Thanks for your response.

PS C:\Users\user> wsl --list --verbose
/bin/bash: --: invalid option

From that documentation, it looks like the wsl.exe command works only on build higher than 1903, older version use wslconfig.exe. Result of equivalent :

PS C:\Users\user> wslconfig.exe /list /all
Distributions du sous-système Windows pour Linux :
Ubuntu (par défaut)

It's in french in my case (system default), it does not output the version specifically, I guess from what I have described earlier, being on a pre-WSL2 build (17134) , only WSL 1 is enabled in my case.

[bburky]

@tleroy-dev Yes, sounds like you're definitely on WSL1 then.

[tleroy-dev]

I have opened a new ticket for my problem under WSL 1 (#5203)

[AsciiWolf]

Any news regarding USB devices support in WSL2?

[xklob]

Just upgraded to WSL2 for the native Docker integration, but frustrated that I can't continue to do Arduino development natively in WSL anymore without switching back and forth between WSL versions... any updates here?

[Ludorg]

Just upgraded to WSL2 for the native Docker integration, but frustrated that I can't continue to do Arduino development natively in WSL anymore without switching back and forth between WSL versions... any updates here?

Same frustation and same behavior here...

[GearWalker]

I'm also working with embedded system build environment, really need this too!

[kategray]

This is a huge blocker as well. Using WSL1 as a workaround, but there needs to be some way to get USB->Serial working on WSL2.

[all-chu]

Any updates on this? This is a showstopper for moving to WSL for embedded Linux development. There are issues with buildroot + WSL1 so that's not an option either.

[mkanet]

I guess I can forget about installing Home Assistant under WSL2 anytime soon. My HUSBZB-1-USB-HUB won't mount.

[ghost]

Another vote for this, being able to attach serial over usb embedded devices to my docker containers would be a game changer

[shambodeva]

Bummer! I was happy to setup WSL 2 & install Ubuntu to build my project on linux. However i couldn't flash or access the serial/COM USB port from WSL 2. This feature is a huge blocker. Can you pull-in the device access support from WSL 1 immediately?

[dattrax]

I could really do with this to flash an embedded serial device.

[mastrolinux]

Arduino CIO here, as Arduino, we would like to contribute in making this happen. Allowing developers to work with WSL and Arduino boards would be fanstastic. As of now, our arduino-cli inside WSL does not allow people to see the list of the boards. Mainly related to https://github.com/microsoft/WSL/issues/3099 and the closed one: https://github.com/microsoft/WSL/issues/1929. Thank you for your great work!

[TaDahCorp]

Another vote for USB-serial support, WSL2 was doing so well otherwise on first try...

[cduplantis]

I wanted to build and burn an custom raspberry image to a flash drive from a WSL2 session. My first test (writing the Raspberry Pi OS) using the dd utility to host USB ports, I found out that it is not possible. Please raise the priority of this. Thanks.

[pianocomposer321]

I have a workaround for Arduino at least:

I downloaded the arduino-cli and put the exe in the Program Files (x86)/Arduino folder, then added that folder to path. Then you can access the exe's from WSL (see https://docs.microsoft.com/en-us/windows/wsl/interop). You can run the command just as you would from windows. The only difference is that instead of just arduino-cli you have to append .exe, as in arduino-cli.exe.

So to create a new arduino project, I do the following:

cd ~/arduino-projects
arduino-cli.exe sketch new cli-test && cd cli-test

Then edit the .ino file with neovim:

nvim cli-test.ino

And finally compile and upload the sketch:

arduino-cli.exe compile --fqbn arduino:avr:mega ~/arduino-projects/cli-test
arduino-cli.exe upload -p COM4 --fqbn arduino:avr:mega ~/arduino-projects/cli-test

Note that using full path (~/arduino-projects/cli-test) rather than just . is important. If you just use . , (for reasons I don't understand), you will get an error:

avrdude: can't open input file build\arduino.avr.mega/..ino.hex: No such file or directory
avrdude: read from file 'build\arduino.avr.mega/..ino.hex' failed
Error during Upload: uploading error: uploading error: exit status 1

Also note that the last two commands could be run from inside (neo)vim with :!, in which case the command would look like this:

:!arduino-cli.exe compile --fqbn arduino:avr:mega %:p:h
:!arduino-cli.exe upload -p COM4 --fqbn arduino:avr:mega %:p:h

You could also add a mapping in your vimrc (or init.vim) for these commands, or add a makefile, or both.

HTH, pianocomposer321

[badcf00d]

This is very much a workaround, but I thought I'd share the what I've done for ESP32 development until WSL 2 has serial access in case it's useful to anyone. You could probably follow a similar approach for other microcontrollers.

The WSL 2 virtual drives are mounted as network drives in Windows at \\wsl$, so you can do your builds in WSL, and then open a powershell window in the WSL directory with your build. You can then write some powershell scripts to flash and monitor over your COM ports, for the esp32 this works fairly well thanks to the python scripts they provide from esptool and idf_monitor.py

flash.ps1

# Make sure you have python, and esptool installed (pip install esptool)
# Usage: flash.ps1 COM6 

esptool.py -b 1152000 -p $args[0] write_flash 0x1000 .\build\bootloader\bootloader.bin 0x8000 .\build\partitions_two_ota.bin 0x10000 .\build\esp32-binary.bin

monitor.ps1

# Usage: monitor.ps1 COM6 

python idf_monitor.py --baud 921600 --port $args[0] .\build\esp32-binary.elf

EDIT: As pointed out below instead of opening a separate powershell window, you can just run powershell scripts from within a WSL terminal by doing: powershell.exe ./monitor.ps1 COM6

[pianocomposer321]

@badcf00d Once the PowerShell scripts are written, you could probably even just run them from the wsl terminal, similarly to how you can run arduino-cli.exe from wsl.

[badcf00d]

@badcf00d Once the PowerShell scripts are written, you could probably even just run them from the wsl terminal, similarly to how you can run arduino-cli.exe from wsl.

Oh yeh, good point actually, that's much easier: powershell.exe ./monitor.ps1 COM6.

[pianocomposer321]

Or even put all the scripts in the same folder and add them to PATH (in windows, not wsl (I think)). That way you don't have to be in the same directory as the scripts when you run it.

[caowent]

sist_x64.zip

A better serial debugging tool is sisterm

1. Command line form
2. It is a native exe application built using rust
3. It supports custom syntax highlighting
4. It works well in windows terminal
5. If it is only for debugging the serial port, such as embedded development, it consumes less memory than wsl1.
6. The simple start command in powershell: sist -l com3 -s 1500000

[Matheus-Garbelini]

any updates on this?

[jimmyw]

Please have a look at this soon!

[imadjamil]

This is really a showstopper for WSL and should be given more attention!

[rhyek]

As a windows user traditionally, I've given WSL several chances for my work and I will say that it has gotten better over the years for sure. But there is always some detail with it or Windows in general with some workaround needed that messes with your work flow. The mental overhead of sometimes needing to switch or even consider to switch between WSL and Powershell contexts depending on what you're doing, the lack luster window and external display management compared to OSX, the uncomfortable keyboard shortcuts in general, now this USB issue. I value my time and so I will go back to my MacBook at least for now and try again in a year.

[pianocomposer321]

@rhyek I'm sure you've considered this already, but why not install Linux on your Windows laptop? With the right desktop environment, you can have just as good window management and just as good (or even identical) keyboard shortcuts as OSX.

[rdbisme]

@rhyek I'm sure you've considered this already, but why not install Linux on your Windows laptop? With the right desktop environment, you can have just as good window management and just as good (or even identical) keyboard shortcuts as OSX.

Well, Linux on a Windows laptop is a suboptimal solution at the very least IMHO.

• Battery Life: In my experience, a Laptop with generic drivers on Linux performs 30% worse than the same exact laptop with Windows installed.

• General compatibility. As an example I would bring the compatibility with Clickshare, to make presentations. Lots of corporate environments have it, but you can't use on Linux. ANother example is the Touchpad drivers that are very often extremely poor on Linux, making the experience extremely frustrating.

• Gaming: It's very annoying to reboot on a system every time you want to play a game.

WSL allows to work on Windows, having all the benefits of Windows world, but being able to switch on a fast Unix environment with a click.

At the contrary of @rhyek, for me the current WSL experience is good enough to legitimate the switch from macOS to Windows. That said, it would be great to have Serial Device compatibility back again.

[pianocomposer321]

@rubendibattista Those are some very interesting points. Not trying to start an argument, so please don't take this that way:

First of all, you mentioned battery life. I don't have that much experience with Linux when my laptop wasn't plugged in, but I never had any issues. I'm sure it differs from laptop to laptop, battery to battery, and likely distro to distro.

Next, when it comes to compatibility: There's a saying that goes "Anything that windows can do, Linux can do for free". Whatever program you are used to that doesn't run on Linux, there is a 99% chance that there is a free alternative that will. However, if you are a part of a team, and all of your teammates are running Windows machines, I can see why you might want to just keep it consistent. However, if you are "flying solo", this really isn't an issue.

For games, there are a number of factors involved here. First of all, gaming on Linux has gotten much, much better the last year or so, and there are distros (like Manjaro) made specifically for gaming. If you want something a little more versatile, Pop OS is a great choice too. It's based on Ubuntu and should provide a great gaming and programming experience. Also, if @rhyek isn't going to be programming on his windows machine anyway, then booting it up to play games really isn't that different than rebooting the same one. The gaming experience on OSX is just as bad (arguably worse) than gaming on Linux.

[cascornelissen]

@rhyek, @pianocomposer321, @rubendibattista; could you guys move this discussion somewhere else? I get the point and I agree but it's only slightly related to the original issue and I'm subscribed to email updates (just like 30+ other people) because I'm interested in when this gets fixed, not in the millionth OS discussion.

[pianocomposer321]

@cascornelissen Not sure where we would move it to, but that's ok, it's not really that important, and I apologize for getting the discussion so off track ;-). I just wanted to make sure @rhyek had considered the other options.

[mirchat]

Just to save some time please: are the serial devices mounted OK using Ubuntu 20 on WSL2 ?

[mastrolinux]

No, the issue is still present on Ubuntu 20. Not sure if we need to open another bug about it. @mirchat

[Matheus-Garbelini]

This is really sad as the whole Arduino, Platformio, Mbed, and firmware developers community benefits a lot from serial port over WSL2.

[f4grx]

Please make serial devices work in wsl2, this is a showstopper for embedded development on windows.

[ghost]

I would also like to express support for this feature. As an embedded developer, it's currently preventing me from using WSL2 in my workflow.

[abobija]

Any updates on this? My ESP32 waits impatiently to be flashed directly from WSL2 :disappointed_relieved:

[f4grx]

@abobija meanwhile you can use MSYS2 / MINGW64 with python installed to flash the esp32. just replace /mnt/drive by /drive and the --port by a real windows com port.

[abobija]

Thank you @f4grx I know, I already flash it like that, but I'm looking forward to flash it directly from wsl2, without any improvisations

[f4grx]

Same here, of course! it would be much easier. comm ports are a basic OS feature that should work from wsl.