I know the ‘kernel-module-build’ exists but from what I understand, that’s used to create modules that are loaded into the container?
How should I go about compiling the module and loading it into the base ResinOS image? Keeping in mind that the ESP8266 is the sole method of connectivity on the device, and this module would need to be loaded for the device’s first online connect and check-in with resin.io.
The https://github.com/resin-io-playground/kernel-module-build project is exactly how you would go about it - I suspect it’ll take a bit of trial and error to get the hackaday project instructions ported to Dockerfile.template, but should be well doable.
As the binary docker image is build on our build servers when you git push resin master the project, the binary driver and accompanying files would be available on device boot and as the container is running in privileged mode it’ll be able to insmod the custom kernel module without any issues.
Thanks so much for the reply, definitely quelling some fears about my implementation choices.
I would just like one thing cleared up then if possible. From what I understand, the Dockerfile.template would be merged with my main application Dockerfile.template (ignoring multi-container environment for now) and pushed up to your servers with git push resin master. The container that’s downloaded to the device would then have the binary module inside it that can be insmod’d into the base resinOS.
If that’s the case, wouldn’t the device require an internet connection to pull down the first main application container (Chicken before the egg, ESP8266 wifi/internet before the container)? Or am I misunderstanding something in the previous paragraph?
And if this is the case, would a suitable fix be to do the first pull with a device that does have internet, then create a clone of the SD/eMMC and use that for all future devices?
Oh yeah … that is indeed a lovely chicken and the egg problem. There are some work arounds you could try.
One would be to do as you suggest and booting it up and having the image loaded on a different device. Another option could be to mount the SD card on a linux box, add the binary module to the resin base os, and depend on that for the first boot. If you go the second route, those changes would be lost when ResinOS is updated so it would be a one-shot kind of thing.
With WiFi being critical path, I would recommend doing lots of testing of new app updates if you decide to use this at scale.
Ok great, then it seems the first option is the better option to avoid the ResinOS version lock. I guess there’s just one last thing I’d need to know, at the risk of being off topic.
When it comes to cloning an SD which has ResinOS on it that’s already done the first boot and has a pulled container, will writing that cloned image to other devices be fine or is the Device UUID somehow hardcoded into the image?
@keab it won’t be fine, as your “device” is really the config.json on the device. If you just clone the device, and boot it up elsewhere, then two hardware tries to be the same device.
Also, after the first boot, the resin supervisor’s database already has some entries, and it would probably misbehave, if that database wasn’t cleared.
download the resinOS image from the dashboard (it’s unconfigured)
user resin preload to add your current application Docker image (or a specific release if you don’t want the current) to the OS image.
if you burn that card multiple times, and plug it into different Raspberry Pis, they will come up as different devices, and all have your application running from the start, not downloading anything.
