Due to increasing space consumption of WSL I was forced to move my WSL distros to another disk.
Ubuntu
docker-desktop
docker-desktop-data
I used these commands.
wsl --shutdown
wsl --export (on all three of those distros)
wsl --import (already on another disk)
Now my environment is running fine but the ext4.vhdx in AppData\Local\Docker\wsl\data is still present and I can't remove it due to it still being used.
When I look at process hadnles
Its still being used by system which is not telling much.
If I run WSL --shutdown all virtual disks present on disk E: lose their handles and the one on disk C: is still being used.
Would you know how to find out what part of WSL or if it even is WSL is using?
Since shutting down WSL does not remove that handle it might be used by something else.
Its not docker-for-desktop that one uses different disk.
Thanks for your suggestions.
Docker Desktop for Windows, which uses WSL2, stores all image and container files in a separate virtual volume (vhdx). This virtual hard disk file can automatically grow when it needs more space (to a certain limit). Unfortunately, if you reclaim some space, i.e. by removing unused images, vhdx doesn't shrink automatically. Luckily, you can reduce its size manually by calling this command in PowerShell (as Administrator):
Optimize-VHD -Path $Env:LOCALAPPDATA\Docker\wsl\data\ext4.vhdx -Mode Full
If the above command fails with
The system failed to compact 'C:\Users\Maxx\AppData\Local\Docker\wsl\data\ext4.vhdx':
The process cannot access the file because it is being used by another process. (0x80070020).
exit form Docker Desktop or stop services and tasks using that file:
net stop com.docker.service
taskkill /IM "docker.exe" /F
taskkill /IM "Docker Desktop.exe" /F
wsl --shutdown
I reclaimed 15Gb of 40Gb.
Origin of the solution.
You can just clean data from interface. Troubleshooting -> Clean/Purge data
Upgrading from WSL1 to WSL2 made it a bit messy, but resetting docker-desktop to its default setting and then purging data from WSL (using docker-desktop troublesshot) cleared it for me.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've installed wsl2 on my windows machine and I was not able to figure out where the files are actually stored.
Note, that I don't mean that I wanna browse them inside the file explorer - I know it can be done by typing in the explorer \\wsl$\.
If I would have to guess I would say the files are stored in the same hard-drive that the os is stored.
So actually I have two related questions.
Where the files are stored?
If they are stored in the hard drive of my os, can I somehow relocate my wsl to another hard drive?
EDIT:
I was able to locate the installation path, in my machine the path is:
C:\Users\Eliran\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState
Is there a way to mount this to another location?
All the files are stored in a ext4.vhd files in the installation directory, which you can't mount directly onto windows as it is in ext4 (obv)
There's two ways to change the location of the above mentioned vhd file the official, tedious way and an unofficial quick and dirty way
The official tedious way
Export the distro to a location with wsl.exe --export <Distro> <FileName> from CMD/PowerShell
Import the distro to a different location with wsl.exe --import <Distro> <InstallLocation> <FileName> [Options]
The problems with this is it's quite time consuming and after you do this, pray that it exported and imported several gigabytes worth of thousands of files without any problems
The quick and dirty way
This involes an unofficial opensource WSL manager called lxrunoffline
To install it (takes like a min at max) read through the instructions by the dev here
If you installed it by manually downloading the binaries from the release page, make sure to install it to a directory in PATH, like C:\Windows
Now the process is simple as lxrunoffline move -n <distroname> -d <destination-folder>
For example lxrunoffline move -n Ubuntu-20.04 -d G:\wsl\
Hope I helped
Edit: typo
I executed these commands in PowerShell to move my Ubuntu distro from C: to drive D:\wsl-ubuntu :
PS C:\Users\smarc> mkdir D:\wsl-ubuntu (create new location)
PS C:\Users\smarc> wsl -l -v (list wsl distros)
NAME STATE VERSION
Ubuntu Running 2
PS C:\Users\smarc> wsl --shutdown
PS C:\Users\smarc> wsl -l -v (verify if is stopped)
NAME STATE VERSION
Ubuntu Stopped 2
PS C:\Users\smarc> wsl --export Ubuntu ubuntu.tar
PS C:\Users\smarc> wsl --unregister Ubuntu
PS C:\Users\smarc> wsl --import Ubuntu D:\wsl-ubuntu\ .\ubuntu.tar --version 2
and reboot the computer at the end.
The only problem I have is that the default user when I started the Ubuntu application is the root. I need to execute $ su sergio to enter in my personal user.
You can delete the ubuntu.tar at the end of process.
#edit 2021-04-13: As pointed out in the comments, I had forgotten the "--export" command.
This is an answer to your last question: use symbolic links
open command prompt as administrator
shut down wsl vm using wsl --shutdown
change folder to C:\Users\Eliran\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\
move the LocalState folder to another location like Z:\wsl\Ubuntu\
create symbolic link with mklink /J LocalState Z:\WSL\Ubuntu\LocalState
I would also edit/create the .wslconfig file from your user folder to move the swap file to the folder where you store your WSL vm's and maybe edit/add options for CPU cores and RAM assignment
[wsl2]
memory=4GB
processors=2
swap=1GB
swapFile=Z:\\WSL\\swap.vhdx
memory is the maximum amount your ram that WSL will use;
processors is the alocated cores to your WSL vm;
swap is the size of the swap file;
swapFile is the location of your swap and to my knowledge is used by all WSL vm's; notice the double slashes in the path, they are mandatory for the path.
Start your WSL VM as you normally would.
VirtualBox (Version 5.2.24 r128163 (Qt5.6.2)) user with xubuntu guest (Ubuntu 18.04.2 LTS) and Windows 10 host here.
I recently tried to resize my vdi from ~100GB to 200GB. In windows I used the command:
./VBoxManage modifyhd "D:\xub2\xub2.vdi" --resize 200000
That went fine. Then I used a gparted live cd to create a vm, attached the vdi and resize the partitions:
gparted gui
All looks good. If I then use the 'fdisk -l' command whilst in the gparted vm the increased partition sizes are visible as expected.
fdisk -l results for vdi attached to gparted vm
If I try and resize the file system for one of the newly resized logical drives with 'resize2fs /dev/sda5' I am told it is already 46265856 blocks long and there is nothing to do.
However....
If I then re-attach this vdi to an ubuntu vm and boot up with the vdi, the 'fdisk -l' command gives different results and is basically telling me that the drive is still 100GB in size.
fdisk -l results for the same vdi attached to ubuntu vm
The 'df' command confirms that it is not resized.
df command output with same vdi attached to ubuntu vm
If I try the command 'resize2fs /dev/sda5' I get the result:
The filesystem is already 22003712 (4k) blocks long. Nothing to do!
How can I fix this and make the ubuntu vm see that the disk and partitions have been increase in size?
Ok. I will answer my own question (thank you for the negative vote anonymous internet).
This issue occurs when you have existing snapshots of the drive that you are trying to expand associated with a VirtualBox VM.
I found this described in VirtualBox's documentation.
https://forums.virtualbox.org/viewtopic.php?f=35&t=50661
One suggested solution is to delete the snapshots, however I got an error message when I attempted that.
The solution that worked for me was to clone my VM. The cloned VM (which did not have any snapshots associated with it), behaved as expected and showed the correct size for the resized disk.
To be clear: the situation I described above is 100% true.
Hope that helps someone.
I recently moved my wsl directory to another drive due to low storage in C: drive. As per the answer provided in this StackOverflow post, I used lxrunoffline tool and moved my Ubuntu distribution to another drive (E:\wsl in my case). As soon as the distribution was moved successfully, I ran wsl to test and it worked like a charm.
Everything went fine until one day I accidentally renamed the E:\wsl folder to something else. Well, as expected, wsl didn't work. Then, I reverted back to the name wsl and expected it to work but to my surprise, it didn't find any installed distribution after that even though it's installed... 😕
E:> wsl
Windows Subsystem for Linux has no installed distributions.
Distributions can be installed by visiting the Microsoft Store:
https://aka.ms/wslstore
Is there any way to revert back to the old directory or make wsl point to a manual location?
EDIT: I don't want to reset Ubuntu as I want to retain the installed packages and preferences...
Well, I finally found a solution to this problem. 😊
This is as simple as registering the distribution using lxrunoffline tool using the rg or register command.
E:\LxRunOffline\LxRunOffline-v3.3.3>lxrunoffline rg
[ERROR] the option '-d' is required but missing
Options:
-n arg Name of the distribution
-d arg The directory containing the distribution.
-c arg The config file to use. This argument is optional.
After running the register command, I was able to start wsl as usual. But that would log you in as a "root" user and would thus start in "/root" directory. I ran the following command to start wsl as different user (this is for Ubuntu):
ubuntu config --default-user <user-name>
I have a dual-boot setup with Windows 10 and Kubuntu 18. Following instructions found from here and there I managed to get the Windows to run as guest in Kubuntu host as a VM using VirtualBox.
sudo usermod -a -G disk $USER
VBoxManage internalcommands createrawvmdk -filename "/path/to/vm/win10.vmdk" -rawdisk /dev/sda -partitions 1,3,4 -relative
The first line is to avoid running VirtualBox as superuser.
When I boot the VM, I briefly see an error message
Boot Failed. EFI DVD/CDROM
SystemBootOrder not found. Initializing defaults.
Creating boot entry "Boot0003" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi"
and then end up in grub shell. Now, when I run the commands
insmod chain
set root=(hd0,gpt1)
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
boot
Windows boots and works just fine but entering these every time is not exactly smooth workflow. Any idea how to permanently fix this?
Please note that I'd still like to be able to physically boot into both OS's.
Thanks,
I had the same problem. I fixed it, but then updated my kernel and so grub re-un-fixed it for me! Figuring it out for the second time was quicker, but I figured it'd be even quicker next time to find my answer on StackOverflow!
My grub.cfg file in /boot/efi/EFI/ubuntu looked like this:
search.fs_uuid 47d6233f-c0ae-4f89-bf18-184452eac803 root hd0,gpt6
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
Because we have setup the VirtualBox vmdk file with only the selected partitions for Windows to work, the search.fs_uuid command was failing, $root was empty and so grub can't find $prefix/grub.cfg (/boot/grub/grub.cfg in my linux rootfs which is on sda6==gpt6)
I automated it by changing the EFI grub.cfg, note my EFI System partition is 2 not 1 as in your example:
search.fs_uuid 47d6233f-c0ae-4f89-bf18-184452eac803 root hd0,gpt6
set prefix=($root)'/boot/grub'
if [ -f $prefix/grub.cfg ]
then
configfile $prefix/grub.cfg
else
insmod chain
set root=(hd0,gpt2)
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
boot
fi
Now if grub can find the cfg file it will give me the menu to select the boot as before, but if it can't - when I'm in VirtualBox - it'll just boot straight into Win10.
Hope this helps!
Is there any way to restore a snapshot from inside a VBox guest machine?
I have a Windows machine that hosts numerous machines. Currently we are working with something using a Ubuntu guest and it is really painful to have to keep switching machines just to revert a snapshot.
What I had in mind is setting the machine to a "base" state and every time I want to go to that I just type some command like:
revertbase
Than the machine would restart in the previous snapshot and I would just need to restart ssh to continue.
You cannot snapshot a running machine, you have to freeze it before, so my guess is that the host itself cannot do that.
In the host machine, from command line you can do this using VBoxManage.
The file is located in
Program Files/Oracle/VirtualBox/VBoxManage.exe
and is used as a command-line interface with VirtualBox.
Using the command:
VBoxManage snapshot "MachineName" take SnapShotName
Them after that:
VBoxManage snapshot "MachineName" discardcurrent -state
To return to the last state, for more read the text bellow, to have easy acess to VBoxManage add it to your path:
PATH=%PATH%;c:\Program Files\Oracle\VirtualBox
Taken from: http://www.linux.com/news/enterprise/systems-management/8224-secrets-for-controlling-virtualbox-from-the-command-line
Managing snapshots
One of the most useful feature of virtualization software is its ability to take snapshots of VMs. It's always a good idea to take a snapshot of a VM before making changes to it. Snapshots help on the hardware level to recover a system that has been rendered unusable due to changes to the hardware configuration, and on the software level they protect against data loss due to accidental deletion or virus.
Taking a snapshot from the VirtualBox CLI is child's play. VBoxManage snapshot "Fedora" take snap1-stable-system takes the snapshot of a stable Fedora VM when everything is working perfectly. Saving a snapshot might take some time, depending on the VM and the resources on the host. To make sure you don't make changes to a system while a snapshot is being taken, VirtualBox grays out the whole VM interface, and you cannot use it until the snapshot has been saved.
With a stable snapshot in hand, go ahead and play with the system. If you get in trouble and your machine won't boot or starts behaving abnormally, you can revert to the snapshot of the stable machine. To do this, first power off the VM with VBoxManage controlvm "Fedora" poweroff, then revert to last snapshot with VBoxManage snapshot "Fedora" discardcurrent -state. If you have multiple snapshots, you can revert to the last but one snapshot with the -all switch instead of -state.
Of course when you revert to an older state, all the changes you made since that snapshot was taken are lost, including all configuration changes and changes to old and new files. You can work around this by specifying that your data should be stored on a "writethrough" disk, which behaves like a normal disk but isn't affected by snapshots. Put another way, when you take a snapshot, VirtualBox ignores the writethrough disk. You can store all your important data and files or your complete /home directory on that disk.
¬â€
To add a writethrough disk, use the -type writethough option when creating a new disk with createvdi. You can also change a disk you created earlier and make it writethrough. To do so, first unattach it from the VM with VBoxManage modifyvm "Fedora" -hdb none, and then unregister it with VBoxManage unregisterimage disk fourgig (using the name of the disk on your system in place of fourgig). Now register it back again but as a writethrough disk with VBoxManage registerimage disk "fourgig" -type writethrough. Finally, attach it back to the VM using VBoxManage modifyvm "Fedora" -hdb fourgig.
Now you can safely save data on this disk, and no matter what state the VM is in, the data will always be safe. But remember not to revert back to a state that was saved before this disk was created; if you do, VirtualBox will simply delete the disk, becase it didn't exist in that state. Also, VirtualBox doesn't currently let you take a snapshot of a VM that has a writethrough disk attached, so you have to unattach a writethough disk before saving the state of the VM and then reattach it. I hope in upcoming VirtualBox versions the presence of a writethrough disk will have no influence on the snapshot process.
An updated answer. You still can't do it from the guest directly.
You could trigger the host to restart the guest by means of a shared drive/folder and a script running on the host which will reload the guest when a shared file is updated.
Included is my windows script to restart the guest. The commands as given by Canesin did not work for me. I have the following in a CMD file.
PATH=%PATH%;c:\Program Files\Oracle\VirtualBox
vboxmanage controlvm "DEMO" poweroff
timeout /t 10
vboxmanage snapshot "DEMO" restorecurrent
timeout /t 10
vboxmanage startvm "DEMO"