I was wondering what tweaks I could make to an image we flash onto our units to speed up the first boot.
The main documented one is preloading which does help quite a bit and the steps to do it work fine and I have an image which is pre-loaded. Excellent.
I noticed however on the log’s it would apply one boot config and reboot. Then apply the boot config with our application’s boot configuration and reboot again.
I found by flashing the pre-loaded image, then copying in the config.txt file off an initialised unit that has the settings pre-applied did save one of the reboot steps.
Are there any other possible tips or tricks to speed up the first boot process slightly more? Or are the above two parts mostly it?
The initial boot you mentioned resizes the image to fit the SD card. So, I would make sure that I did this with another SD card of the same size.
I think the methods you mentioned are the low hanging fruit, and I can’t think of anything off the top of my head that would increase the initial boot speed by a significant amount.
Can you tell me what your use case is that your require such a fast initial boot time, or are you just trying to reduce initial boot time out of convenience?
We’re going to be shipping Balena on a product and as part of the production process have to boot each unit up for first initialisation along with getting a mixture of serial numbers off the device once it’s booted and initialised.
I don’t need to massively cut down on boot time, just was more any major things to do to speed it up and wanted to confirm the config.txt trick was suitable.
I did consider re-sizing the SD Image but that would then involve increasing the image from 1.7GB to 30GB as we’re using the CM3+/32GB , Roughly 28GB of dead space would need to be added and I would say t that point the time to flash the image would take longer than the boot up time.
Thanks for that feedback. I wanted to confirm that setting the config.txt on the image is one correct path to skipping the reboot as you discovered. The supervisor will take values in config.txt and push them as updated device configuration variables to the cloud when they differ.
Depending on what steps are performed during initialization of the device, you might want to check pre-register of devices, you could pre-register and pre-load devices during manufacturing and let them perform initialization on first boot. You can learn more about pre register here Going to production - Balena Documentation
That being said, we are continuously working on improving our product to be aligned with our customers manufacturing workflows, so this feedback is extremely valuable.
I did consider getting the details via the Balena API however during production we need to also print out some of those details on a label for the unit.
The best combination I came up with to resolve both issues was that in production we have a Raspberry Pi setup with a USB Ethernet Adaptor setup as a bridge and the unit connects through that.
The Pi runs a python script to then detect the IP of the unit that’s connected and communicate with the service that contains all the information we need.
This also combines so far best from what I can figure out as it also performs a majority of hardware tests to ensure it fully works before going out the door Along with some other steps we’d need to normally do with programming which is all working well with this setup.
Originally I was at about 5 minutes per unit, but with the config.txt tweak and a few others with ensuring a more up to date pre-load I’ve got it to around 3 minutes per unit.