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

Unknown Error Code '125' on Windows and macOS #933

Closed
apyrgio opened this issue Sep 26, 2024 · 4 comments
Closed

Unknown Error Code '125' on Windows and macOS #933

apyrgio opened this issue Sep 26, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@apyrgio
Copy link
Contributor

apyrgio commented Sep 26, 2024

This bug affects new Dangerzone users on Windows and macOS, who have done a fresh installation of Docker Desktop 4.30.0 or greater. We believe that almost all of our new users after August 29th are affected.

Explanation

Docker Desktop 4.30.0, released in August 29th, introduced the following breaking change:

Fresh installations of Docker Desktop now use the containerd image store by default.

When Dangerzone attempts to load its container image tarball in an installation which has enabled the containerd image store, then Docker will report a different image ID than the expected one:

Expected: 099204f90b54
Got: c0865729b351

Dangerzone will fail the container image installation, and subsequent conversions will fail with error code 125.

Workaround

A workaround in this case is to disable the containerd image store from the Docker Desktop settings. This does not pose any security risk or loss of functionality for the Dangerzone users.

docker_desktop_workaround

Open Docker Desktop, go to Settings (gear icon) -> General (scroll down) -> Unselect "Use contained for pulling and storing images" -> click on "Disable containerd" in the pop-up window -> click on "Apply & restart".

Follow this issue for updates and an official fix.

@apyrgio apyrgio added the bug Something isn't working label Sep 26, 2024
@apyrgio apyrgio self-assigned this Sep 26, 2024
@apyrgio apyrgio pinned this issue Sep 26, 2024
@spkerber
Copy link

Confirming that this update worked for me! Thank you + much appreciated!
Easier than stashing the terminal command for each use.

apyrgio added a commit to freedomofpress/dangerzone.rocks that referenced this issue Sep 26, 2024
New Windows / macOS users will be affected by a recent Docker Desktop
change, and Dangerzone will not work until they change a specific
setting.  Add this announcement in the downloads page, to let people
know sooner.

Refs freedomofpress/dangerzone#933
@charginglabrador
Copy link

Unfortunately, this workaround hasn't worked for me. When I went to the settings, containerd was already disabled. I tried re-enabling, restarting Docker, and then disabling and restarting, but with the same outcome.

@apyrgio
Copy link
Contributor Author

apyrgio commented Sep 30, 2024

Good to know @charginglabrador. I think you're bit by an extra issue actually, check out my comment here: #919 (comment)

@apyrgio
Copy link
Contributor Author

apyrgio commented Oct 1, 2024

We're happy to inform you that we have released Dangerzone 0.7.1, which should fix this problem on Windows and macOS platforms. Try it out, and let us know if something is amiss.

apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 2, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
apyrgio added a commit that referenced this issue Dec 4, 2024
Revamp the container image installation process in a way that does not
involve using image IDs. We don't want to rely on image IDs anymore,
since they are brittle (see
#933). Instead, we
use image tags, as provided in the `image-id.txt` file.  This allows us
to check fast if an image is up to date, and we no longer need to
maintain multiple image IDs from various container runtimes.

Refs #933
Refs #988
Fixes #1020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants