Hello duelingcats,
To reduce the size of your image, you can take a look to our `shrink_image.sh` script which you'll find in our ImageBakery repository:
https://gitlab.com/revolutionpi/imagebakery. This script was designed specifically for this purpose and it reduces the image size by removing unused space and adjusting partitions to the minimum required size.
The script performs the following main operations: mounts the image, removes the machine-id file to trigger the firstboot service, checks filesystem integrity, shrinks the ext4 partition to the minimum necessary size using resize2fs, adjusts the partition size with parted, and finally truncates the image to the new size. This can significantly reduce flashing time.
The automatic filesystem expansion on first boot should be triggered after removing the file machine-id. This script was used in our images up to Bullseye.
Regarding your second question about revpi-factory-reset, what it actually does is initialize the RevPi hardware by loading the necessary device overlays and changing the password. It also resets the hostname based on the device's serial number, but doesn't affect the MAC address as this is stored in the HAT EEPROM. (See here:
https://gitlab.com/revolutionpi/revpi-t ... type=heads)
However, I don't like copying images and using them on different devices
This approach means all hostnames will be identical initially, and certain certificates that are generated the first time the system boots may cause issues. While this method might have worked well in the past and could still be acceptable for some RevPi deployments, I honestly believe there are better tools available for system provisioning that can create cleaner setups and replicate the same environment across different RevPi devices much more effectively.
Tools like Ansible, for example, allow you to define your system configuration as code and deploy it consistently across multiple devices while ensuring each device maintains its unique identity (hostname, certificates, etc.). This approach is more scalable, maintainable, and avoids the potential issues that come with cloned images. You start with a fresh RevPi image on each device and then use configuration management tools to install and configure exactly what you need.
What particularly bothers me about the image cloning approach is that sometimes, when an issue arises, a new image needs to be generated, and this new image... must be reinstalled on all the systems? If one device is located remotely, this becomes a significant problem requiring physical access or on-site intervention. If you can do an update, there shouldn't be much of a problem... but I still think something like Ansible is better, for example. With just one command, you can update one device, several devices, or just a few... Having these options can save you a lot of headaches in the future.
If you still prefer the image cloning approach, you can use Win32 Disk Imager to create the image of your configured system, apply the shrink_image.sh script to reduce its size, and then flash this reduced image to other devices. I do not like it... but it should work. After the first boot, each device will have its own unique hostname based on its specific serial number, but will maintain all your software configuration.
I recommend testing the reduced image on at least one device before proceeding with mass flashing to ensure everything works correctly.
For reference, our latest image is the RevPi Bookworm 64-Bit from November 2025 (
https://revolutionpi.com/en/support/downloads#c1069), and we're already working on Trixie images for future releases. After launching trixie, we will no longer support Bullseye, so I recommend using a recent system.
Good luck!