Hi, today when I inserted a micro USB cable to the micro USB port, the port on TX2 fell off. I need the micro USB port. Also, I have spent a lot of time to install software on the TX2 and a lot of my new code is also on it and does not have any backup. So I would like to clone the TX2 so I can have an exactly the same device. Is there still a way to clone the TX2 without the micro USB port? From all the posts I read online, it needs to use the micro USB port to clone.
Normal clone does require this port, but if you were to mount a large enough SD card or SATA disk, then you could use “dd” to clone.
FYI, assuming your disk is SATA at “/dev/sda1”, then something like this would clone rootfs such that at a later date this could be restored to another Jetson through the flash tool (that Jetson would have to run the same verison of L4T):
sudo mount /dev/sda1 /mnt
sudo dd if=/dev/mmcblk0p1 of=/mnt/backup_of_rootfs.img bs=512
I do have a 128G SD card at /dev/sda1 and mount to /media/nvidia/Sandisk
So the command to create image is
sudo dd if=/dev/mmcblk0p1 of=/media/nvidia/Sandisk/backup_of_rootfs.img bs=512
Correct?
Also, what would be the command to flash this image to my new TX2?
As for “that Jetson would have to run the same verison of L4T”, I am confused. Since I thought “clone” means making an exactly same copy, including the OS. My current TX2 has jetpack 3.1. Do you mean I have to flash jetpack 3.1 to the new tx2 from a PC and then I can flash backup_of_rootfs.img to the new TX2?
That command is correct (since it is almost 30GB it will take quite some time). You can then put the SD card on your host and test this way:
sudo mount -o loop,ro /dev/whatever_the_sd_is /mnt
cd /mnt
ls
# ...is it exporable and matching the Jetson rootfs?
cd
sudo umount /mnt
Note that if you want to see progress it this also goes in the command:
status=progress
e.g.,
sudo dd if=/dev/mmcblk0p1 of=/media/nvidia/Sandisk/backup_of_rootfs.img bs=512 <b>status=progress</b>
The driver package understands two types of images…one is the raw image (this is what the dd produces), the other is sort of a kind of compression, a sparse image. You can’t manipulate a sparse image, it seems to be in a format open source tools don’t understand. The raw image works perfectly well, but is larger and takes much more time to flash. You can use the mksparse tool if you really want to create a sparse version of your raw image, which would leave you with both.
The flash software has directory “Linux_for_Tegra/bootloader/”. All you have to do is copy your image as name “system.img” and place it in that directory, and then flash with the option to “reuse” the image. Example:
sudo ./flash.sh <b>-r</b> jetson-tx2 mmcblk0p1
(the “-r” is the magic)
@linuxdev thanks. So the procedure is:
- On my currently broken TX2, run
sudo dd if=/dev/mmcblk0p1 of=/media/nvidia/Sandisk/backup_of_rootfs.img bs=512 status=progress
- Eject the SD card and insert it into a host PC, mount the SD card as /mnt with
sudo mount -o loop,ro /dev/whatever_the_sd_is /mnt
then
cd Linux_for_Tegra/bootloader/ // Where is this directory on host PC?
cp /mnt/backup_of_rootfs.img system.img
Then set the new TX2 in forced recovery mode and link it to the host PC. From the host PC, flash with the command
cd Linux_for_Tegra/bootloader //Is flash.sh in this directory?
sudo ./flash.sh -r jetson-tx2 mmcblk0p1
Correct?
That is basically correct.
The “Linux_for_Tegra/” directory is from the driver package. If you’ve ever used JetPack to flash, then it will be a subdirectory within the JetPack location of the PC host. JetPack just runs the driver package for you.
FYI, a regular flash by command line normally only requires the driver package plus sample rootfs. When you “reuse” the rootfs image (the “-r” option) you don’t use the sample rootfs. A normal flash without “-r” generates a new image each time it flashes based on that sample rootfs…“reuse” implies leaving the system.img in place and not recreating it, so if you put your image there, then that is what it uses.
If you were to flash on command line without JetPack, this has some notes on it (this is for all Jetsons, adjust for your TX2):
[url]https://devtalk.nvidia.com/default/topic/982779/jetson-tk1/how-to-perform-a-correct-fresh-ubuntu-install-on-jetson-tk1/post/5040584/#5040584[/url]
Your command would be as mentioned up above for “jetson-tx2”, and with the “-r” option. The image is already generated, you shouldn’t need to specify size (it was generated via dd and will be the right size).
Driver package would be from the version the rootfs image is taken from. For example, if your image came from R28.1, then you wouldn’t want to restore it to R28.2.
One other note if you look at the manual command line flash instructions…you won’t need to unpack sample rootfs, and you won’t need apply_binaries.sh. Sample rootfs is if you don’t already have an image, and apply_binaries.sh overlays drivers on the rootfs…but your install already has drivers since it came from a working Jetson.
Whenever you eject a mounted SD card be sure to properly umount it first. Failure to do so can corrupt whatever has recently changed.
Despite how large that file will be (close to 30GB) you might consider keeping it somewhere safe and not putting your only copy in “Linux_for_Tegra/bootloader/system.img”. Just the file copy will take a lot of time, but if you have the space, consider doing so until you know you have things working again.
hi @linuxdev, do I have to use a PC? I mean, after creating the backup_of_rootfs.img on SD card from the borken TX2, can I just insert the SD card into the new TX2 and copy file file to some location on the new TX2?
Before you do anything do be certain you have a safe copy of that image until you are convinced things have worked as required.
Do beware that the new TX2 would need to have the same version of L4T on it as the one the rootfs comes from. If that is the case, then in theory you could boot to a rescue SD card, and then use “dd” to place the “.img” file from the previous “dd” which created the image. This also only holds true if the old partition and the current partition are also the same size (“dd” won’t rearrange partitions if the old and new size scheme does not match).
If you were to use the flash software (“driver package”), and if that software were from the same L4T release as your recovered image, then flashing and telling it to “reuse” the rootfs (while the recovered image is in the right place), then it would both copy the image to the correct place and make certain that everything else is from the same release. This would be the preferred method since there is less to go wrong (and you can explicitly tell it to use a partition size that is the size of your recovered image so partition layout won’t be an issue).
The driver package is what provides the “Linux_for_Tegra/” directory, and within that is the “bootloader/” subdirectory. Normally flash.sh would create “bootloader/system.img” based on a sample rootfs, but you can instead place a copy of your recovered image there using the “system.img” name, and then tell flash.sh to not generate a new image (the “-r” option to “reuse”).
What is the exact byte size of your image? Which L4T release is the recovered image from?
When I got my old TX2, I used my PC to flash jetpack 3.1 to it. So the old TX2 and the recovered image should have jetpack 3.1 which I think is L4T 28.1.
Here is the size of my recovered image:
nvidia@tegra-ubuntu:/media/nvidia/Sandisk/clone$ ls -ltr
total 29360132
-rw-r–r-- 1 root root 30064771072 Nov 21 19:12 backup_of_rootfs.img
It is about 30G.
When I checked the hard drive usuage, however, only 17G is used:
nvidia@tegra-ubuntu:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 28768380 17280872 10003120 64% /
I am wondering how can the recovered image larger than the disk used…
A note on image size at the end…steps shown for when the image is valid.
Size “30064771072” implies the flash.sh size is “-S 28GiB” (30064771072 divided three times by 1024…if it only divides evenly twice by 1024, then it is “-S …MiB”…if neither of those divide evenly, then it is a failed clone). So a flash with reuse of your clone (not generating a new rootfs, but still making sure other components are in place) would go something like this:
- cp /your/backup/image /where/ever/it/is/Linux_for_Tegra/bootloader/system.img
- Put the TX2 in recovery mode, connect micro-B USB, verify host sees the Jetson:
lsusb -d 0955:7c18 - cd /where/ever/it/is/Linux_for_Tegra
sudo ./flash.sh <b>-S 28GiB -r </b>jetson-tx2 mmcblk0p1 # Or with logging: sudo ./flash.sh <b>-S 28GiB -r</b> jetson-tx2 mmcblk0p1 2>&1 | tee log.txt
You are correct that the image size is not possibly from a TX2’s eMMC. The image would be valid for an Xavier, but not for a TX2. Since the size was valid for other hardware, are you using more than one Jetson?
What do you mean by “using more than one Jetson?”
I have a SD card mounted to my old broken Jetson TX2. I first made a directory on the SD card on the old broken Jetson,
/media/nvidia/Sandisk/clone
then go to that directory and ran:
sudo dd if=/dev/mmcblk0p1 of=/media/nvidia/Sandisk/backup_of_rootfs.img bs=512 status=progress
I will try to create this file again and see if the size changes.
Sorry, miscalculated and looked at wrong eMMC: It isn’t possible, on a TK1 through TX2, to produce an image of size “30064771072” bytes via dd of mmcblk0p1 (on the other hand, this could be a copy of the SD card, but SD is mmcblk1 and not mmcblk0). Xavier is the first Jetson to have that much eMMC. I thought perhaps the wrong partition was copied (the method looks correct, the result does not). That size is approximately double the entire eMMC,The size is invalid for a TX2, and so dd cannot possibly produce a copy which is that size.
Keep in mind that not only do you have to have that SD card, you also have to boot to that SD card. Having it exist is not enough. I don’t know if you modified extlinux.conf and booted to an alternate boot entry (via serial console) or not. You can use dd to copy mmcblk0p1 even if it is mounted, but it will change while being copied and may not be a valid copy (it could be a slightly corrupt or worse copy needing repair).
Do you have a serial console? This allows picking entries instead of committing to a single entry and hoping it still boots when a failure to boot could end the life of the device.
Do you mean before I can dd, I need shutdown the Jetson and boot from my SD card? I did not do that. How can I boot from SD card?
Yes, you need to boot from the SD card. How to do so depends on release and a few other things. If you have a serial console, then it is much easier (a case when it is ok to make mistakes). Do you have a serial console?
How large is your SD card? If it isn’t large, then it is ok provided you have ethernet to stream the dd image to the host rather than copy to the SD card.
Basically, if the boot environment has macros to look for extlinux.conf file at “/boot/extlinux/extlinux.conf” of alternate boot media, then you won’t necessarily have to use a serial console. On the other hand, I wouldn’t even consider developing on a Jetson without one (at least nothing serious), so if you don’t have serial console, then you should get the cable.
The first step is to create a bootable SD card. This means it needs the first partition to be file system type ext4, and to at least contain some minimal content. It is actually easier to just put the full content in, but some people may want to keep disk use to a minimum in order to use a smaller SD card or have room for other content during a rescue.
There are a lot of variations on this, so first tell me:
- How large is your SD card?
- How much disk space is used on the Jetson (on the Jetson you can run "df -H -t ext4" and see this)?
- Do you have lots of space on your host PC (e.g., "df -H /where/ever/on/host/you/will/back/up/to")?
- Do you have a serial console (USB serial UART cable with 3.3V, i.e., "TTL" logic level)?
- Which L4T release is running on the Jetson being copied (use "head -n 1 /etc/nv_tegra_release")?
An update to one of my prior notes which was incorrect:
Size of the final image will be evenly divisible by either 1024^2 or 1024^3. I miscalculated and the size was valid for a TX2, but the partition still must not be mounted at the time of producing it.
Hi there, my micro USB port on TX2 is broken, too. I wonder if I can flash without it?
The flash process of Jetson Nano is quite easy, is there any possibility that I could flash all things I need into an SD card and force the TX2 to boot and install from the SD card? Or any flashing method which doesn’t require the micro USB?
I have JetPack 3.1 on the board for the moment.
Thank you.
–edit–
Too copy all things from TX2 to a SD card and/or boot from SD card, check here Run Jetson TX1 from SD Card - JetsonHacks
However, I do not know a good way if you want to flash new content to the broken TX2
Part of the problem is that newer releases change more than just the rootfs partition. There are many partitions needing to be added, and those are signed. You could boot from SD card with the old version and attempt dd to install newer versions, but it is complicated and any failure would leave the device unbootable. You might be better off not messing with the eMMC and just using an SD card.
Thank you for the reply. Still something unclear to me.
First of all, my TX2 is still alive, just the micro USB port is broken (so it’s just broken “physically”)
Secondly, do you mean that I can flash the latest Jetpack into an SD card, and boot from that card? Or it’s not possible at all? If not, I’d better fix the USB or buy another board.
Thanks!
If somehow you can access to another TX2 with jetpack 3.1, you can make a bootable SD can with that TX2 and then run your own TX2 with this SD card.