Failed to read component versions: /opt/docker-desktop/componentsVersion.json not found
Provisioning a data disk with ID fbd3fc9a-1163-3149-9ab4-8f884cf27d30
Detected no file system. Formatting
mkfs.ext4: No such device or address while trying to determine filesystem size
Unmounting disk: invalid argument
A read-only investigation found these VHDX files:
docker_data.vhdx (approximately 16 GB)
docker_data.fresh.vhdx (approximately 1.65 GB)
ext4.vhdx (approximately 100 MB)
The files exist and are readable from Windows, but their internal filesystem health has not been verified. The investigation also found repeated container cleanup failures involving a read-only filesystem in Docker’s containerd metadata database.
I have existing project data and containers that I need to preserve. I have not intentionally reset Docker or formatted its storage.
Could you help me identify the likely cause and recommend safe troubleshooting steps that will not delete or overwrite existing Docker data?
I cannot provide a Diagnostics ID because Docker Diagnostics is not working. I can provide the investigation report and any additional logs or command outputs needed.
You possibly already found some solutions, but if not, Mm first thought was that the data disk was corrupted somehow, but if WSL bootstrap was the one that failed, I assume that should not be affected by corrupt filesystem on a virtual disk.
Docker Desktop has to mount the data disk to keep your data when upgrading, bt if WSL backend is used and WSL cannot mount the disk, Docker Desktop could fail too.
If you searched for similar issues you likely also found recommendations for upgrading WSL itself, but first you could try if you can mount the same data disk manually.
You also mentioned container cleanup failures, so if something tries to cleanup containers, Docker or containerd must be already running which means the problem is not with the operating system’s disk.
If the data disk is corrupted, it is possible that you already lost the data unless the vhdx can be recovered somehow. If it is a different problem, we can think more about debugging and/or you cana lso share it on GitHub.
Even if it is a disk problem, the question could remain what broke it, whihc could be hard to find out, but diagnostics include logs that you can find on the host filesystem, so checking those would still be an option.
Have you tried to run other wsl distributions? Do you get an error code, when you try to start a wsl distribution?
If it fails in generall, you mgith try to reinstall the wsl version with msiexec /fa wsl.2.7.14.0.arm64.msi (assuming you ussed the latest stable wsl version).