It could be worth trying a few things. Firstly, we could just try to recreate the container. I don’t imagine that would help if the image has been corrupted, but it’s certainly worth a try. Secondly, we can delete the image and have the supervisor redownload it. This should definitely help, again assuming it’s corruption.
What would worry me with these methods is that if it corruption then likely it will happen again, as these tend not to be isolated incidents. Fsck can certainly be used as well, although the success rates for this is typically low.
To remove the container, ssh into the host OS and do
balena ps, finding the specific service id, and doing
balena rm -f <id>. The supervisor should start it back up fairly quickly and you can check the output. (If the supervisor doesn’t immediately start it back up you can restart the supervisor to force a re-application with
systemctl restart resin-supervisor). First see if this fixes the issue, otherwise:
To delete the image, use
balena inspect on the container ID that can be found with the method above, and run
balena inspect <container-id> | jq '..Image' and remember that id (we’ll call it
image-id). Then run
balena rm -f <container-id>, followed by
balena rmi -f <image-id>. Then proceed to restart the supervisor again.
This should give us a decent insight into whether this is corruption or not.