Embedded Linux based devices often require a mechanism to update applications and system files. For example, a (non-networked) lab instrument with a USB port can get software updates from a USB stick.
It would be a simple matter to run a script to copy files into place on the device's internal flash memory. However, there is the danger that the device would lose power in the middle of the update, and end up a brick.
The situation for application files is a bit easier since there is room to duplicate the application directory, update one copy, and quickly swap old and new directories minimizing the failure window.
Things are dicier for kernel and system files since they are spread out throughout the file system.
We have used hard and soft links in the file system to identify critical files. We use hashes on files and archives to verify file integrity. We have considered using an emergency ramfs in the kernel to provide a fallback if starting from the updated file system fails.
What are your approaches to this requirement?
Best Solution
I would go with the same approach as with the application files: Make for the critical files and complete own partition, link to them, and duplicate the partition. In all of your init you should as first check if the links show all to the same partition, if not, reset them (to the partition with the files with the newest date of a certain file). If you want to update just copy everything onto the new partition, and if everything is fine (crcs ok) loop over the files and set for each the link from one filesystem to the other.
This way your critical files should be always be in sane state.
Scenarios:
Update fails while copying files onto new partition
No Problem because the links show still to the old working ones.
Update fails while linking
No Problem because all new files are valid and already copied (else the relink step wouldnt have start), setup check correct this