podman machine init fails on Hyper-V hosts without WSL installed — cross-provider existence check runs wsl -l --quiet (6.0 regression)

[MWurzinger]

Issue Description

On Windows with the hyperv provider configured and WSL not installed, podman machine init aborts before doing any work. Even though the selected provider is correctly resolved as hyperv, init performs a cross-provider name-collision check that enumerates all providers, including WSL. The WSL enumeration shells out to wsl -l --quiet, which exits non-zero on a host where WSL is not installed, and that error is propagated as a hard failure that aborts the entire init.

This is a regression in 6.0.0. In 5.8.x, init only consulted the configured provider, so a Hyper-V-only host (no WSL) was never probed for WSL during init.

This blocks podman machine init entirely on a common enterprise configuration: the Hyper-V provider with WSL deliberately not installed (e.g. WSL disabled by security policy). It also surfaces through Podman Desktop, which drives the CLI.

Steps to reproduce the issue

Steps to reproduce the issue

1. Windows host with the Hyper-V Windows feature enabled and WSL not installed (neither the Microsoft-Windows-Subsystem-Linux / VirtualMachinePlatform optional components nor the WSL app are present).
2. Select the Hyper-V provider via any of: CONTAINERS_MACHINE_PROVIDER=hyperv, [machine] provider = "hyperv" in containers.conf, or podman machine init --provider hyperv.
3. Run podman machine init.

Describe the results you received

init aborts immediately (log anonymized; German locale):

time="..." level=debug msg="Using Podman machine with `hyperv` virtualization provider"
time="..." level=debug msg="socket length for C:\Users\<user>\.config\containers\podman\machine\wsl is 55"
time="..." level=debug msg="socket length for C:\Users\<user>\.local\share\containers\podman\machine\wsl is 60"
... (socket-length lines are computed for both the wsl and the hyperv machine dirs) ...
time="..." level=debug msg="socket length for C:\Users\<user>\.config\containers\podman\machine\hyperv is 58"
Error: command C:\WINDOWS\system32\wsl.exe [-l --quiet] failed: exit status 1 (Das Windows-Subsystem für Linux ist nicht installiert. Sie können die Installation ausführen, indem Sie "wsl.exe --install" ausführen. Weitere Informationen finden Sie unter https://aka.ms/wslinstall)
time="..." level=debug msg="Shutting down engines"

The message is localized — English equivalent: "The Windows Subsystem for Linux is not installed." — but the failure is not locale-dependent; any non-zero exit from wsl -l --quiet aborts init.

Note that the provider is correctly resolved as hyperv. The failing wsl.exe call comes from the WSL provider being included in the cross-provider existence check, not from provider selection. --provider hyperv and CONTAINERS_MACHINE_PROVIDER=hyperv do not avoid it.

Describe the results you expected

podman machine init should create the Hyper-V machine. When a provider's platform is not installed (here: WSL), the cross-provider existence check should treat that provider as having no machines and continue — not abort with a hard error. WSL not being installed is a normal, supported state on a Hyper-V-only host.

podman info output

# Client section only (the machine is not created yet). Please replace with your actual `podman info` output.
version: 6.0.0
Os: windows
OsArch: windows/amd64
provider: hyperv

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

• Windows 10/11 (Microsoft Windows [Version 10.0.26200.8457]) (non-English / German locale in our case), Hyper-V feature enabled, WSL not installed.
• Provider: hyperv (confirmed in the debug log).

Additional information

Claude helped me to find this issue and added this information:

Why this is a 6.0 regression
In v5.8.2, initMachine checked existence against the configured provider only:

_, exists, err := shim.VMExists(initOpts.Name, []vmconfigs.VMProvider{provider})
There was no VMExistsOnHyperVisor call iterating all providers, so a Hyper-V-only host was never probed for WSL during init.

v6.0.0 introduced the all-providers behavior (per the 6.0.0 release notes: all podman machine commands now operate on VMs from all providers, regardless of the configured provider). That change is what adds the unconditional WSL probe to init.

Suggested fix (maintainers will know best)

Any of:

1. In VMExistsOnHyperVisor, skip providers whose platform is not installed — e.g. gate the WSL stubber with wutil.IsWSLInstalled() / provider.IsInstalled(define.WSLVirt) and treat "not installed" as "no machines" (false, nil).
2. Make getAllWSLDistros / WSLStubber.Exists return (false, nil) when WSL is not installed, reusing the existing not-installed detection in wutil (parseWSLStatus, wslNotInstalledMessages) instead of returning a hard error.
3. More generally, VMExistsOnHyperVisor should not fail when one provider's enumeration fails solely because that provider is not installed.

Workarounds (for others hitting this)

• Enable only the WSL Windows feature, no distro: wsl --install --no-distribution, then reboot. This makes the real wsl -l --quiet exit 0. (Not acceptable where WSL must remain uninstalled.)
• Put a no-op wsl.exe on PATH ahead of C:\Windows\System32 that prints nothing and exits 0; the probe then returns "no WSL machines" and init proceeds on Hyper-V. It must be a real .exe (Go's exec resolves wsl via PATH but launches it through CreateProcess, which cannot run a .cmd/.bat). Note this only satisfies the CLI; Podman Desktop's own WSL preflight is separate.

[Luap99]

cc @baude @l0rd

[baude]

Seems like a reasonable bug and problem. I will assign myself but I cannot do anything about it until Monday (maybe?). If anyone else wants to reproduce and fix, thats fine too.

[baude]

This is proving more difficult that it would appear. The versions of windows that I have still leave a "stub" file for wsl.exe around for user convenience. This is even after uninstalling the WSL system components from windows. And I cannot delete the file even as adminstrator). I really wanted to replicate your error so I could make this right for you. @MWurzinger If I were to make a PR and kind guess my way through it, are you in a position to compile it and try the branch? If not, maybe I can attach a compiled binary?

[l0rd]

@baude I am able to reproduce the problem after running wsl --uninstall. I also have a fix here #29063 PTAL