Is there a way to configure a partition (e.g. in the flash_l4t_nvme_rootfs_ab.xml) to be persistent with updates?
Alternatively, I would appreciate any guidance on preserving specific data (e.g., located in the /var/my_data/ directory) to ensure it remains unaffected by system updates. If there are any recommended practices or techniques for achieving data preservation during updates, I would be grateful for your insights.
Thank you in advance for any assistance or hints you can provide.
If you have a secondary storage device mounted in “
/var/my_data”, and if the “
my_data” is not part of the operating system directory (e.g., not “
logs” or part of package database, but something custom to you), then updates should never touch this, it isn’t a risk.
What can happen is that an update causes your storage to no longer be mounted there, but that’s a simple fix and it can just be set up to mount again. Even that is not likely to happen as it would mean updating “
/etc/fastab” (although if
udev is involved, the risk of failure to mount goes up).
Are you worried about OTA updates? Or do you mean loss during flash?
Thanks for the fast response.
In my case I do not have a secondary storage device. I am more thinking about specific configuration files that my Application will need and I don’t want to lose when doing a system update (e.g. a/b update).
I could imagine that the data that should not be affected by a a/b update needs to be copied and moved to the other partition when the update is performed. Is there a recommended practice or technique how to do this.
An A/B implies that the same data must exist on both partitions simultaneously. Normally I would say you want RAID 1, which mirrors partitions. RAID 1 tends to read at double to speed of no RAID, and writes about the same speed. However, when two mirrors are operating in degraded mode, there is a performance penalty.
Without a second device or some special scheme to mirror your content (something other than RAID 1), I don’t think there is much you can do. A second device which merely mounts is by far the easiest thing to do.
FYI, updates won’t actually erase anything on your directories in the partition, but A/B mirror is something I’ve not heard of being done (I’ve not heard of RAID 1 across the A/B). You could try it, but that also means that if something makes the A partition unbootable, it also makes the B partition unbootable. So you really must have a second device, or else a scheme to copy from A to B (e.g., via
None of the above are a particularly good choice if you don’t have a second partition to mount.
About the best I can suggest is an
rsync script which allows you to update that content from one partition to another. Then, either manually, or automatically (which might be dangerous to your data during a failure since
rsync will gladly copy bad data), tell the script to mirror from A to B or B to A.
Thanks a lot for the response.
My hope was that I could somehow add a new (update persistent) partition to flash_l4t_nvme_rootfs_ab.xml and than mount it as I need.
Since that does not seem possible, I will probably use rsync.
I just saw that there is a script when using ota that does what I want:
Now I just need to find out if using ota is worth the effort in my project, since my devices probably will not have internet connection once they are on the field.
Regardless of where a backup partition is at,
rsync is the traditional method of such backup. Within Jetsons, cloning is the other method.
Cloning requires the Jetson be in recovery mode and is slow;
rsync only copies actual content and does not copy empty space the way clone does. Also,
rsync is able to detect unchanged content and copy only that which is changed.
rsync works on a running system.
Clone is nice because the image can be used for flashing;
rsync could too, but it would have to be set up with special steps. Cloning is still superior because the partition is read-only during the clone of a system which is otherwise shut down.
rsync is best with the operating system in read-only mode, but normally this is not easy and ends up being used on a running system which is read-write.
As soon as you add an A/B partition redundancy scheme this all goes out the window.
rsync becomes more important, and perhaps you could rsync to the backup partition instead of to some external storage device. I don’t know what the consequences would be though. I think the A and B partitions are matches to each other (aside from partition metadata), and so I think you could
rsync from A to B or from B to A, but I am not positive. Also, if you accidentally
rsync from the wrong one you could end up disabling everything.
Someone else will have to suggest whether OTA in combination with A/B redundancy is worthwhile. I can’t answer that, but if you have
rsync questions, then I can answer. I don’t know how well OTA and A/B schemes work. An external backup is always useful though.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.