I couldn’t say for sure, but it is quite possible the kernel change required extra steps. In some cases you’ll be looking at the kernel in the rootfs “/boot/Image”, but there may also be something in a partition (can’t say for sure, but it might be the case). Also, any time you flash without the “-r” option to flash.sh, then Image will get put back in and overwrite.
Different kernels may require a different device tree as well in some cases (not always), and those are part of the board support package which would have to be added to the “Linux_for_Tegra/” content to match what the original kernel used.
Using dd for mmcblk0p1 versus clone is exactly the same result, except that dd requires a running system, and a running system may write to the partition while copying. Even if the partition is set to read-only before reading it with dd there may be temp files involved, whereas clone will be from an unmounted partition (of course if you run from a different media, then this would take care of any issues of copying a mounted partition just like rescue mode clone does).
In the case where your clone fails to boot, have you verified that the clone being written to a new unit uses the same JetPack/SDKM relesae as what created it originally? If so, then you’ll want to include a serial console boot log for a closer look at the point of failure. You may also want to post what device tree and/or kernel modifications exist. Kernel mods may not matter, but in some cases they will, and if those mods do matter, then the boot log may reflect this.
Also, you might verify the exact byte size of the raw clone. This can be explicitly set during the flash of that clone to guarantee it has space if it isn’t a default size. The size divisible evenly by 1024 twice is “MiB”, or divisible by 1024 three times is the size in “GiB”. A size of “28GiB” for example: sudo ./flash.sh -s 28GiB -r jetson-xavier mmcblk0p1
LI unlikely support 4.4 Jetpack infrastructure yet;
I also doubt that app partition will work if restored with a different versions of Jetpack than with which it was created.
For full disc clone, full dd disk dump should work.
I assume that if I only cloned APP partition with e-con drivers that I had and would try to install it to Jetpack 4.4 flashed device it wouldn’t boot as in the defined case. But if I made dd clone and then fully recovered the dd dump, it would likely work out.
My question for a full dd clone is whether or not part of deciding if signed content is valid/invalid might include information on the Jetson itself (e.g., in ROM)…if part of the test of partition signing depends on the specific Jetson, then an exact dd copy of what is correctly signed on one system will not be valid on the other system. I only have one Xavier dev kit, so I’ve never been able to really test this.
Know the release used to create the rootfs which was cloned. Use that same release to install it.
At “Linux_for_Tegra/bootloader/” copy your clone in as file name “system.img”. You will then have “Linux_for_Tegra/bootloader/system.img”. Put the Xavier in recovery mode with the USB-C connected. For more recent releases simply flash and tell it to “reuse” the system.img via the “-r” option in a command line flash (while in the “Linux_for_Tegra/” directory): sudo ./flash.sh -r jetson-xavier mmcblk0p1
how was the raw image created? from a partition or from entire disk [ many patritions] ?
in the former case it should work for mksparse; In the latter case it will work with mmksprse only if a single partition is dissected from it and processed; otherwise multi-partition dump can be restored from raw with dd
i did it in jetson with this command.
sudo dd if=/dev/mmcblk0 of=‘/media/nvidia/Data/backup/jetpack_4.2/Disk Image of mmcblk0 (2020-08-11).img’ status=progress
the size of img is around 31GB.
for restore progress, i go to host pc, and i did this, the raw is my 31GB img file.
cd /home/nvidia/nvidia/nvidia_sdk/JetPack_4.2_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader
sudo ./mksparse -v --fillpattern=0 /data/image.raw system.img
after that command, i get smaller system.img file around 15GB
this system.img, i remake 2 times, because i saw your post saying that you redo second it works.
but i remake it and reflash, it just stuck at system.img 0%.
after that i put back the stock system.img size around 4GB.
i try to flash to stock jetpack4.2, it didn’t stuck at system.img… haha…
but i still want to flash my system.img in future.
@albert.a
with sudo dd if=/dev/mmcblk0
there are two options:
either dd
or separate the app partition and use mksparse on it or flash.sh
in order to separate the partition it is possible to mount the raw image as a loopbackdevice
then from the loopback device dd only the mmcblk0p1
so that it will be compatible with flash.sh or mksparse method
otherwise you can just dd the whole thing back to the booted device
so that it will rewrite the underlying disk entirely
with all partitions rewritten
At the target Xavier;
sudo su
dd if =‘yourraw of mmcblk0’ of =/deb/mmcblk0
I suggest either use network if source
or use microsdcard with the raw image as a source locally attached to Xavier; Otherwise usb-disk or flash[pen drive]
if the command above won’t work due to permissions;
try the following
sudo su
echo u > /proc/sysrq-trigger
#remount sdcard writeable:
mount --options remount,rw /dev/mmcblk0
please note that the only way you could use flash.sh or mksparce is if only the APP partition has been dumped of the entire mmcblk0 disk;
if the entire disc got dumnped for flash.sh & mksparce it requires to pick up only the APP partition from it
or use alternative methods as Dd to restore the entire disc mmcblk0
Beware that the sparse image size is in no predictable way related to the size of the “-S size” parameter. Only the raw image size can be used to calculate the final image size. Using "-S 15GiB implies the raw file has exact size “15*1024*1024*1024” bytes (16106127360 bytes). If the raw image is around 30GB, then that size setting is far from correct. The “-S” option is about the final partition size, and a sparse image will be expanded during flash.
hi @linuxdev,
thanks for reply.
may i know what is the recommendation for cloning at the moment? or rather “official” method. @jonny21 also mention that just use full image size to restore will do.
i prefer image level. i also don’t mind go into target machine to do the dd, but not sure if boot normally into jetson unwanted version and then do dd from backup image, or usb pendrive to boot from jetson and then dd.
at the moment i use backup rsync rootfs and restore rsync rootfs method to survive, but it is not perfect, it did 99% restore.
Current releases (R32.x, but R32.1 needs a patch) will clone via: sudo ./flash.sh -r -k APP -G my_backup.img jetson-xavier mmcblk0p1
The Xavier would need to be in recovery mode, the USB-C connected, and the host PC would need about 50GB of free space (at least 32GB would be taken by the clone). The flash.sh command is in the “~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/” directory.
The result of the clone would be two files:
The raw file, the one you want, my_backup.img.raw (very large).
The sparse file, only useful for flashing, I throw it away, my_backup.img (about 2 or 3 GB if the filesystem is mostly empty).
Either raw or sparse can be used for flash, but only raw can be examined or manipulated.
NOTE: You can loopback mount a raw clone and use rsync to update it, so if you have a clone as a full backup, then you can use rsync to incrementally keep it up to date without a full clone.
this is the one that failed, i did 2 attempts, second attempt i key in the size, it stuck at 0% system.img
my system.img size is 15056753960 or 15G (ll with -h)
my command was “sudo ./flash.sh -S 15GiB -r jetson-xavier mmcblk0p1”
i suspect the 15GiB might be wrong.
this part you see if you know what’s wrong, please advise.
for now, i move on to use backup/restore rootfs with rsync. for APP partition.
after you looped
the original raw that you have of the mmcblk0,
you could extract from it the APP partition in raw form e.g. with dd
so it will kind of create a raw of the partition mmcblk0p1
once extracted it is possible to use it with flash.sh;
However, rsync rootfs might be even better solution
I typically just copy one tiny folder with Dockerfiles and that is it