Deploy Fails - Unable to extract image digest

I’m attempting to create a new release with a command that I’ve been using successfully for the last several years.

balena deploy edo/development --registry-secrets=../../credentials.yml --build --debug

Regardless of what I try, I’ve been getting Deploy failed with the following error…

Unable to extract image digest (content hash) from image upload progress stream for image:
registry2.balena-cloud.com/v2/d408ca4c4855811636fc5c3cefe699d9:latest

ExpectedError: Unable to extract image digest (content hash) from image upload progress stream for image:
registry2.balena-cloud.com/v2/d408ca4c4855811636fc5c3cefe699d9:latest
    at pushImage (C:\Program Files\balena-cli\client\build\utils\compose_ts.js:698:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Promise.all (index 1)
    at async inspectAndPushImage (C:\Program Files\balena-cli\client\build\utils\compose_ts.js:710:42)
    at async Promise.all (index 4)
    at async pushAndUpdateServiceImages (C:\Program Files\balena-cli\client\build\utils\compose_ts.js:739:9)
    at async pushServiceImages (C:\Program Files\balena-cli\client\build\utils\compose_ts.js:748:5)
    at async C:\Program Files\balena-cli\client\build\utils\compose_ts.js:789:17
    at async awaitInterruptibleTask (C:\Program Files\balena-cli\client\build\utils\helpers.js:283:16)
    at async deployProject (C:\Program Files\balena-cli\client\build\utils\compose_ts.js:787:13)
    at async DeployCmd.deployProject (C:\Program Files\balena-cli\client\build\commands\deploy\index.js:146:27)
    at async DeployCmd.run (C:\Program Files\balena-cli\client\build\commands\deploy\index.js:50:25)
    at async DeployCmd._run (C:\Program Files\balena-cli\client\node_modules\@oclif\core\lib\command.js:312:22)
    at async Config.runCommand (C:\Program Files\balena-cli\client\node_modules\@oclif\core\lib\config\config.js:435:25)
    at async run (C:\Program Files\balena-cli\client\node_modules\@oclif\core\lib\main.js:95:16)
    at async C:\Program Files\balena-cli\client\build\app.js:78:13

I’m running this on a Windows 11 laptop. I’ve completely uninstalled/reinstalled Docker, tried going back to HyperV from WSL 2, tried different networks, and all attempted have yielded the same error.

I see this similar post from a couple months ago, but the ‘solution’ was to use Linux, which to me isn’t a valid solution to the problem.

Any ideas?

Edit: If I use a Linux VM I’m able to deploy this release which to me rules out any configuration errors with the release itself.

Hello @adhilton first of all welome to the balena community!

Could you please confirm the version of the balena CLI that you are using in Windows?

Thanks!

Hi @mpous,

Thank you for the response. I’m currently using 20.2.3. I also tested with 20.1.2, which was previously working for me, but that also currently yields the same error.

Thanks!

hi @adhilton , what version of docker desktop are you running on windows and did you recently update it? It sounds like very recently docker has changed the default for docker to start using buildKit for their builds (BuildKit on Windows After Docker Update · Issue #4594 · moby/buildkit · GitHub) this I think breaks our CLI as the underlying library we use to interact with the docker engine doesn’t yet support buildkit. Could you check that buildkit is disabled in your docker engine settings and if it is not could you disable it. It should be possible to do this from the docker desktop engine settings page, see image below:

Hi @shaunmulligan1,

Thank you for looking into that. I’m currently using Docker Engine v27.5.1 with Docker Desktop v4.38.0.

I just tested with the following settings but that unfortunately yielded the same result.

{
  "builder": {
    "gc": {
      "defaultKeepStorage": "20GB",
      "enabled": true
    }
  },
  "experimental": false,
  "features": {
    "buildKit": false
  }
}

Note that in your screenshot, you had buildKit: true. I assume that you meant false, but I went ahead and tested both ways (restarting everything after changes). Enabled and disabled yielded the same results.