SOLVED: Downloading Loop Fail - "no space left on device"

Hi All,

I am running a RPI3 on a small SD card 1GB for testing. I got a node container going, but now moving to a python container.

What I found out is the python image, I am assuming using different layers than the resin node test app, is pulling down many new layers causing it run out of disk.

Here is what I am observing:

  1. Device boots up and immediately starts container
  2. Device sees a new update and starts downloading new container
  3. Device runs out of disk and I get this error
    Failed to download application 'registry2.resin.io/basestation/c810c66da821b798fe08b26d793e14e1d635eaaf' due to 'failed to register layer: Error processing tar file(exit status 1): write /usr/lib/arm-linux-gnueabihf/libicudata.so.52.1: no space left on device'
  4. Device cancels and very shortly will try again.

Since this is on a small SD it brings up the question what happens if the device was in the field? Is this something Resin should handle, and if not what do I need to do to dump the old container and free up room, without wiping the SD card?

I saw other related posts such as Downloading fail loop regarding deltas, but a deltas wouldn’t help as we are switching from entirely different images.

Other info that might be helpful:
df output
root@XXXX/# df -h
Filesystem Size Used Avail Use% Mounted on
none 1.1G 1.1G 5.1M 100% /
/dev/mmcblk0p6 1.1G 1.1G 5.1M 100% /data
/dev/mmcblk0p2 295M 240M 36M 88% /lib/modules
tmpfs 487M 0 487M 0% /tmp/resin
shm 64M 0 64M 0% /dev/shm
tmpfs 487M 7.0M 480M 2% /host/run/dbus
none 481M 0 481M 0% /dev
tmpfs 487M 7.4M 479M 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock

Hey @mr337, wow, a 1GB SD is pretty small, didn’t even know you could still find these. This is a cool test :slight_smile: Basically I think the best way to handle this on resin.io would be to use the delete-then-download update strategy detailed here: https://docs.resin.io/runtime/update-strategies/#delete-then-download

This would first remove the current image and then pull the new. It would obviously incur a lot more App downtime than a regular update.

Perfect, I figured Resin would handle it but wasn’t for sure where and couldn’t find in the docs. Worked perfectly.

When we start deploying in field, we def won’t be using 1GB SDs :slight_smile: