Block devices, (i.e. /dev/sda) ?
ScarFez opened this issue · comments
Is there any ETA on when we can see block devices such as sda, for tools like hdparm ?
Thanks
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.
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.
@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
@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.
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 :(
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.
@finkelamein idk about that, I think the LVM driver is baked into the Linux Kernel.
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.
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)
@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.
At least fuse will be great. With fuse we will be able to implement\emulate somehow everything other linux specific filesystems.
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.
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.
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
@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.
If folks here would like FUSE support (I would), you can up-vote its UserVoice:
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.
Pretty cool use case eevans - I haven't thought of anything like that.
FUSE in userspace is also great in general.
@eeevans Can't you do that using the new support for removable drives?
@sundhaug92 probably not. That is specifically in the case of fat32 and ntfs removable media.
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.
@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?
@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.
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 ;)
No problem, thanks for the feedback!
@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.
@lucvdv Thanks!
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"
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.
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 ;)
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.]
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.
@jdevora WSL does not use the Linux kernel and thus cannot use Linux kernel drivers
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.
@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?
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.
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.
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.
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?
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.
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 🏭
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.
I would absolutely love to see this implemented so i can stop fiddling with VMs and passthrough and dualbooting and all of that.
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.
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.
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.
If all you need is the hash of the mbr, in the unit test, stick it on /dev/loop*, which is available in WSL2.
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).
Thanks for the suggestions to use WSL2 instead of WSL but this is not possible at this time due to our IT security policy. Would still love to have device block access in WSL.
The User Voice page linked in the first two comments returns
Account has been deleted
This UserVoice instance is no longer available.
My use cases
- mount a micro sd card with a Linux file system (Raspberry Pi) to add auto-join to my wifi
- run ddrescue on a disk that isn't fully readable
Allow for audio playback (/dev/snd). For example a remote audio player.
This was the main reason I opted into Insiders and moved to WSL2, it's the only thing I still use Cygwin for and I assumed it would be possible in WSL2 so I can finally retire Cygwin. I regularly make use of low-level access to drives to securely wipe them: dd for SDDs and hdparm for everything else. hdparm is currently the only CLI tool that is capable of sending the SECURE ERASE and SANITISE firmware commands to SSDs, which mean it's currently the only (non-proprietary) way to securely erase any SSD, and it was retired on Cygwin due to inactive maintainers, which means WSL2 is currently the only way to do this while still staying on Windows. Please bring this to Version 2004.
Some BIOS on Supermicro motherboards don't like MBR or GPT bootable USB so I have to dd the ISO directly to them. That, and wiping drives. DBAN bootable USB is often the tool of choice, but if data is not sensitive dd is usually good enough to render a disk unbootable.
As explained in #4197 usb access to programmers would make embedded development where direct flashing of targets is involved a lot easier.
You can connect pretty much anything via USB in WSL2. You only need an USB/IP application (I use Virtualhere) and reconfigure the WSL2 kernel if the device needs it.
For example this user connected his iPhone to WSL2 with Virtualhere but needed to enable ipheth module in the WSL2 kernel first.
That seems like a lot of overhead and slow (I need to do debugging). Also don't want to recompile my kernel. That takes away the benefit of a linux build environment of being easy to set up, compared to the windows compiler.
WSL2 should be able to do that out of the box.
Of course, I was talking about as a workaround. USB access and more should come after the GUI and GPU support.
Another use: f3probe seems to only work with block device access, and I'd like to use it to test my flash drive on Windows
Use case: Access LUKS encrypted data such as an lvm volume with partition(s) inside.
I can build and use a custom kernel with the necessary dm-crypt module support, e.g. https://superuser.com/a/1499035/1182194
If my LUKS partition/volume is on a USB drive, I can serve host's USB drive to WSL2 via iSCSI (see UPDATE 2 in the same answer referenced above) and go from there.
However if my lvm volume is on the same physical drive where Windows is, I don't know of a workaround today. (Is there one?)
Another use case: while CD mounting is already possible, I'm unable to use Linux tools to rip audio CDs since programs like abcde/cdparanoia/cd-discid/cd-info reads data directly from the (currently inexisting) raw block device.
Another use case: Bootstrapping a dual-boot to a separate drive (e.g. sudo su; mount -t btrfs /dev/sdc2 target; mkdir -p target/boot/efi; mount -t vfat /dev/sdc1 target/boot/efi; debootstrap --arch=amd64 focal target; chroot target apt-get install linux-image linux-headers ubuntu-desktop; chroot target grub-install --removable /dev/sdc; chroot target update-grub) is currently not possible with the NT kernel’s limited number of supported file systems. For installing distros that require stage tarballs (e.g. Gentoo) using WSL instead of the entirely text-based installation media to set up such a BIOS-based dual boot would make the installation process much easier.
And I’m talking about a dual boot that makes use of multiple whole devices here, not simply a partition-based one. Case in point: my mining rig has two SSDs (one 256GB and one 1TB) and a 2TB HDD (the latter for transfer between OSes) in it.
On a related note: when the rig exclusively ran Linux, it was possible to fstab the 2TB HDD as /home and the 256GB SSD as the filesystem root, in order to allow for a best-of-two-worlds kind of scenario (fast system boot from the SSD while also allowing large amounts of user data to be stored without the need to constantly move stuff back and forth). The limitations presented by the fact that Windows uses drive letters instead of NTFS mounts by default render this impossible.
This is blocking me to go all-in with Windows and WSL 2 for all my desktop needs. There are 3 SSDs in my machine, and I cannot access 2 of them because they have Linux filesystems (which I cannot change).
My use case is wanting to connect my phone so I can adb install the apk I just generated for work and debug it
I agree with @kissgyorgy and @sevaseva : lack of block device access is currently a show stopper for WSL 2. I have a machine that already has a luks volume with my user data-- I should be able to dual boot windows with WSL and linux, and when in windows just mount using the partition designator of the block device. This would allow using the same user home directory in both boot environments...which is pretty much required for switching over to WSL as a daily driver.
There are other technical reasons for this too that have been mentioned above. Another that hasn't been brought up is designating swap space inside of windows for the WSL instance. Having a nvme drive with space allocated for swap would reduce memory pressure, and there's no reason to provision another virtual partition when one already exists specifically for that purpose on the system.
Use case: flash and debug my microcontroller dev board: STM32 F3 Discovery Board
Use case: flash and debug my microcontroller dev board: STM32 F3 Discovery Board
Different board, but for the rest <metoo> want to be able to write images to flash devices </metoo>.
For now I'm still forced to use a Linux VM in VMWare to do it.
Here is our use case:
As a software/hardware development company we've had some success using WSL2 as a development environment for a lot of our software. We would like to be able to access simple usb hardware devices from within the WSL2 environment so we can continue this trend and not have to move over to a linux box for these activities.
... also, tried to follow the requests higher up in this thread but:
Since user voice links have expired. I would like to add additional information in this feature request as recommeneded by @sunilmut @russalex in 2016. I have been unable to find a new WSL User Voice option. Sorry if this not the location to store this info but thought this might help other poeple doing a Bing/Google search.
I would use this feature with the Yubikey for SSH PIV.
At the moment (as fare as I am aware) it kinda hard to setup a Yubikey with PIV on WSL. I think this is because WSL has very limited support for USB devices at the moment. It not important feature as there are workarounds just would be nice to have similair setup for Yubikey SSH on WSL compared to Linux.
Provided some resource links to explain this in more detail and also show other possible solutions.
Resource Links:
How to setup yubikey pkcs11
Securing SSH with OpenPGP or PIV
SSH authentication using a YubiKey on Windows
Using YubiKey from Windows Subsystem for Linux (WSL)
I noticed that the WSL2 kernel configuration seems to support ext and btrfs. Just run zcat /proc/config.gz and filter for EXT and BTRFS
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_BTRFS_FS=y
CONFIG_BTRFS_FS_POSIX_ACL=y
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
# CONFIG_BTRFS_FS_REF_VERIFY is not set
@Dimensional WSL2 root filesystem is ext4 but what does it prove?
mount | column -t
/dev/sdb on / type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered)
@Dimensional WSL2 root filesystem is ext4 but what does it prove?
mount | column -t /dev/sdb on / type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered)
That at least it has ext4 and btrfs support?
Use case: format a USB flash drive with format-udf.sh.
Is there any way to mount an usb drive under WSL2? In WSL1 it works without any problem, but not in WSL2. Any ETA when that's gonna be made possible?
I would like to have native fs performance on my btrfs-formatted second nvme and share the filesystem with Windows via Samba.
Is there any way to mount an usb drive under WSL2? In WSL1 it works without any problem, but not in WSL2. Any ETA when that's gonna be made possible?
This works in both WSL1 and 2 via Ubuntu 20.04: sudo mount -t drvfs H: /mnt/h
Is there any way to mount an usb drive under WSL2? In WSL1 it works without any problem, but not in WSL2. Any ETA when that's gonna be made possible?
This works in both WSL1 and 2 via Ubuntu 20.04:
sudo mount -t drvfs H: /mnt/h
Can't confirm for WSL2, in WSL2, when I typed in “mount” on the console, it said “9p” as the file system type it mounted the windows drives under (C, D and also the USB drive that was plugged in at boot time). When I tried to mount an USB stick with the “9p” file system it said that file system is unknown or something, same for drvfs. It is the main reason I downgraded to WSL1 on because I need WSl to be able to mount USB drives.
Is there any way to mount an usb drive under WSL2? In WSL1 it works without any problem, but not in WSL2. Any ETA when that's gonna be made possible?
This works in both WSL1 and 2 via Ubuntu 20.04:
sudo mount -t drvfs H: /mnt/hCan't confirm for WSL2, in WSL2, when I typed in “mount” on the console, it said “9p” as the file system type it mounted the windows drives under (C, D and also the USB drive that was plugged in at boot time). When I tried to mount an USB stick with the “9p” file system it said that file system is unknown or something, same for drvfs. It is the main reason I downgraded to WSL1 on because I need WSl to be able to mount USB drives.
Both DrvFs and 9p filesystem require that the host Windows operating system mount and understand the filesystem itself. There does not appear to be a real way to access raw block devices from WSL, 1 or 2.
Is there any way to mount an usb drive under WSL2? In WSL1 it works without any problem, but not in WSL2. Any ETA when that's gonna be made possible?
This works in both WSL1 and 2 via Ubuntu 20.04:
sudo mount -t drvfs H: /mnt/hCan't confirm for WSL2, in WSL2, when I typed in “mount” on the console, it said “9p” as the file system type it mounted the windows drives under (C, D and also the USB drive that was plugged in at boot time). When I tried to mount an USB stick with the “9p” file system it said that file system is unknown or something, same for drvfs. It is the main reason I downgraded to WSL1 on because I need WSl to be able to mount USB drives.
Both DrvFs and 9p filesystem require that the host Windows operating system mount and understand the filesystem itself. There does not appear to be a real way to access raw block devices from WSL, 1 or 2.
The USB stick was mounted just fine under Windows, it's just that WSL2 didn't want to play ball with it.
Well, my objective for it would have been the ability to mount a kernel supported filesystem directly from the WSL2 environment, rather than requiring a Windows filesystem driver for it first. But it turns out, I didn't need to do that anyway, as I already had the data elsewhere.
If support for linux FS is added natively into Windows, it certainly would allow more use of accessing an external partition instead of having to do some tricks with something like VirtualBox or VMware connecting directly to the block device. Heck, if it supports direct block device access, then in theory WSL2 could even mount LUKS encrypted partitions. And then it would be easier for MS to see everything we have. That last sentence is purely sarcasm, in case the joke got missed. Don't want any misinterpretation there.
No idea why they didn't do it yet, the specifications for ext2/3/4 are freely available on the net.
Guys, I thinks this is what you want:
https://github.com/MicrosoftDocs/WSL/pull/824/files
Guys, I thinks this is what you want:
https://github.com/MicrosoftDocs/WSL/pull/824/files
That looks fine for fixed disks, but not for USB (removable) disks. What I've been waiting for is a way to partition and format those from within WSL[2].
We use dozens of Raspberry Pi's, which will grow to hundreds of Raspberry Pi CM modules by early/mid 2021. I still have to prepare the flash images in a Linux VM in VMWare. Having to use VMWare also keeps me locked out from WSL2.
can't google chrome give websites raw USB device access if they ask for it? we're kinda at the point where we can run a whole fully functional VM inside a web browser with all the APIs we have today. so you'd just need to build the flash images and load them into a website?
Guys, I thinks this is what you want:
https://github.com/MicrosoftDocs/WSL/pull/824/filesThat looks fine for fixed disks, but not for USB (removable) disks. What I've been waiting for is a way to partition and format those from within WSL[2].
We use dozens of Raspberry Pi's, which will grow to hundreds of Raspberry Pi CM modules by early/mid 2021. I still have to prepare the flash images in a Linux VM in VMWare. Having to use VMWare also keeps me locked out from WSL2.
According to the docs, USB HDD is supported and USB stick support is coming soon.
Forgive my ignorance here, but is the wsl --mount feature only available to Windows Insider builds, or can I get it on Version 2004 (build 19041) by just upgrading WSL separately?
@imReker - nice detective work!
@craigloewen-msft and @OneBlue you spilled the beans!
@neon64 : wsl --mount isn't available anywhere at this time. It's still in the pipe :).
We'll announce publicly once it will be available in insider builds.
...this is encouraging! @OneBlue do you have a rough date? Can we expect this for the Insider Preview builds for 20H2 later this year?
Is there any technical reason a block level device (that is probably a disk, thanks) couldn't be mounted to WSL1? I see the docs are only for WSL2.
Discs can be mounted in disc drives, WSL1 is not a disc drive.
@espg : We've made this change and it's working its way through the Windows release pipeline. If I had to give a non-official estimate, I'd say around 3-5 weeks.
@lmcdougald : WSL2 is running in a lightweight VM and Windows already has infrastructure to attach block devices to VM's. WSL1 does not have any infrastructure for that, so that would be a completely different problem to solve.
We have no plan to implement wsl --mount for WSL1 at this time.
Not concerned with wsl --mount being implemented, just wsl --mount --bare. Obviously that's the part you're suggesting takes the most effort though. Would it be that different than how any sort of usb image writer app takes exclusive mode of a drive? Or is it trickier because the virtual Linux file system has to map it?
There is no block device to map, which is what this issue is about.
wsl --mount is now available in the latest insider preview build (see blog post).
@lmcdougald : Making the device readable and writable in WSL1 wouldn't really be useful unless WSL1 could also parse partitions (GPT / MBR) and read filesystems. That's the reason why wsl --mount is only available in WSL2.
My use cases
-
To use a single windows 10 machine with WSL enabled to complete linux imaging for a small company assembly line process with linux-illiterate assembly folks. As of now I have to provide a secondary computer with linux running in order to access the raw drives for dd imaging.
-
If I was doing a forensic recovery with dd, testdisk, photorec it would be useful for me to stay in one OS instead of splitting myself between two so access to a raw drive again is very useful.
So at the end of the day WSL adds nothing for me that I can't get quickly from a secondary OS or from Docker for Desktop containers at this point. The differentiator for me is to be able to eliminate at least one or both of the aforementioned options.