Hi Paulo,
I appreciate you taking the time to investigate here.
I am not so sure the aufs vs overlay2 is my actual problem. The essential idea is i’m just trying to preload an app into an image I have. I may be doing something completely wrong, but the core of what doesn’t work for me is that when the dockerode package in balana-cli creates, then runs the container that will download the app, its can’t find any /dev/loop* devices. If I manually step into the container and using docker run -it --privileged mine /bin/sh run /usr/src/app/preload.py then the script does run and the container does have loop back devices. My problem at that point is that I don’t know what arguments (config.json?) are needed by preload.py in order to inject the app I have into the image.
I hope that makes sense. I feel like I’m digging fairly far into the tooling to see whats going wrong, just not sure how those arguments get injected against the ‘docker run’ command in order to pass it all to preload.py
aufs vs overlay2: balenaOS images use one or the other (aufs for most devices types), preloading an image using the incorrect storage driver will result in the dockerd daemon on the device not being able to load the application.
loop devices: /dev/loopX devices do not exist all the time, they are created by losetup. When you run losetup -f --show resin.img, a loop device will be created for you and should appear in /dev/.
If you copy the image you’re trying to preload in the container, you’ll have to copy it back to the host once it’s preloaded, that’s why it’s bind mounted and not copied.
I wouldn’t recommend trying to run the preload.py script by yourself (even if it’s possible), it has not been designed to interact with humans
But you can use balena preload and modify the Dockerfile in node_modules/balena-preload/Dockerfile, the preload.py script in node_modules/balena-preload/src/preload.py and the script that launches docker and communicates with preload.py in the container in node_modules/balena-preload/lib/preload.js.
Hi @majorz, No I never did get it to work on linux (ubuntu 18.04) or mac. Different errors in each case and I logged an issue in the project on github. Maybe others are seeing it as well?
It looked at least on the mac side related to not running the container as --privileged to get the loopback nodes to be created so the bind mounted OS image could be mounted, presumably for editing the filesystem with the app. Maybe there are some slick sudo commands that need to be passed in to allow for that behavior.
