Jetson AGX Xavier not booting after clone

I have followed the post for cloning an image off of one device onto the a host posted on this forum and this site:
https://elinux.org/Jetson/Clone

The img copied successfully but after rebooting the Xavier that the clone was taken from will not boot. The power light is on but nothing else. I have tried to boot in recovery and it is the same, nothing but the power light.

Hi,

  1. It is probably the clone would cause system not working if the driver is not compatible between old and new environment.
    If you want to debug this kind of issue, you need to dump the serial console log.

  2. No matter what you’ve done to your board. It should always be able to enter recover mode and re-flash.

have tried to boot in recovery and it is the same, nothing but the power light.

I am sorry but really don’t know what do you want to describe here. what is same here? When you enter recovery mode, the OS will not boot up but just wait for you to flash.

Thank you for the reply.
I am able to see the device in force recovery with lsusb. can you tell me how to dump the serial console log?

What was your restore command? Looking at that URL I see one method, which might be the reason for this failure:
$ sudo ./flash.sh -r -k APP jetson-xavier mmcblk0p1

There are many ways to restore different parts of a system, and I am going to suggest leaving out the “-k APP”. Instead try:
$ sudo ./flash.sh -r jetson-xavier mmcblk0p1

If you do this with the clone in place as “Linux_for_Tegra/bootloader/system.img”, then the entire eMMC content will be flashed, and not just a subset. This means that supporting boot partitions (partitions which are not the rootfs which the clone produces) will also be flashed.

For background, sometimes you will find a rootfs which is from a release different than the JetPack/SDKM producing that release causes problems resulting in failure to boot. If you just flash the rootfs, then it is still possible the content of those other partitions is not compatible with your clone. Just be sure to use the same exact version of JetPack/SDKM/L4T for flashing the clone in as that which originally produced the system the clone came from.

Hi bobstoggies,

Please connect the usb-ttl cable to the UART pin.

Also, please make sure you understand what is recovery mode and why serial console is needed here…

We want the log from serial console because you said your device is not able to boot. It has nothing to do with recovery mode unless you have device flash problem.

After you dump the log, I think you would still have some to correct. You could refer to this page then.
https://elinux.org/Jetson/General_debug

Thanks for the updates.

The issue that I had was that when I ran the command :

sudo ./flash.sh -r -k APP jetson-xavier mmcblk0p1

I didn’t know that it would remove the image off of the Xavier. I was under the impression that the command would simply copy the system image.

I had previously ran:

dd if=/dev/mmcblk0p1 | ssh user@hostpc dd of=/data/testimage.raw

After running this the clone was taken and the Xavier was able to be booted without issue.

The first code makes the copy, however it requires the flashing of something back on the device.

I have successfully recovered my device, but it would have been nice to know, to avoid the panic of pushing the power button and nothing happening.

Replacing the system (rootfs) image often requires updating the other partitions to match that rootfs. Unless you’ve made some sort of custom modification of the non-rootfs content, then there is nothing to fear from flashing everything, but where the rootfs comes from your clone. “-k” can prevent those other partitions from updating to match.

Keep in mind that when you run a default flash that this image is created from a combination of things. By far the majority of content is from the PC side’s “rootfs/” subdirectory, and that content is mostly a purely Ubuntu system with some added NVIDIA drivers. The catch is that depending on what arguments were given during the flash the “rootfs/boot/” content will also be modified, e.g., the kernel and device tree and kernel arguments. That content usually comes from places like “Linux_for_Tegra/bootloader/” or “Linux_for_Tegra/kernel/”. Some of this content will have dependencies on the non-rootfs content partitions.