Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No images in docker images after snap install dive #546

Open
pjonsson opened this issue Aug 10, 2024 · 4 comments
Open

No images in docker images after snap install dive #546

pjonsson opened this issue Aug 10, 2024 · 4 comments

Comments

@pjonsson
Copy link

pjonsson commented Aug 10, 2024

I was trying to get a better understanding of what was taking space in a local image, so I ran docker inspect ... just before installing dive through snap, and after doing snap install dive my images in docker images were gone.

The snap install dive downloaded something and then entered some "configuration stage" (don't recall what it said, but the terminal replaced the line with dive 0.12.0 from Guillaume Belanger (gruyaume) installed when it completed) that took quite a long time. I had 30-40 images, so the time in the "configuration stage" is on par with how long it would take to delete the images with docker system prune.

I do not have Docker installed through snap, I'm using the Docker deb packages from Docker.com on Ubuntu 24.04, currently with Docker 27.1.1. I also only have the default Docker context.

$ snap info dive
name:      dive
summary:   A tool for exploring each layer in a docker image
publisher: Guillaume Belanger (gruyaume)
store-url: https://snapcraft.io/dive
license:   MIT
description: |
  Dive is a tool for exploring a docker image, layer contents, and
  discovering ways to shrink the size of your Docker/OCI image. To learn more
  about dive, see https://github.com/wagoodman/dive.

  **Usage**

  Install the Docker and Dive snaps and connect them:

     sudo snap install docker
     sudo snap install dive
     sudo snap connect dive:docker-executables docker:docker-executables
     sudo snap connect dive:docker-daemon docker:docker-daemon

  Run `dive`:

     dive ubuntu:latest
snap-id: MudyYZqdJlVtqfObbi6wN5bOzZM7JKft
channels:
  latest/stable:    0.12.0 2024-03-03 (20) 7MB -
  latest/candidate: 0.12.0 2024-03-03 (20) 7MB -
  latest/beta:      0.12.0 2024-03-03 (20) 7MB -
  latest/edge:      0.12.0 2024-03-10 (26) 7MB -

It seems @RafaelWO had the same problem a couple of weeks ago:

Originally posted by @RafaelWO in #542 (comment)

@thowbikdustan
Copy link

thowbikdustan commented Aug 11, 2024

Hi Team, Same Issue here. My Images got deleted after install drive through snap And also all the containers in the which are running in process

@pjonsson
Copy link
Author

I started getting permission denied errors when doing docker compose down. Turns out that is caused by AppArmor. After some more digging, it turns out I had somehow gotten docker through snap, which mixed with the Debian docker packages from Docker.com that I want to use:

# docker info
Client: Docker Engine - Community
 Version:    27.1.2
 Context:    default
 ...
Server:
 Containers: 6
  Running: 5
  Paused: 0
  Stopped: 1
 Images: 16
 Server Version: 24.0.5                <<--------------------- THIS
 ...
# snap list | grep docker
docker                     24.0.5           2915   latest/stable    canonical**     -

Removing the snap-installed docker killed my running containers, and then ran tar+gzip for half an hour:

# snap remove docker
2024-08-19T14:22:10+02:00 INFO Waiting for "snap.docker.dockerd.service" to stop.
Save data of snap "docker" in automatic snapshot set 3

until it finally said docker removed, so I guess I should have run docker system prune -af --volumes to remove my docker images+cache+volumes before asking snap to remove docker. While snap was running tar+gzip, docker info looked like this:

Client: Docker Engine - Community
 Version:    27.1.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.16.2
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
errors pretty printing info

So suddenly getting a new containerd when doing snap install dive explains why the images disappeared. It would be nice with a big warning both in the README and in the dive-snap-package that it's not "compatible" with the upstream Docker packages.

@YuanfengZhang
Copy link

YuanfengZhang commented Sep 5, 2024

it's a disaster without any warning. I got traped too. The snap approach is not fully tested and should get removed from the README.md.

The after-trap solution is:

  1. disconnect, then remove the stupid snap pkgs:
sudo snap disconnect dive:docker-executables docker:docker-executables
sudo snap disconnect dive:docker-daemon docker:docker-daemon
sudo snap remove dive
sudo snap remove docker
  1. kill all docker associated processes:
sudo systemctl stop docker
sudo pkill -9 -f docker
  1. restart the docker deamon process:
sudo systemctl restart docker
sudo nohup dockerd &

And, never try snap approach again, if your docker is installed by apt-get.

YuanfengZhang added a commit to YuanfengZhang/dive that referenced this issue Sep 5, 2024
@Hawxxer
Copy link

Hawxxer commented Oct 7, 2024

+1 how to push this issue more? It's not self explanatory that it requires docker installed via snap (who does this anyway?) and it just install it without asking (Or did I miss this? I did not install it with 'snap install docker'). @wagoodman

joschi added a commit to joschi/dive that referenced this issue Nov 6, 2024
wagoodman#546 demonstrates the trouble it may cause.

Co-authored-by: Zhang Yuanfeng <[email protected]>
joschi added a commit to joschi/dive that referenced this issue Nov 7, 2024
wagoodman#546 demonstrates the trouble it may cause.

Co-authored-by: Zhang Yuanfeng <[email protected]>
joschi added a commit to joschi/dive that referenced this issue Nov 7, 2024
wagoodman#546 demonstrates the trouble it may cause.

Co-authored-by: Zhang Yuanfeng <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants