-
Notifications
You must be signed in to change notification settings - Fork 832
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wsl --mount not working on arm64 #12360
Comments
View similar issuesPlease view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it! Open similar issues:
Closed similar issues:
Diagnostic information
|
Powershell Get-Disk output
The file path for the VHD is on Disk 1 (D:\media\extdisk.vhdx).
|
|
Hmm, sounds like maybe a WIndows OS update is needed then? And I'm guessing that that version of Windows 11 has not been released yet. I am on the Microsoft Store version of WSL2 and thought that it was decoupled from Windows ... sounds like it was mostly decoupled but maybe not entirely (but as much as technically possible). |
@benhillis so we just need to wait until version 27653 is available? Do you know if enabling the Windows Update option "Get the latest updates as soon as they're available" will install this version? |
@benhillis, if you see this and have pity on a poor WSL hacker, any help/suggestions would be appreciated. I believe I have Windows version: 10.0.26100.2314 so I need that to update to 10.0.27653.xxxx then? (Sorry, my Windows background is a bit sketchy). In my Windows Update I see that "2024-12 Cumulative Update for Windows 11 Version 24H2 for arm64-based Systems (KB5048667)" is pending and I'm guessing that is probably the 27653 update that I need. Unfortunately every time I try to install it, it fails with "Install error - 0x800f0983". In reading about that error it sounds VERY painful as it sounds like my Windows installation has become "corrupted" and I will need to wipe out my machine and re-install Windows and then everything I have... pretty depressing. I'm guessing that the "corruption" was caused when I created the VHD in Disk Management and then tried to mount it in WSL2. I have since deleted the VHD but it looks like the damage has already been done. :( Does that sound about right? |
Windows Version
Microsoft Windows [Version 10.0.26100.2314]
WSL Version
2.3.26.0
Are you using WSL 1 or WSL 2?
Kernel Version
5.15.167.4-1
Distro Version
Ubuntu 22.04
Other Software
Existing issue #12038 was closed after waiting for logs.
WSL2 is from Windows Store and is up-to-date (ran wsl --update to be sure).
Windows 11 is up-to-date (ran Windows Update check for updates to be sure).
$ wsl.exe --version
WSL version: 2.3.26.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.2314
Repro Steps
With WSL2 IO performance (and the Linux file security model) work much better for the native filesystem (ext4) though there is very much appreciated access to the Windows NTFS filesystems through the drvfs filesystem driver albeit at a slower IO rate.
To reproduce:
Get-Disk
wsl.exe --mount \\.\PhysicalDrive# --bare
In my case the drive number of the new VHD was 2 so I tried running
wsl.exe --mount \\.\PhysicalDrive2 --bare
in a variety of contexts:
I am generally trying to follow the steps outlined in https://joeferguson.me/adding-another-disk-to-wsl2/, though some of those steps are apparently outdated. Like the process to get the VHD drive number, so I eventually figured out that (these days) a simple Get-Disk in Powershell will interactively provide the number.
Expected Behavior
New VHD will mount into Ubuntu where an ext4 filesystem can then be created and the resultant ext4 filesystem can then be mounted and used for normal file handling from that point forward.
So basically now a
df
command in Linux would show the usual/
(root ext4) filesystem, all thedrvfs
filesystems exposing the various NTFS Windows "drives", plus this new ext4 filesystem which happens to be on a different physical disk than the root filesystem. Expectation is that the IO performance of the new VHD would be similar to the root filesystem (after taking into account any physical limitations due to the disk characteristics and interfaces, e.g. SSD vs spinning, USB, etc).Actual Behavior
PS C:\> wsl --mount \\.\PhysicalDrive2 --bare
wsl.exe --mount is not supported for ARM64 on this version of Windows.
Error code: Wsl/Service/WSL_E_WSL_MOUNT_NOT_SUPPORTED
also tried
PS C:\> wsl --mount --vhd D:\media\extdisk.vhdx --bare
wsl.exe --mount is not supported for ARM64 on this version of Windows.
Error code: Wsl/Service/WSL_E_WSL_MOUNT_NOT_SUPPORTED
Diagnostic Logs
Since this is a WSL --mount issue, tried to follow the guidance to run the
wmic
command but looks like that has been deprecated.Running
wmic diskdrive get Availability,Capabilities,CapabilityDescriptions,DeviceID,InterfaceType,MediaLoaded,MediaType,Model,Name,Partitions
from an elevated command prompt resulted in -'wmic' is not recognized as an internal or external command, operable program or batch file.
Attached logs from
collect-wsl-logs.ps1
.WslLogs-2024-12-09_19-33-42.zip
The text was updated successfully, but these errors were encountered: