Is this even possible? I can do that (sort of ) an an RPi but these TX2 files are much more important and there is only one (at $600 there is only one!!!)
So what do you guys recommend? I have an old model NAS available or I could use a big SD Card, or I might even be able to connect an SATA drive if I could figure out how to power it properly. So media is not the problem but I don’t know how to make a bit-for-bit image of that 32 Gb EMMC. Ideas? How do you guys backup yours?
Thanks.
The simple and easiest way is cp / to somewhere else
you can power the 2.5" HDD from the onboard sata connector and ssd.
not sure of the 3.5" HDD.
But the problem is whenever you backup it will copy all the files so it will take quite long time and the backup image is going to be big.
Cloning is nice since the driver package option to “reuse” can use the clone directly to restore. Plus you can loopback mount it, edit, explore, so on. There is a lot of information on cloning for the TX1 which can be used, though commands differ from TK1:
[url]http://elinux.org/Jetson/Cloning[/url]
For commands on TX2:
[url]https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/[/url]
Figures it would not be simple. :) Do we need to go into single user mode for the above to work? How do we do that on the TX2 since we can’t get into the boot partition?
I was hoping to boot via, say SD Card, then run a simple image maker like ‘dd’ or somesuch. Kind of like “Redo” on desktops. (But Redo doesn’t know how to do the very newest PC’s with nvme as boot drives.)
I’m kinda lost re the requirement to “flash.” Is there a separate EMMC area or separate EMMC just for booting? I don’t know TX2’s boot system.
The next time a new Jetpack comes out, and you’ll want to upgrade the OS to a newer version, you will want to do it by flashing from scratch, which will nuke everything on the board.
If you do development on Jetson, I would recommend using proper configuration management and source control. For example, put everything you develop into a git repository, and install any third party packages using some install tool rather than straight from the command line. (Even if it’s just a list of “things-to-install” and you install the with “apt-get install cat things-to-install”)
In general, you should be able to re-flash the Jetson from scratch, add a couple of files from backup (your “things-to-install” file and SSH keys) and then be able to recover your development environment automatically. In fact, I highly recommend doing this manually, “just because,” every month or so.
IMHO:the best would be dd if=/dev/mmcblk0 of=path to external e.g usb hdd
Andrey, that would be the simplest IF we could get into single-user mode or one of the other 6 levels besides multi-user. While in multi-user mode, there are many files open and we will get the filesystem marked as corrupt. Not to mention what actual data may be lost but at least that is unlikely if you plan properly.
That would work very nicely if we could boot by some other means and have the OS exist only on ramdisk and not using the emmc at all.
IMHO Force recovery mode mounts eMMC to HostOS
I think it would be appropriate to make a raw image.
Moreover, I think it could be remounted as ro or rw or whatever mode.
Some basic info: eMMC is the solid state hard drive. Normally the first partition serves as the root partition for Linux. Many other partitions follow this, but they are hidden partitions used during boot. A normal flash to a JTX2 on command line would use the “-S” parameter to name root partition size. The maximum root partition (least waste of disk) on a JTX2 would be this if done manually without JetPack:
sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1
As mentioned above by @Andrey1984 you must be in recovery mode to flash a Jetson. Kernel and module updates under U-Boot do not require flash, they’re just file copies. Being in recovery mode or entering recovery mode has no risk, you won’t do anything to the Jetson unless the driver package is run (the flash.sh file or JetPack). When in recovery mode your Jetson becomes a custom device and the flash.sh program is the driver for that USB device (JetPack is a front end to flash.sh and other optional operations).
In that above command mmcblk0 represents the eMMC disk. mmcblk0p1 represents the first partition of eMMC. An SD card would be mmcblk1, and the first partition of an SD card would be mmcblk1p1. Normally you would not directly name the SD card in the flash.sh command line…instead most people would edit the “/boot/extlinux/extlinux.conf” file to point at mmcblk1p1 on the kernel command line (the “APPEND” key/value pair in extlinux.conf). The difference is that the boot environment remains on the Jetson if you flash to mmcblk0p1 and point the kernel command line at SD card; if instead you flash and directly name mmcblk1p1 (SD) as the install location, then you can no longer boot to eMMC without the SD card being present (some of the boot environment itself shifts to SD card in this latter case).
You can add more than one boot entry in extlinux.conf and select which entry you want if you have a serial console. See:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/
Note that during a flash an exact copy of everything which will go on the Jetson’s root partition is created (your host needs 28GB for that if your partition will be 28GB). This is turned into a “sparse” file (a form of compression) before sending to the Jetson. The flash.sh program can work with either the sparse file or the raw (uncompressed) file system. A clone can be used in place of the generated file system and you’ll restore the root partition if that is what was cloned. Cloning is a long procedure, but steps to do this are actually fairly simple.
Note that if you do an operation on a Jetson in recovery mode (such as clone or flash), then you must restart recovery mode for the next operation (e.g., you cannot clone then flash without restarting recovery mode between clone and flash).
You can of course do ordinary backups using existing purely Linux methods, e.g., rsync or dd. What’s interesting is that if you have a clone you can mount the clone on loopback and update the clone on occasion through rsync from Jetson to host. A clone (or any raw image) can be mounted on loopback and treated as a mounted disk.
This is really no different from what you’ll get if the power fails.
You may also be able to set up LVM and take an LVM volume snapshot that you then image from.
However, I’d like to re-iterate that trying to rely on snapshots for a development system is going to lead to nothing but trouble.
You need to be able to re-create the system from source files, without relying on ephemeral state stored only on the system.
Here’s a way to backup and restore your Jetson TX2.
Jetson/Cloning - eLinux.org doesn’t give any insight into the tool that I must use. It just gives the command but where exactly can I find “flash.sh”?
If you’ve ever flashed with JetPack/SDKM, then this is a front end to the flash software (the “driver package” if you were to install this manually without JetPack/SDKM). When SDKM flashes it will unpack and install to:
~/nvidia/nvidia_sdk/JetPack_...version info.../Linux_for_Tegra/"
The content in “Linux_for_Tegra/” is basically the driver package, and this is where “flash.sh” can be found. If you manually unpacked the driver package, then this would directly provide the “Linux_for_Tegra/flash.sh”.