Hakan

Reclaiming it is three steps and skipping the first is why people report that compaction "did nothing".

1. Tell the filesystem to release the blocks. Inside the distro:

sudo fstrim -av

This is the step that communicates downward, it discards blocks Linux no longer uses so the virtual disk layer can see they are free. Without it, the compactor looks at the disk, sees data everywhere, and correctly reclaims nothing.

2. Shut everything down, from PowerShell, because the file cannot be in use:

wsl --shutdown

Give it a few seconds. Docker Desktop must be closed too, or it holds its own distro open.

3. Compact the file. diskpart as administrator:

select vdisk file="C:\Users\<you>\AppData\Local\Packages\<distro>\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk

On a 90GB file holding 12GB, expect it to come back close to the real usage.

For question 2, use the address the distro already knows, rather than localhost. Inside Linux:

ip route show default | awk '{print $3}'

That gives the gateway, which is the Windows host on the virtual network. It changes on every restart, which is exactly why hardcoding it into a config is a bad afternoon.

So do not hardcode it. Options in order of how well they hold up:

• Resolve $(hostname).local if your setup provides it
• Read the gateway at startup in your app's config
• Switch WSL to mirrored networking mode, in .wslconfig:

[wsl2]
networkingMode=mirrored

Mirrored mode makes the distro share the host's network interfaces, so localhost genuinely means the same thing on both sides in both directions. It is the real fix for your problem rather than a workaround, and it also tends to survive VPNs, which the shim does not.

Before building anything around the address, check whether you need it at all: because in a lot of cases you do not.

Reaching a Linux service from Windows. Ports listened to inside the subsystem are generally reachable from Windows at localhost directly. If you are trying to open a web service in a Windows browser, try localhost first; there is a good chance the address hunt is unnecessary.

Reaching a Windows service from Linux. This is the direction that genuinely needs an address, because localhost inside Linux means Linux. The host's address is available from inside the distribution, and depending on your configuration there is also a name that resolves to it.

Reaching the Linux service from another machine on the network. This is the hard case, and the address does not help you directly: other machines cannot route to that virtual network. You need a port forward on the Windows host, and the built-in port proxy tool is the usual way to set one up.

"Enabled enough to take the extensions, not enough to create a VM" would explain why every fix I tried for one broke the other.

Practical suggestion once you have sorted the above: after any major macOS update, run the toolchain reinstall before you need it rather than discovering it mid-task.

It takes five minutes and it removes the entire category of "why has my build broken today". I keep it in the same note as the other post-update chores.

And brew doctor is genuinely worth running after an update even when nothing looks wrong, it flags the mismatched-header case explicitly, in advance, instead of letting a compile fail with something unrelated-looking three days later.

That code means the virtual machine could not be started, and in practice it almost always means a required Windows feature or a hardware virtualisation setting is off.

The subsystem in its current version runs a real lightweight virtual machine, so it needs the platform underneath it. The checklist, in the order worth trying:

1. Enable the required Windows features. Both the subsystem feature and the virtual machine platform feature must be on. Turning one on without the other produces exactly this symptom.
2. Reboot. These features genuinely require it and the failure looks identical before and after enabling them until you do.
3. Check virtualisation is enabled in firmware. On many machines this is off by default. The setting is in the system firmware, usually under CPU or advanced settings, and is named after the processor vendor's virtualisation technology.
4. Check the task manager's performance tab. It reports whether virtualisation is enabled, which tells you whether step 3 is needed without rebooting into firmware to look.

The circle breaks the same way as any bootstrap problem: fetch one file by hand, verify it, and install it with a tool that does not need the network.

The distribution publishes a keyring package containing the current signing keys. Download that package directly with a downloader that is already present, then install it with the low-level package tool rather than the network-aware one.

The key point is to verify the file before trusting it. You are installing a trust anchor over a channel you have not authenticated, so compare its checksum against the value published by the distribution, fetched from a machine that works. Skipping that step converts a package problem into a security problem.

After installing the keyring, refresh the package lists and everything proceeds normally.