Hello duelingcats,
Great to hear that you are preparing a clean deployment strategy for your RevPi Connect 4.
You are right, some details have changed since the original post about cloning images. Specifically, regarding your question on Bookworm, the file
/home/pi/.revpi-factory-reset is no longer used, and the equivalent reset mechanism now uses the file
/etc/revpi/factory-reset. Removing this file before creating your image will give you a similar “first boot” effect on each device when flashing, but please note that it will not reset everything automatically and you would still need to handle certain device-specific configurations manually.
However, I personally do not recommend cloning an image and using it across all devices. While cloning may seem quick, it often copies device-specific settings that can cause conflicts, skips future package updates or necessary adjustments per device, and creates challenges when managing larger fleets, especially if configurations need to change over time.
For example, when cloning, you will copy the
/etc/machine-id file generated during the first boot of the system, leading to all your devices having identical identities on the network, which can cause conflicts or confusion in device management systems later. To avoid this, you would need to delete
/etc/machine-id before creating your image so that a unique ID is generated on first boot after flashing, but there can still be other side effects that may not be immediately visible during short test phases and can appear later when systems are in production.
One of the cleanest options you might consider is to build your own image using our open repository "debos-build". We use this internally to generate our official images, and you can use it as a starting point to create your customized, versioned images while maintaining a clean and reproducible state for every device you flash. Here is the repository:
https://gitlab.com/revolutionpi/debos-build#debos-build . Using this approach, you can easily track changes, maintain version control, and ensure your devices always start from a known, clean state, even after updates.
Another alternative I personally like is using Ansible or a similar configuration management tool. With this approach, you can flash the latest released image on each device and then use Ansible playbooks to install your packages, configure users, copy necessary files, and adjust network settings across all devices consistently. This way, you maintain a clear, automated process to replicate configurations and can selectively define what settings apply to all devices and which are device-specific, ensuring reproducibility and simplifying future updates across your fleet.
Additionally, although we do not actively support it (and it is not my preferred method either), it is worth mentioning that you might consider running your application inside a container on RevPi for certain use cases. This approach allows you to separate your application from the base OS, making updates and migrations much easier, and helps ensure consistent deployments across devices while keeping your system clean and your application fully self-contained. Personally, I do not use Docker much but often use LXC containers for certain tasks, which work quite well. It might be worth experimenting to see if this approach aligns with your workflow and maintenance strategy.
I hope this helps... at least a little
Best regards,
RamiGspo
