Working with .img files with the Jetson

I’m wondering how I might create a carbon copy of my current Jetson board as an .img file or something like that. That way, I can easily flash it to a new board and not have to re-install everything. Is that possible?


I’ve already “almost” done this. To elaborate, the system.img created while flashing is a carbon copy of what will be installed during the flash…it’s a loopback mountable ext4 filesystem. E.G., “mount -t ext4 -o loop bootloader/system.img /mnt”.

I’ve personally created a customization directory tree, which is nothing more than files to copy using the same structure as rootfs. So if I unpack rootfs, I then just recursively copy my files from custom tree onto this tree preserving permissions…all permissions must be set correctly (these files could be copied onto the loopback mounted file system as well). Examples of files copied are that I have a customized .bashrc, my network files in /etc/network/ are pre-set, my /etc hosts file is edited, so on. What this does is allow me to unpack rootfs anywhere, and then just copy my edits onto rootfs…any img created immediately has all customizations. I’ve used this loopback mounted for cross-compiling…works quite well using the gcc-linaro tool chain.

The part I did not succeed with yet is that of package upgrade. My host is fedora, but I suspect this wouldn’t change a lot for ubuntu hosts. To directly update packages on loopback, there are three choices: (1) Have a copy of edits just like my other files (very impractical), (2) create a cross-apt running on x86 picking up packages for ARM and chroot into loopback (I only partially succeeded here, takes a lot of time), or (3) use QEMU with this loopback. Choice 3 seems to be the only practical solution, but I don’t know enough about QEMU and never got this to work. I was actually closer porting a cross-apt tool, but so much of this tool is hard coded to ubuntu structure that chroot of everything is a nightmare. So what I was left with is that it is easy to create a rootfs clone and have it updated from file customization tree…this part is very easy.

In order to create the system.img, one would have to actually flash the system, as the script did not separate out system.img completely. To make this easier, I created a subset of the L4T R19.3, which can’t be pasted here because of characters in it (sorry, I don’t have a URL I can post it on). This script comments out some lines and then completely cuts all lines after the point where system.img is created. I’m sure it could be tuned a lot, some parts which are left over are not needed.

I do wish nVidia would incorporate the ability to generate system.img separately (my script is basically just a cut of theirs), which would aid cross compiling. I created a script, but I have no server to put it on and pasting it here will not work due to the characters in the file intefering with forum code (can’t escape these characters). Kind of frustrating, I wish I could attach a file here in forums. In any case, the result is that I can flash my system at any time and it comes back 100% (other than package updates) as I had it before…and if I want to cross compile, I don’t really need to set up a special environment, everything is already there, it just works. This dramatically cuts down the time it takes to develop on nVidia systems using L4T.

It’d be awesome to have your script-- maybe Google Drive or Dropbox? Then people on the forum could share system.img files for other people to try out. It’d also probably help the people making Jetson clusters…

I’m willing to post the file, but I hate spam with a passion. I’m guessing if I use Google Drive then making the file public would link my email. What are the possibilities without spam?

If nVidia were interested this would be ideal…it’s just an edit of their existing script, and if separated out, the original script would be more flexible. It certainly doesn’t hurt their marketing to have instant snapshot clones of their environment available.

As a test, I uploaded the existing script to, which doesn’t require login/email

It seemed to work ok for the ~35KB script.

Eventually, with your permission your cloning script could be hosted somewhere permanent (like the wiki for example), but for now perhaps filebin will work for initial testing. I for one would save a lot of time being able to clone!

My version is just nVidia’s with edits, it contains their original licensing, as required.

Take a look in a diff program to see them side-by-side. I’m sure there are parts which could be further cut out. Put it in the same directory as Creates system2.img so it will not overwrite’s version. Takes pretty much the same arguments as the original script; in some case items like boot options may matter if it populates /boot differently with those options, or if it in some way changes boot.

Also remember that once an image is created, you can edit that image mounted on loopback; the advantage of this script is that image creation is not tied to flashing.

Thanks, I was able to use the script to make system2.img and mount it in loopback. However what I really would like to achieve is copying the system.img back from an existing Jetson, so I can have all packages already preinstalled, not worry about cross-compiling, ect. I was poking around the surprisingly well-documented nvflash tool to see if this may be possible:

./nvflash --cmdhelp --read
Nvflash 4.13.0000 started

--read command usage ->
nvflash --read <N/pname> <filename> --bl <bootloader> --go
used to read partition N/pname from already flashed device into filename
Partition number N can be found from cfg file used for flash earlier or
Partition name(pname) can also be used as an argument

As the help indicates, included in my flash.cfg (left over from flashing the Grinch kernel), is the system.img partition (number 9)


The command I will try is:

sudo ./nvflash --read 9 system_backup.img --bl fastboot.bin --go

Ok, it did seem to work:

sudo ./nvflash --read 9 system_backup.img --bl fastboot.bin --go
[sudo] password for gecuda: 
Nvflash 4.13.0000 started
chip uid from BR is: 0x340010017408c1431c000000140185c0
rcm version 0X400001
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x81
   chip uid: 0x000000017408c1431c000000140185c0
   macrovision: disabled
   hdcp: enabled
   jtag: enabled
   sbk burned: false
   board id: 375
   warranty fuse: 0
   dk burned: true
   boot device: emmc
   operating mode: 3
   device config strap: 0
   device config fuse: 0
   sdram config strap: 3

RCM communication completed
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: fastboot.bin
- 900496/900496 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
Receiving file: system_backup.img, expected size: 15288238080 bytes
/ 15288238080/15288238080 bytes received
file received successfully
Time taken for flashing 2436 Secs

Make sure you have enough disk space before running, otherwise might take you twice as long (like me) ;)

Then mount & inspect the backup image:

sudo mount -t ext4 -o loop system_backup.img /mnt

I saw my edits (made post-flash on the Jetson) in home/ubuntu and also etc/network/interfaces, ect.

Then if you want to reflash the cloned image to a Jetson, use’s ‘-r skip building and reuse existing system.img’ flag:

sudo umount /mnt
sudo rm system.img
sudo mv system_backup.img system.img
cd ../
sudo ./ -r jetson-tk1 mmcblk0p1

If you want a full backup, just loopback mount your system.img and run rsync from Jetson to the system.img on loop.