Note that any rootfs needs absolute preservation of numeric owner/group IDs, and git is not capable of this. It is the realm of “rsync” to detect filesystem changes (including user/group/permissions), download or update, and preserve permissions. “rsync” works locally or remote. “rsync” can simply list what it finds has changed. This is really what you want.
Your reference copy can exist on your host PC or a server so long as you can guarantee no accidental edits…any edit would probably be from a set of files you’ve developed and then copied into the rootfs reference copy. Cloning or otherwise starting with a current Nano rootfs could be considered a “seed” to start with, but after that you would use it more or less like a version control system for a filesystem.
There are many ways to do what you want via simple scripting of rsync. Flashing on command line via the “flash.sh” tool offers ways to handle this since flash.sh is itself a script which can be modified. Normally JetPack/SDKM would have unpacked the sample rootfs and run apply_binaries.sh to create the “Linux_for_Tegra/rootfs/” content, followed by a few minor edits to the “/boot” content during actual flash. Once that has been created each run of flash.sh ignores further unpacking of the sample rootfs, along with ignoring repeated apply_binaries.sh updates. There is no reason you couldn’t modify flash.sh to update the “Linux_for_Tegra/rootfs/” via some reference copy over rsync.
You really should experiment some with what rsync can do. Some random comments without any particular order are:
- The "--dry-run" shows you what happens without committing to it really happening.
- The "--numeric-ids" preserves numeric user and group IDs, which is critical when mixing things up.
- The single character options can be combined, e.g., "-x" (don't cross filesystems) and "-c" (compress) can become "-xc".
- You can get an idea of what is going on (or redirect to a log using "tee") through the "--info=progress2,stats2"...extra useful in combination with "--dry-run".
- Certain directories would always be excluded, such as ".gvfs" and "lost+found" directories. Example: "--exclude '.gvfs' --exclude 'lost+found'.
- Use the "-c" compression if doing a remote rsync, but skip "-c" for local "same machine" operations.
- An example backup of a home directory to a contrived "/mnt/backup/" location:
rsync -avcrltxAP --info=progress2,stats2 --delete-before --numeric-ids --exclude '.gvfs' --exclude 'lost+found' /home/ /mnt/backup - An example similar operation remotely over ssh, designed for nearly full systems in need of having files deleted before updates are added, performed on a Jetson and placed onto a host with "root" unlocked (non-update files are never touched):
sudo rsync -avczrx --numeric-ids --exclude '.gvfs' --exclude 'lost+found' -e 'ssh' --delete-before / root@YOUR_HOST_IP_ADDRESS:/home/someone/rsync_stuff/ - The same thing in multiline format with backslash trailing lines (hint: This makes it easy to remove or add "--dry-run"):
sudo rsync -avczrx --numeric-ids --exclude '.gvfs' --exclude 'lost+found' \ -e 'ssh' --delete-before \ / root@YOUR_HOST_IP_ADDRESS:/home/someone/rsync_stuff/ - Usually reversing source and destination, but using the same "other" options is the reverse operation.
- The "--numeric-ids" implies you must run as root. Only root has the authority to deal with permissions which the user themself is not privy to.
- For development systems I unlock root, set up ssh keys so I have non-password root login to the Jetson (but no access from Jetson to host PC), and then relock the root password. This results in ssh to "root@the_jetson" working without sudo, but root still cannot be logged into directly as root (only sudo style root operations and ssh to root works). Setting up keys is in fact a very useful way of setting up developers in a commercial environment. The only part here which is unusual is that of unlocking root on Ubuntu long enough to grant access by key. There is some root unlock info here: https://devtalk.nvidia.com/default/topic/1062269/jetson-tx2/cuda-remote-debug-error-amp-problem-creating-executable/post/5379922/#5379922
You should experiment with seeing how to extract, slightly modify and detect, and then restore updates through some small subdirectory which is fast to test on. For example, you could rsync backup the sample applications, and then modify something on the host PC, followed by detecting the change through rsync, or restoring the Jetson to contain the change via rsync. Perhaps there are more file types you wish to ignore, e.g., maybe the “.o” object files of a C compile, and you could experiment with that.