I’m new to a project on the jetson TX2. I need to update de OS but want to make a backup of the full OS + files and apps so that if anything goes wrong i can recover everything. How can I create such backup and how can I restore from it if needed?
There is a way to clone the rootfs, and the clone is useful for more than one purpose (backup is just one of those purposes).
However, you should understand what backup and restore and flash do on a Jetson, which is not like a desktop PC. PCs have a BIOS, but Jetsons do not…they have the equivalent in other software forms. Is it correct that this is an eMMC model? Some developer kits boot from an SD card, and there are important differences between the two (the default full-sized TX2 is an eMMC model). What I’m going to describe differs from the SD card models. Also, the carrier board this applies to is the NVIDIA developer’s kit; third party carrier boards normally have differences (especially in device tree).
For terminology, L4T (“Linux for Tegra”) is what actually gets flashed. This is a generic Ubuntu plus NVIDIA drivers. JetPack/SDK Manager is a GUI front end tool run on the PC for the purpose of flashing (the actual part on the host PC which performs the flash is the “driver package”). On a Jetson you can find the L4T release via “head -n 1 /etc/nv_tegra_release”. This release is generally tied to the JetPack/SDKM release, so if you’ve picked one, you’ve more or less picked the other. You can find L4T and JetPack releases here:
Notice that whichever release you pick, you then end up on the same web page for that pairing of L4T and JetPack. The latest L4T release you can use with a TX2 is the R32.x series.
Official instructions and documents for that release appear at the above URLs.
The eMMC models have a lot of partitions. Only one of those is for the operating system. The label for the operating system is “APP”, and is the rootfs (root filesystem). When you have this cloned, and if you know the L4T release, then it is simple to restore. Cloning and restoring is as simple as running a command on the command line of the host PC when you are in the right directory.
Note that two clone types are generated, and that you can restore from either: The raw clone is a bit-for-bit exact copy of the rootfs. The sparse clone is the same partition, but empty partition space is not included. As the rootfs fills up the sparse clone approaches the size of the raw clone. Raw clones are always large, and although sparse clones are also at least a couple of GB, they can be significantly smaller than the raw clone.
When the flash software is installed on the Ubuntu host PC, there will be a directory, “Linux_for_Tegra/”, located here (which is where what follows is from):
~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/
You do need a lot of disk space. Consider though that your host PC should have a minimum of about twice the size of the partition for spare space, and some more on top of that. It wouldn’t be bad for the host PC (running Ubuntu, typically version 18 for a TX, although version 16 works) to have 50GB of spare space. I throw away the sparse clone since the raw clone can be loopback mounted, examined, modified (e.g., updated via rsync of a Jetson which has changed since the clone), used as a reference during cross compile, so on. A sparse clone can be created from a raw clone if you wish (there is a mksparse tool, and you would use a NULL filler byte for the empty space). Regardless, moving those files across a partition, or copying it to anywhere, will take a very long time due to size. When you flash, then regardless of whether the image is the raw or sparse clone, it will be used if it is named “system.img” and is placed at “Linux_for_Tegra/bootloader/” prior to flashing with the option that says “don’t generate a new image, just use the exsting image” (if you don’t do that it will overwrite the existing image with a newly generated default image).
If you are at “Linux_for_Tegra/”, and if this is an eMMC model of TX2, then clone typically is like this:
sudo ./flash.sh -r -K APP -G my_backup.img jetson-tx2 mmcblk0p1
I will point out that in the “Linux_for_Tegra/” directory, if you run the command “ls jetson*.conf”, then you’ll see a lot of possible flash targets (which are also clone targets). The “jetson-tx2” is just the prefix of “jetson-tx2.conf”. I’ll emphasize that SD card models differ, but for the most part, you can clone or flash any target which has the “.conf” file. That command is run with the correct USB cable between the recovery mode Jetson and the host PC.
Recovery mode is just holding down the recovery button while either turning on power or resetting power. Think of it like the shift key on the keyboard, but it works with the power button. There is no requirement to hold the button down. Recovery mode itself does not modify the Jetson, it only turns the Jetson into a custom USB device understood by the flash software. Because a Jetson does not have a BIOS, it cannot self-flash, and thus the host PC requirement. The “driver package” is the flash software, and is appropriately named because it is the driver to a custom USB device.
The flash command will produce both my_backup.img (a sparse clone) and my_backup.img.raw (the raw clone). If you are in a production environment and want to speed up flash, then you’d “reuse” the image which based on the sparse clone. If you are developing, then you’d either reuse the raw clone (a very long flash), or work with the raw clone, and then create a sparse clone from the raw clone. If you are modifying the clone you might want to make a copy of the raw clone (if the raw clone is 16 GB in size, then it implies you have a very long file copy and will eat another 16 GB of space).
A normal flash puts all of those other partitions in, along with the rootfs/APP. Those other partitions are not modified in normal operation, and tend to be standard. Think of the flash as flashing not only the operating system, but also the bootloader and BIOS. The rootfs is compatible with the non-rootfs content of the same release (it might work with some other release, but is not guaranteed, and will often break; you are advised to flash a clone to a Jetson with the same L4T release in order to get the same compatible non-rootfs content). This is why you only need to clone the rootfs/APP partition.
You can mount and examine the raw clone on the PC. There are a lot of uses for this. An example would be to copy a subset (such as home directory) from the clone to a new system (the new system might be a new release, and thus you can’t use the full clone on the new release due to incompatibilities with other software; but home directories are often not a problem). An example:
sudo mount -o loop ./my_backup.img.raw /mnt
cd /mnt
ls
head -n 1 ./etc/nv_tegra_release
cd -
sudo umount /mnt
The short summary: Put the Jetson in recovery mode with the micro-B USB port connected to the host, run the command to flash. If you wish to restore a Jetson with that, put the rootfs file in as “Linux_for_Tegra/bootloader/system.img” (raw or sparse), and then flash reusing the rootfs:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1
(if you forget “-r”, then a new image will be generated which will overwrite your system.img)
If you install JetPack/SDKM, then the host PC software will be there and set up for you already. This will install the “Linux_for_Tegra/” content and other content. You can flash with the GUI or from command line after that.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.