Failed to download image in microservices app


I am using a microservices type app, in a Raspberry Pi 3. The version of the ResinOS is 2.12.5+rev1 (prod).

I pushed the images to the app using resin deploy app_name (where a docker-compose.yml exists), and the images started to download in the device.

  • First question: I am using the fleet var: “RESIN_SUPERVISOR_UPDATE_STRATEGY”: “kill-then-download”. However, the downloads started but the services didn’t stop: only when the image has been downloaded, the service is stopped and then installed. Shouldn’t services be stopped and then download and install the images?

Because of memory issues, the device was rebooted (while some of the images were being downloaded) because of the functionality of one of the services (using the supervisor API). At the end, all the images has been downloaded and installed, but one of them seems to be blocked: it tries to download the image all the time, and the following error is printed on the logs screen:

Failed to download image '' due to 'failed to register layer: open /var/lib/docker/aufs/layers/XXXXXX: no such file or directory'

  • Second question: whan can I do to repair that error?

Thank you!

Hey @jcozar

The second error that is shown implies that the docker directory has become corrupted. The easiest way to deal with this (if you don’t mind redownloading your application containers and the supervisor container ) is to run the following on the host OS:

systemctl stop resin-supervisor
systemctl stop balena
rm -rf /var/lib/docker/{aufs,containers,image,tmp}
systemctl start balena
systemctl start resin-supervisor

For the second error, I believe @pcarranzav will be able to provide more context.

Hi @jcozar! In resinOS 2.12.x (with resin-supervisor 7.x), update strategies are defined per-service, so they’re no longer defined with configuration variables. Instead, you’ll need to use an io.resin.update.strategy label in your docker-compose.yml. Docs:


thank you very much @CameronDiver! I tried your commands and it worked perfectly.

And also thank you @pcarranzav! I misunderstood the doc: I though that both possibilities (using the label and using the device conf var) were possible in microservices apps. I like this approach more because you can set the strategy individually, but just as a first trial I used (incorrectly) the device conf var approach.