for several projects, using very resource limited platforms like the RPi Zero, I thought about “sliming down” balenaOS. Essentially, after being setup with the application container, certain types of applications won’t need the balena supervisor with its own node.js powered API and other services - hence these could be removed without any problems - or the vpn connection (especially if its used as local, non balenaCloud enabled system) - freeing up valuable cpu and memory resources.
I wanted to use the oppurtunity to ask if other guys also had that idea and done something in this direction :).
Due to this specializied request, @zubairlk did open up an repo on github to prepare a “trimmer” script which can disable certain services on the balenaOS. You can find it here: https://github.com/balena-io-playground/balenaos-trimmer - maybe we can take this further?
So I’ll describe my own workflow while making the balenaos-trimmer script. I think it is vital to use a development image and have some sort of serial/uart access to the device while working on trimming the OS. Even if the final device needs to use the serial port, that is a separate activity to working on the script.
I personally use the piuart and can recommend it. It is very handy to always have access to the boot console as it happens. I can see the timeouts happen. And can adjust as I go. https://www.adafruit.com/product/3589
On a separate note, you mentioned earlier that the container starts at a ‘random’ time. Can you check dmesg if balenaEngine depends on random initialisation?
also. just to add. I’ve been testing on a pi3b+… Going to try to rummage through the drawers for a pi0… still don’t know where everything is after moving recently.
regarding the pulled release. we found that 2.44 introduced a race condition between supervisor and engine on subsequent reboots, details on it here: https://github.com/balena-os/meta-balena/issues/1748
The fix is already in 2.45.1 and in staging for some device types…
Dear @zubairlk and @robertgzr - is there any ETA for the new release of balenaOS for RPi 1 / Zero? It looks like the current ( BalenaOS 2.32.0+rev1 ) revision is missing the kernel files for the PiCamera, hence it does not work. The 2.44.0 which I still had here seems to be not having this issue
( I guess its the 2.44.0 I got, as the balenaEngine is from October )
Client:
Version: 18.09.10-dev
API version: 1.39
Go version: go1.10.8
Git commit: 7cb464a406748016f2df0c31a9851d20456a3d31
Built: Thu Oct 17 14:28:36 2019
OS/Arch: linux/arm
Experimental: false
Server:
Engine:
Version: 18.09.10-dev
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 7cb464a406748016f2df0c31a9851d20456a3d31
Built: Thu Oct 17 14:28:36 2019
OS/Arch: linux/arm
Experimental: true
after some investigation we found that the issue is a dependency between the userspace camera libraries and the firmware, so a possible solution if it’s urgent for you to use a Raspberry Pi Zero with the 2.32 version of the OS, is to downgrade libraspberrypi-bin and you can do this by adding apt-get install libraspberrypi-bin/oldstable --allow-downgrades -y to your Dockerfile.
Another solution is to use a 2.4x version of the OS which will be available in production in about two weeks, for the pi-zero.
Finally, if you have a raspberry pi 3 you can use that as 2.44 version of balenaOS is available.
