Cloning TK1 without JetPack and micro USB

Hi all,

I’m a little bit stuck. The micro-USB port on my TK1 is not working and unfortunately it was set up without JetPack. I got a new TK1 but I am wondering how I could clone the broken one to my new one.

Thank you!

Does the Jetson run and is the network available?

The jetson is completely functional and it can be connected to network via ethernet.

@linuxdev I reconnected it to the internet via ethernet and was able to ssh in. Is there a way to make a clone from the jetson?

You should be able to do the equivalent of a clone via dd, or else just copy of files (suitable for using in place of sample rootfs). In the case of files rsync can be used to back up the Jetson to an empty directory on the host or a second hard drive on the Jetson…this latter avoids issues with sudo to an Ubuntu host complicating things (rsync works to a remote host, but your remote host must run the operation as root since files being copied are owned by root…using sudo on both local and remote can be a real pain). This takes only the space of the files themselves.

You can also create a copy of the entire root partition like a clone. This dd version or a normal clone would be suitable for use of “-r” in flash.sh to reuse that clone with exact bit-for-bit partition copy into the new Jetson.

In the case of rsync you’ll want to copy over only files on “real” file systems (if you run “df -T” you’ll see only one partition of type ext4…that is a real partition, the others are pseudo file systems which only exist in RAM). Those pseudo file systems are mounted as subdirectories of the root partition though, so you have to be sure eliminate those if they find a way into your backup.

For both rsync and the equivalent of clone I’m going to assume you have a real hard drive on the SATA port of the Jetson, that it is formatted ext4 on a sufficiently large partition (and for illustration, that partition is sda1). In both cases, from the Jetson:

sudo -s
mkdir /backup
mount -t ext4 /dev/sda1 /backup

For rsync:

rsync -avczrx --delete-before / /backup
# ...verify backup has what you want...
cd
umount /dev/sda1
# Leave the "sudo" shell...
exit

…note that the option “-x” is to stop rsync from crossing file systems. This is important to stop traversing into other mount points, including both the “/backup” directory and the pseudo file systems.

A bit-for-bit exact copy to be used as a raw system.img.raw and “-r” in flash.sh requires knowing what size the file system size currently is. On the running Jetson, if you do this you’ll get partition size information:

sudo gdisk -l /dev/mmcblk0p1

You’ll see something like this in the response:

Disk /dev/mmcblk0p1: 29859840 sectors, 14.2 GiB
Logical sector size: 512 bytes

This means the exact byte size of the loopback image needs to be “29859840 * 512” bytes. This sample is 15288238080 bytes. If you divide this by 1024 as far as possible without fractions occurring, then you’ll know this was the original flash’s “-S” parameter. In this case:

15288238080 / (1024 * 1024) = 14580

…the flash which originally created this was “flash.sh -S 14580MiB jetson-tk1 mmcblk0p1”. If you are able to divide by 1024 three times instead of just twice it would be “GiB” instead of “MiB”. This is the size of which you need to have available on the backup sda1 device.

Assuming “-S 14580MiB”, and having mounted the sda1 partition earlier:

sudo -s
# bs and count are from gdisk -l /dev/mmcblk0p1...
dd if=/dev/mmcblk0p1 bs=512 count=29859840 of=/mnt/backup/system.img.raw
# ...inspect to be sure system.img.raw is exactly the original byte size, e.g., 15288238080 bytes.
# Optionally, verify the image is loopback mountable.
cd
umount /dev/sda1
# exit sudo -s...
exit

Should you choose the rsync method, this replaces the sample rootfs and apply_binaries.sh steps…this alternate set of files goes in the rootfs directory and should have everything needed (the original flash already did apply_binaries.sh, no need to do it twice).

Should you choose the dd method, be careful to not let the system.img.raw file get destroyed. It’s huge and copy to a backup location will take time, but it is worth being careful with that file. Regardless of whether you mount the backup drive directly on your host or copy it via network to the host you want to remove any previous “system.img” or “system.img.raw” from your L4T driver’s “bootloader” subdirectory. Then copy in your “system.img.raw” as name “system.img” (going into that same bootloader subdirectory). You’re ready to flash with the “-r” reuse.

I do not know if you have to explicitly set the size of a “reused” image, but I always do and if it isn’t required it wouldn’t hurt. My example was 14580MiB, perhaps yours was 14GiB…adjust to your situation. You could then flash via:

sudo ./flash.sh -r -S 14580MiB jetson-tk1 mmcblk0p1

…your newer Jetson will be a duplicate of the older one…even partition UUID’s will be the same (simple file copy via rsync may not be an exact duplicate of some of the boot configuration, nor is rsync copy a way to preserve UUID…rsync may additionally slightly modify device special files due to udev interaction).

Btw, when using “reuse” with a raw image in place of a sparse image your time to copy the image into the Jetson goes up by quite a bit…don’t be surprised if it takes close to three hours to flash.

Thank you! I am going to try to do this now. I am fairly inexperienced with Linux so this could take some time but I will report back once I figure it out. I do not have a real hard drive mounted so I will do that as well.

Thanks!

@linuxdev could this also be done with a usb stick?

Edit: Nevermind I was able to successfully copy the file over. I am going to try to replace it in L4T now

Even though you succeeded it would still be useful to note a USB stick can work…but you need ext4 file system type and not VFAT to preserve Linux permissions.

@linuxdev

I was able to flash the jetson and it gave no errors during the process. However, after rebooting nothing comes up. The jetson turns on but I can not ssh in nor can I get anything through HDMI

Did you flash with the “-r” and reusing an image, or by rsync into the rootfs?

I flashed with “-r” and reused the image

What is the exact size of the image? And what “-S” size was used or present on the Jetson the image is going to?

The exact size of the image was 15,288,238,080 bytes and the -S size was 14580 MiB

Prior to this image being used, was there a previous flash with “-S 14580MiB”? I’m trying to determine if size differs between this “reused” image and the layout of partitions prior to this flash, e.g., if the system had a default size it would have something like “-S 12GiB”, and would differ. If there is a difference you may need to flash anything at “-S 14580MiB” and then after that the “reuse” should work (be sure to not lose your saved copy…each non-reuse operation destroys the existing system.img.raw and system.img).

I’m not sure, I will try to reflash without -r and report back!

Be sure to use “-S 14580MiB” so partition layouts match.

I did as you suggested but unfortunately it had the same result. No change, it is still completing the flash successfully but nothing else.

You had mentioned ssh does not work…does ping also fail? Also, is there any chance you can try the serial console? See:
http://elinux.org/Jetson/TX1_Serial_Console

I am not able to ping it or connect via serial console. lsusb recognizes a serial connection but I can not stream any data from it. Would it help to reflash and keep serial open to see if anything comes through following the flash?

edit: I confirmed it is not a hardware problem, when I flash without reuse just setting -S eveything runs normally. It is only when I replace system.img and flash that nothing happens

Would it make a difference that the two systems are on different revisions of L4T? They are both R21 but the new system says revision 5 and the old one says revision 4

Ok so I redid it from the beginning making sure that everything was the same version. After it finished flashing the I had plugged the hdmi in and it started booting but it never displayed in error instead it just stopped the boot. After clicking reset I now get nothing during boot.