docker
[HELP] I may have screwed my docker setup
Description
I tried to get rid of my wsl-swap virtual disk forcefully, in an effort to gain back some space on my drive. This all happened while I tried to get Podman Desktop to play nice with Docker Desktop, while also being in a time where Docker 4.31.x may have had issues for some people.
Get-ChildItem "HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss" -Recurse
Hive: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss
Name Property
---- --------
{00cf9bc9-5fa8-49db-b5e3-bfec5 State : 1
80880c7} DistributionName : podman-machine-default
Version : 2
BasePath : \\?\C:\Users\user\.local\share\containers\podman\machine\wsl\wsldist\podman-machine-default
Flags : 15
DefaultUid : 0
{2070c9a0-5a23-4c54-b0aa-71935 State : 1
735ba38} DistributionName : Ubuntu-24.04
Version : 2
BasePath : C:\Users\user\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_79rhkp1fndgsc\LocalState
Flags : 15
DefaultUid : 1002
PackageFamilyName : CanonicalGroupLimited.Ubuntu24.04LTS_79rhkp1fndgsc
{f04ab2ab-ab17-4454-ae4f-c5b3b State : 1
2ec942b} DistributionName : docker-desktop
Version : 2
BasePath : \\?\C:\Users\user\AppData\Local\Docker\wsl\main
Flags : 15
DefaultUid : 0
%LOCALAPPDATA%\Docker\wsl\data folder is empty
Extra info that may be relevant I am now running 154084 dev build Distro: Ubuntu-24.04 Podman Desktop is uninstalled
Reproduce
Unknown
Expected behavior
Removing wsl-swap while docker is shutdown should not ruin Docker in any way Removing Podman Desktop should not affect Docker in any way
docker version
Client:
Version: 26.1.4
API version: 1.45
Go version: go1.21.11
Git commit: 5650f9b
Built: Wed Jun 5 11:29:54 2024
OS/Arch: windows/amd64
Context: desktop-linux
Server: Docker Desktop 4.31.1 (154084)
Engine:
Version: 26.1.4
API version: 1.45 (minimum version 1.24)
Go version: go1.21.11
Git commit: de5c9cf
Built: Wed Jun 5 11:29:22 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.33
GitCommit: d2d58213f83a351ca8f528a95fbd145f5654e957
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client:
Version: 26.1.4
API version: 1.45
Go version: go1.21.11
Git commit: 5650f9b
Built: Wed Jun 5 11:29:54 2024
OS/Arch: windows/amd64
Context: desktop-linux
Server: Docker Desktop 4.31.1 (154084)
Engine:
Version: 26.1.4
API version: 1.45 (minimum version 1.24)
Go version: go1.21.11
Git commit: de5c9cf
Built: Wed Jun 5 11:29:22 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.33
GitCommit: d2d58213f83a351ca8f528a95fbd145f5654e957
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
PS C:\Users\user> docker info
Client:
Version: 26.1.4
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.14.1-desktop.1
Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe
compose: Docker Compose (Docker Inc.)
Version: v2.27.1-desktop.1
Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.32
Path: C:\Program Files\Docker\cli-plugins\docker-debug.exe
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.24
Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: C:\Program Files\Docker\cli-plugins\docker-feedback.exe
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.2.0
Path: C:\Program Files\Docker\cli-plugins\docker-init.exe
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe
scout: Docker Scout (Docker Inc.)
Version: v1.9.3
Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 26.1.4
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d2d58213f83a351ca8f528a95fbd145f5654e957
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
Kernel Version: 5.15.146.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.761GiB
Name: docker-desktop
ID: 0aa66713-512a-43bc-8152-aa4f91c628db
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=npipe://\\.\pipe\docker_cli
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile
Diagnostics ID
C014D5F5-FFBB-44CF-BE2F-1AB4538C1912/20240613173527
Additional Info
I am now running 154084 dev build Distro: Ubuntu-24.04 Podman Desktop is uninstalled
any help on this matter is greatly appreciated, in the meantime I'm trying to recover the disk files using recovery tools.
Hi @ambhaiji,
can you please share a few more details of what you have exactly done when trying to make docker desktop play nicely with podman desktop and/or deleting the wsl-swap?
What is the behaviour you see when you start docker desktop as opposed to the behavior you were expecting?
For what I can see:
- You no longer have a
docker-desktop-datadistribution registered in WSL. Docker Desktop never deletes it, except in two cases: (1) the factory reset button is pushed or (2) docker desktop is uninstalled (3) the user manually doeswsl --unregister docker-desktop-data.- did any of the above happen?
- Because you no longer have a
docker-desktop-datadistribution (which possibly held your previous data), Docker Desktop switched to the "mono distribution" architecture, which no longer uses a second WSL distribution for storing data, but a plain virtual hard disk (VHDX) on your file system.
If you have a backup of your original data distribution it may be still easy to recover your data, if that's the issue you are facing.
(1) the factory reset button is pushed or (2) docker desktop is uninstalled
Yes I did do a restore factory defaults. It seemed like the only option given it would not run while Podman was open and I didn't know the cause at the time. Can you please help me understand a good reason to wipe volumes and images initiating factory default? I don't see any reason. I am also somewhat sure the warning was not clear enough this would happen, or I just assumed some type of default in my head.
Hey,
I am really sorry about that.
The current "factory reset" workflow does have a message that says that it would destroy all containers and images, but I take the feedback that the UI could be more aggressive in highlighting the consequences of the action.
Factory reset is intended to bring back Docker Desktop at the same stage it would be after a fresh install. For this reason it includes wiping all the content that did not come "from the factory".
Because I am unable to recreate the Podman Docker collision I am unable to check what warning I saw and as such I also do have a suggestion,
If the Reset dialoague is the same as above after this error "Something went wrong. Starting services: initializing Docker API Proxy: open .\pipe\docker_engine: Access is denied." I have the options "quit", "diagnose & feedback", and "reset Docker to factory settings."
I have suggestion to improve it to account for the seriousness of the action about to take place:
A factory reset does the following:
●Destroys all Docker containers
●Destroys all images local to the machine
●Restores the application to its original state, as when it was first installed.
Type your password below to proceed.
<text field>
Your message came in just as I was typing this one up
Thanks for the clarification.
You're right: in case of the recovery dialog below there's no explicit mention on the fact that factory resets deletes all the user data. I agree Docker Desktop should be much more clear about that in this specific workflow - thanks for pointing that out.
must be fate then, this might be my most useful contribution to open source so far, have got to start somewhere I guess.
Can you please help me understand a good reason to wipe volumes and images initiating factory default? I don't see any reason
I was hoping I could get response to this please so I can understand more about how software system should or is expected to work. or if such such drastic measures are not fully necessary maybe can we get tick boxes or options flow to reset different parts of docker as with my case where I wanted all the settings to be default of the Docker core system and not really anything I had within it.
@ambhaiji: I believe wiping out all data is standard practice for factory reset (think, for example, at modern phones). The intention is to put back the system at the initial system conditions.
As said, we are taking your feedback very seriously and we are working on a better UX around factory reset, warning users about the implications more clearly and explicitly.
@andrea-reale yes but all modern systems have options to reset all settings without touching data. Windows itself allows you to reinstall windows while "your apps, files and settings will be preserved". The key benefits of containerizations is that since everything is segregated we can reset parts of the system in pieces to debug in a sense what needed to be reset to get things working again.
As said, we are taking your feedback very seriously and we are working on a better UX around factory reset, warning users about the implications more clearly and explicitly.
I would be happy to be a part of this discussion if you would like me to.
Similarly, this error message does not alert the user that a factory reset will delete all data.
It was triggered by a windows update and was resolved by running wsl --update --pre-release.
Unaware of the consequences, I tried factory resetting. This deleted data that I thought was saved to an external location, was not. And was months of important collected data which cannot be recreated. I think by nature of the windows update, my windows restoration point is also no longer available which could have recovered most of the data.
