Block devices, (i.e. /dev/sda) ?

[ScarFez]

Is there any ETA on when we can see block devices such as sda, for tools like hdparm ?

Thanks

[sunilmut]

Thanks for the feedback. @russalex or @bitcrazed might be able to comment on any ETA's (or the lack of it). Also, please also make any feature requests on our User Voice Page and help us prioritize.

[russalex]

Unfortunately I can't give an ETA on this one. We know there is a desire to be able to access block devices from WSL but it is not terribly high on our priority list at the moment. As @sunilmut points out, the best thing to do here would be to add something to our User Voice page. Little secret, one thing that always helps the requests there is explaining the actual scenario you're looking to enable.

[fpqc]

@russalex Is there really a point to this kind of thing? It's in the nature of the thing that it is going to be served a pre-assembled abstracted filesystem. Loading up something like dd while Windows mounts the disk (in non-raw mode) seems like it could be a problem, and this kind of thing seems to require effectively writing hardware drivers that negotiate hardware access between WSL and WSWin32

[russalex]

@fpqc, While we know there is some desire for this feature, it's not been enough of a priority for us to discuss planning or implementation.

What is interesting to me is to hear what people want to do with these types of features. The users of this forum often surprise me with their creativity and the more information we get the better. I have found that it never hurts to at least hear someone out. If something is compelling enough, and enough people want it, then we should at least look into feasibility and see where we may be able to fit it into plans.

[jtherin]

I would love to have access to block devices from WSL but it would require strict restrictions (like disallow write from devices mounted from windows/wsl). There is a high risk of corruption if a peripheral is already mounted :(

[finkelamein]

Well actually, raw disk access would make it possible to leverage device-mapper, mdraid and LVM to access any existing linux disks/logical volumes in/on your system. I agree that it should be restricted to disks not already mounted.

[fpqc]

@finkelamein idk about that, I think the LVM driver is baked into the Linux Kernel.

[finkelamein]

It's device-mapper driver that's in the kernel, but yeah, that would be needed.

~$ sudo pvs
/dev/mapper/control: mknod failed: Function not implemented
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
/proc/devices: fopen failed: No such file or directory
Failed to create lvm type filter    

But there would be need of something similar anyway to support access to disks like in the original question by OP.

[jdevora]

I would love to have access to partition types that don´t have native support on Windows.( e.g. mount a ext4 partition) Another user case is to use "parted" for modify removable disks (after desatach them from using the disk manager, of course)

[fpqc]

@jdevora This would necessarily be beyond the scope of WSL. The first thing would be the extension of WSL's ability to mount different partition types in general, maybe with a way to query the NT kernel about "FS capabilities" (which I suspect already exists, but probably does not exist with information about Linux FS feature support). Then you would also need to write a kernel-mode driver (or maybe somehow use FUSE?) supporting ext4. The first thing might be within the scope of WSL. The second probably isn't.

[ghost]

At least fuse will be great. With fuse we will be able to implement\emulate somehow everything other linux specific filesystems.

[ytrezq]

On Cygwin I can use/dev/sdXX files directly.

This allows me to manages the fileystems of embedded devices runing linux directly (for example I can run something like mkfs.ext2 /dev/sdc1or copy a firmware to the ꜱᴅ card using dd)

Would it be possible to have the same feature on Windows subsystem for Linux ? Please note I don’t want to be able to mount the filesystems, but just read and write to their device files. That is, getting a raw access in the kiss way.

Otherwise, wsl isn’t a good platform for building and loading firmwares on the ꜱᴅ card.

[georgir]

Am I understanding properly that even if MS found a way to allow the subsystem direct device access, standard linux filesystem kernel modules would not be usable with the subsystem's customized kernel?

I was hoping we could mount the foreign filesystems which windows does not support otherwise and then export them with smbd - like it was possible to do with the old colinux project - but I guess this is too far off into the future for now.

If fuse support in LXSS is easier to implement, being a single thing as opposed to the various possible linux kernel filesystem drivers, it could be pretty great - even though core linux filesystems that have kernel modules don't seem to have fuse drivers yet because there was never any need for them, they can probably be developed once there is a use-case for them in LXSS.

[jtherin]

Yes, as it's not a real kernel, filesystems included from linux kernel will not be usable (or MS have to rewrite them). But if they implement fuse, I think we will see ext2/3/4 comming to fuse :) And yes, it would be exportable to SMB :D

[sundhaug92]

@georgir That's my general understanding. LXSS does not have a kernel and integrating linux kernel modules with the Windows security-model would be really difficult.

[aseering]

If folks here would like FUSE support (I would), you can up-vote its UserVoice:

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl

[eeevans]

One use would be to mount micropython devices so that you can copy .py files from the local filesystem to the on-board memory without having to have another linux machine lying around.

[ghost]

Pretty cool use case eevans - I haven't thought of anything like that.

FUSE in userspace is also great in general.

[sundhaug92]

@eeevans Can't you do that using the new support for removable drives?

[fpqc]

@sundhaug92 probably not. That is specifically in the case of fat32 and ntfs removable media.

[res0nat0r]

My use for such devices is to be able to use tools like cdparanoia and abcde so that I can rip my audio cds directly in Windows vs. using a Linux box.

[bitcrazed]

@res0nat0r - as a matter of interest, if you're running on Windows, why not just use one of the multitude of audio free and/or open-source tools for Windows?

[res0nat0r]

@bitcrazed Honestly it was just so that I could re-use my abcde.conf. I can rip/tag everything with a simple abcde -N without doing anything else. I'm trying to rip my ~1000 cd collection without a bunch of manual intervention so that I can get rid of all of the discs and was wanting to do it without rebooting my Windows box into Ubuntu.

EAC + Picard on Windows though will also do the trick.

[bitcrazed]

Understood. Supporting USB CD/DVD drives isn't high on our backlog - I recommend you look to other tools; there are plenty for Windows too ;)

[res0nat0r]

No problem, thanks for the feedback!

[lucvdv]

@res0nat0r - for ripping cd's I recommend CygWin, for the time being.

Bash on Ubuntu on Windows has its own advantages, but in CygWin, block device access works. To rip a CD in your primary CD drive to an iso file in D:\Temp, just do something like dd if=/dev/sr0 of=/cygdrive/d/Temp/filename.iso bs=2K

I've created and restored images of SD "drives" for Raspberry Pi in the same way, just picking the right raw disk in /dev.

You can install Bash on Ubuntu on Windows and CygWin side by side on the same machine, no problems encountered so far.

[res0nat0r]

@lucvdv Thanks!

[sqweek]

Use case: being able to inspect the handful of bootable usb thumb drives I have lying around to see what distro of linux/bsd they contain instead of windows being all "this drive must be formatted before it can be used"

[bitcrazed]

Thanks @sqweek - we agree that'd be a useful use-case, but it'd also mean we'd have to implement EXT2/3/4, RaiserFS, UFS, ZFS, etc. which, as you can imagine, is not a simple task.

[therealkenc]

but it'd also mean we'd have to implement EXT2/3/4, RaiserFS, UFS, ZFS, etc

Or implement that "other" popular request. Or address #579. Or implement ptrace(PTRACE_SYSEMU) and address #2555. In decreasing order of complexity from re-implementing ext234.

[bitcrazed]

There's so much more to it than that though. Even EXT2FSD disclaims:

Don't use Ext2Fsd 0.68 or earlier versions with latest Ubuntu or Debian systems. Ext2Fsd 0.68 cannot process EXT4 with 64-BIT mode enabled, then it could corrupt your data. Very sorry for this disaster issue, I'm working on an improvement.

Open source is great & all, but customers have expectations of software shipped by the likes of Microsoft. "No Data Loss" is one of them ;)

[therealkenc]

customers have expectations of software shipped by the likes of Microsoft.

Nah, that's clearly specious. Ext2Fsd is not a Microsoft product and you are not (would not be) shipping it. You can install all manner of things (both from MSFT and not) that will scramble your data. Under this line of reasoning MSFT would disallow 3rd party filesystems in Windows. If a person doesn't like the quality of a particular gratis software implementation, then you pay for it and call a customer service representative.

[I should clarify that if you have Ext2Fsd or paragon then squeek's use-case is addressed with or without WSL. #579 was brought up because it is an outstanding bug and related to his ask, but isn't directly related to the OP's request for block devices. The other two routes forward that I mentioned would require block devices, but not an ext234 re-implementation.]

[jdevora]

Thanks @sqweek - we agree that'd be a useful use-case, but it'd also mean we'd have to implement EXT2/3/4, RaiserFS, UFS, ZFS, etc. which, as you can imagine, is not a simple task.

Why?? I think you that you only have to provide a way to inform Windows to not handle certain drive and let the WSL Kernel to handle it directly.

IIRC, this "don't handle this drive" is already possible in Windows; you can use it for allow a Virtualization Software to handle an specific drive directly.

On the WSL side, the file system will be handled by the same old and trusted code that does it on any Linux distribution; with the same "guaranties" you get from a Native Linux OS.

[sundhaug92]

@jdevora WSL does not use the Linux kernel and thus cannot use Linux kernel drivers

[Naadwo]

Is there any chance that usb devices will be accessible from WSL in the near future? My case is to use SSH with private key from yubikey - it would be nice to be able to use just WSL for that.

[therealkenc]

My case is to use SSH with private key from yubikey

That's #2568 aka #412

[jdevora]

@sundhaug92 You are right, I forgot about that :-( Isn't there an easy way to implement some kind of proxy that will avoid to duplicate coder (aka File Systems) that have been working for years?

[therealkenc]

easy way to implement some kind of proxy

Easy, no. Possible, sure. USB over IP is a thing. But nothing consumer friendly you can drop into WSL that I know of.

[Rondom]

I think people are conflating things quite a bit (accessing HID-devices like Yubikey, reading Linux filesystems (filesystem drivers => unrelated to WSL), accessing block devices under /dev (dd), sending SCSI commands to devices (hdparm)).

I think of these different requests, reading and writing block devices like Cygwin can do is not an unrealistic thing to ask for. I have looked at the Cygwin source some time ago, because I needed to learn how it is done for some other project.

I don't know how easy it would be to support hdparm because I guess there might also be some ioctls involved that would all need to be implemented realistically.

Together with FUSE-support one could even solve the filesystem-issue, because there are working FUSE implementations of Linux filesystems.

[ryao]

Thanks @sqweek - we agree that'd be a useful use-case, but it'd also mean we'd have to implement EXT2/3/4, RaiserFS, UFS, ZFS, etc. which, as you can imagine, is not a simple task.

ZFS has already been ported to Windows as a proof of concept. It is in early development.

https://github.com/openzfsonwindows/ZFSin

If you get FUSE support working (with character and block device support working via FUSE too) on top of implementing block device support, there is a good chance that the ZFS support will resolve itself via that. ;)

That said, I found this issue because I wanted to know whether smartctl to get SMART status and ddrescue to image a disk could be run from the WSL for data recovery purposes on a modern Windows machine. There is no chance of that happening without block device support though.

[SoniEx2]

What if you skip /dev and go straight for Windows?

Is it possible to use something like /mnt/c/{DEADBEEF-DEAD-BEEF-DEAD-BEEFDEADBEEF} to get access to \\. (such that you can then access \\.\RawDevices) in a completely unsupported and potentially dangerous way?

[yecril71pl]

Is it possible to use something like /mnt/c/{DEADBEEF-DEAD-BEEF-DEAD-BEEFDEADBEEF} to get access to \. (such that you can then access \.\RawDevices) in a completely unsupported and potentially dangerous way?

As it was already explained elsewhere, those magic names are interpreted by Explorer only.

[aborisovich]

I need this feature to flash firmware on block devices using Unix tools! Please please please 😃 We can already build C++ GCC for Linux using Visual Studio, and output it to the local WSL. Adding block devices in WSL would fulfill the development (and testing) experience 🏭

[kilves76]

hdparm would be the only way to send certain important low level commands to devices, like set readahead, lookahead, APM, acoustic mgmt, prefetch, write-caching, and especially issue the ATA security-erase command with --security-erase PASSWD Erase a (locked) drive. --security-erase-enhanced PASSWD Enhanced-erase a (locked) drive.

[padthaitofuhot]

I would absolutely love to see this implemented so i can stop fiddling with VMs and passthrough and dualbooting and all of that.

[doherty100]

I ran into this today trying to create a bootable USB stick to update the BIOS on an old computer. Tried to do it in Windows 10 but not working, so took a run at it in Ubuntu 18.04.3 LTS running in WSL according to these intructions: https://tojaj.com/lenovo-biosuefi-update-from-usb-stick-i-e-without-bootable-cd/. I ran aground because the USB stick does not show up as a device in WSL. Now I have to go find another old computer and set it up as a Linux box so I can do this.

[therealkenc]

Now I have to go find another old computer and set it up as a Linux box so I can do this.

That's one way to go. You'll probably want a bootable USB stick to install Linux on that old box. Rufus is pretty popular for doing that.

[aybiss]

I have a use case for this although it's not a strong need. I develop for embedded devices that run Linux and I use WSL for compiling and running unit tests because it's much faster than using a VM. For one particular task I need to hash the MBR as a security audit for the embedded devices. I can not currently run the unit test for this because I can't discover anything at /dev/sda. If I just had read access to the MBR on C drive that would be possible. I don't need support for any filesystem that might actually exist on the drive, just block (S_ISBLK) device access.

[therealkenc]

If all you need is the hash of the mbr, in the unit test, stick it on /dev/loop*, which is available in WSL2.

[jovton]

I ran aground because the USB stick does not show up as a device in WSL. Now I have to go find another old computer and set it up as a Linux box so I can do this.

@doherty100 I was able to access my USB thumb drive from WSL2 using the iSCSI protocol. Here is a short list of steps:

• Install WSL2 on your Windows host.
• Compile and install kernel modules to enable iSCSI on your WSL2 instance.
• Create iSCSI target on your Windows host, and expose your USB drive with it.
• Install open-iscsi on WSL2.
• Load the iSCSI kernel modules using "modprobe".
• Using open-iscsi, discover and connect to the iSCSI target node on your Windows host (make sure to open it on the firewall)
• Use your USB drive on the WSL2 as normal (it will be listed on your /dev directory as "sdb" or "sdc" etc).

https://github.com/jovton/USB-Storage-on-WSL2