Container failed to download image

Hi,

I’m trying to deploy a multicontainer application using balena cloud. One container works perfectly, the other one returns me this on Logs.

Failed to download image 'registry2.balena-cloud.com/v2/63bc54de394912e45076055c18f5d066@sha256:235789b14b043fd0fd76795b965ed349f264113403fc7bf888fbfb11dca120ea' due to '(HTTP code 404) no such image - no such image: registry2.balena-cloud.com/v2/63bc54de394912e45076055c18f5d066@sha256:235789b14b043fd0fd76795b965ed349f264113403fc7bf888fbfb11dca120ea: No such image: registry2.balena-cloud.com/v2/63bc54de394912e45076055c18f5d066@sha256:235789b14b043fd0fd76795b965ed349f264113403fc7bf888fbfb11dca120ea '

Thanks

Hi, could you enable support access and share the device’s UUID?

Grant support access enabled for 12 hours. This is the devic UUID 979852d09b4e14bcc26a991d5b1fdd14

Hey I took a look at the device, and the supervisor has went down, and refuses to come back up as avahi, which it relies on is refusing to start. I’m investigating now, and will let you know when I find out why this has happened.

So the root cause was that your data partition filled up. I did a little investigation to try and see what exactly was taking the space. Most of it is from the docker diff directory. There’s two reasons that this could happen.

The first is that one of your containers is writing to it’s filesystem in a location not mounted as a volume. This would then cause a diff to be created with this data, and it isn’t always removed (I’m thinking the supervisor should be able to detect and remove these but I’m not sure).

The other reason would be that the balena daemon sometimes leaves dangling diffs, and it’s also not clear the situation in which this occurs.

I’ll fix up this device, but you should investigate whether your containers are writing to somewhere that’s not a volume.

1 Like

Thanks a lot. I’m actually investigating

How large is your image? Whilst monitoring your device after the fix, the balena daemon crashed and the disk was full again. I’m wondering if the size of the delta is causing this.

Actually I have a 16GB storage with 2 containers, one is about 700MB the other one 1,09GB

Hi, can you enable support again, so we could check the device once more? Maybe we find something else being off. Thanks!

I’ve enabladed the support again

Hi,

We can’t seem to see the device. Is the uuid 979852d09b4e14bcc26a991d5b1fdd14 ?

Regards
ZubairLK

I’ve formatted, the new UUID is cfaaff4c9da054bce67d9e9085b672fc

It seems like the data partition is only 1gigabyte. But it should have expanded to fill the disk which is 16gb I think

Hi,

can you please share with us what this 16GB storage device is? Manufacturer, model, … even a link will be helpful.

Thanks.

It is a USB 2.0 pen drive. I have used just for test while i’m waiting for a real intel nuc target

@aromano Ah. I didn’t realise you were booting from an external USB.

If I remember correctly, the script that expands the resin-data partition does not expand the partition on externally plugged usb drives.

If its easy for you, plug out the usb, expand the resin-data partition to fill the rest of the disk using a tool like gparted.

Alternatively, you can do this on the device itself. There are some instructions here for the pi3. But they should be applicable to the NUC as well. Raspberry to run resin.io from Hard disk

Regards
ZubairLK

Perfect, thanks