I have problem after used clone img.
I using comment line:
sudo ./flash.sh -r -k APP -G backup.img jetson-tx2 mmcblk0p1
to backup my img.
And i have succesfully backup img. I see in my folder after backup: file my_backup.img.raw have 30.7GB, file my_backup.img have 42.3MB.
Then I using file my_backup.img change name to system.img and flash into my jetson tx2 and i have code
error return value 3
Can anyone help me fix this. Tks a lot :)
i have the same problem
Leave out the “-k APP”. Let JetPack flash the non-rootfs partitions. FYI, you must use the same version of JetPack/SDK Manager which produced the clone source on the actual clone write.
In terms of disk space, a clone produces a backup.img (sparse image) and a backup.img.raw (raw image). The sparse image is much smaller than the raw image if the filesystem of the clone has free space, but the sparse image is more or less set in stone. If you want to examine or modify the clone, then you need the raw image. I always delete the sparse image and keep the raw image. It takes quite some time, but while not in use I run “bzip2 -9 ./backup.img.raw” (I’m assuming you named the image “backup.img” during the clone).
If your host system is filling up, or even if it is not, then you are safe to delete the sparse image. The raw image can be used directly for flash, but will take longer. If you wish to, then you can create a sparse image using the mksparse program (NULL fill byte, which is the default).
The actual raw image is a bit-for-bit exact copy of the entire rootfs partition. Between the raw image and the sparse image your host will need a lot of disk space. There isn’t any reason you couldn’t save the clone to a thumb drive or other drive.
NOTE: I do not know what the return error 3 is. However, if you are out of disk space, then there is no chance of success until you have enough disk space. If you intend to reuse a cloned image, then you could also delete the content in the “Linux_for_Tegra/rootfs/” directory…this content is used for generating a default image, and restoring a clone replaces that.
Hi linuxdev,
I’ve used the raw img to flash but it kept returning error
E> NV3P_SERVER: Accessing offset 30742151168 after boundary partition size 30064771072
&
Error: Return value 4
Using older jetpack ver. 3.3.1 yield the same result, just a slightly different returned log
Size is more than actual size
On the other hand, adding “-k APP” gave different error for both jetpack ver. 4.2.3 and 3.3.1
For 4.2.3, the error is
Failed to fetch load address
&
Error: Return value 13
For 3.3.1, its error value is 4 (same error log)
I guess somehow my backup img is larger than it’s actual size, therefore when restoring it back, it couldn’t fit into smaller disk space of TX2. I try to flash a fresh img (using jetpack 4.2.3) and back it up. This time, the raw img is 30.1GB while the previous one is 30.7GB.
I’m trying to sparse this 30.7GB raw img, hopefully its result could fit into smaller disk space but was unsuccessful. The sparse img is only 42MB!!!
Do you have any idea how can I get out of this situation?
Thanks in advanced!
I think I see what is going on. Before I mention this, I should explain that on command line flash there is an option to set rootfs partition size. The size has a default. When that size is explicitly stated, then it is either in MiB (1024x1024), or GiB (102410241024). To determine the size a clone has produced in those units, use “ls -l /where/ever/my/clone/is/something.img.raw”, and then after dividing twice by 1024, this is the “MiB”; or divide again, and that is the size in “GiB”. If the image size does not divide evenly by 1024 twice, then the image is corrupt. If the image divides evenly by 1024 three times, then you could name this amount in either MiB or GiB.
During a flash where you want to name some specific size (versus using a default) through the “-S” option, we could for example flash a TX1 to max partition use via:
sudo ./flash.sh <b>-S 14580MiB</b> jetson-tx1 mmcblk0p1
If the size of your clone is larger than the default, then what you see would occur. What is the exact size of the raw image (the sparse image cannot be used to determine this)? Convert that to MiB or GiB, and use the “-S” parameter during the restore, and I believe the error will go away if the eMMC can handle that amount of data.
On the other hand, if your image is too large (even with “-S”), then I would wonder if the clone came from modified hardware or a non-eMMC partition.
Now I get it. Thanks so much for your support!
I’ve checked and and confirm that the raw img is most likely not corrupt as its size is exactly 29318 MiB. I’ll try to re-flash using the “-S” parameter and come back here with the result.
I’ve copied the old 30.7GB raw img to bootloader dir, renamed to system.img & flashed the TX2 using this cmd:
sudo ./flash.sh -r -S 29318MiB jetson-tx2 mmcblk0p1
This time, the flashing process works but after finished and reboot, it hangs at the nvidia logo boot screen.
I’m trying to use other method that flashing a fresh img and then re-flash it with below cmd, hopefully it would work
sudo ./flash.sh -r -k APP -S 29318MiB jetson-tx2 mmcblk0p1
Was the image you reused from the same release of L4T/JetPack? Is this the development kit carrier board? Also, is the kernel itself modified in any way versus stock? The mechanics of the flash are now correct, but we still have to consider actual content.
NOTE: I wouldn’t use the “-k APP”.
No, I use the flash.sh file from jetpack 4.2.3 to backup L4T on Jetson installed by jetpack 3.3.1 → I believe the L4T ver. is 28.3.1
Yes, it is the TX2 development kit carrier board
This, I’m not sure because there are several other members also working on this board.
BTW, I doubt my backup img was really ok. If it’s healthy, then why mksparse doesn’t work on it?
On the other hand, I used jetpack 3.3.1 to flash this raw img but got the same result as 4.2.3 - the system stuck on nvidia logo boot up screen.
Obtaining an image (a clone) is ok from any release. However, it is very important that the clone being restored is from the same release as you are using to restore the clone. If you used JetPack 4.2.3 to flash a clone from a different release, then this may be why it fails. Root filesystems are not entirely independent from the setup software in the other partitions.
“mksparse” cannot work on an image which is already sparse. Understand that when you clone and name a file, that two files are generated. If you name the file “backup.img”, then this plus “backup.img.raw” will be created. The “.img” is already sparse, and only the “backup.img.raw” can be used with mksparse.
However, if mksparse fails on the raw image, then something is probably wrong. One possibility is that the filesystem was somehow corrupt, e.g., it was shut down uncleanly before starting the clone. mksparse depends on the ext4 filesystem integrity. If the journal is needed to replay to correct for some previous bad shutdown, then mksparse needs this to be completed prior to conversion from raw to sparse.
We do know that the division by 1024 worked exactly, and so you know the image is not truncated. This does not say whether or not the ext4 on the image is valid.
Note that mksparse is simply what I would call “the poor man’s run length compression”. If the filesystem is nearly full, then sparse and raw approach as being the same size. I’ve never tried, but I suppose that if the filesystem is full, then this might be a problem for mksparse (though I doubt this would really be a problem).
Do realize that you can flash using the raw image so long as it is named “system.img”. In the past there was no sparse file and the flash software worked only with raw images, but the flash time was long and the sparse image began use to reduce flash time.
Also, if you can loopback mount the raw image, then you know the image is good (and you may find some indication of needing filesystem check). For example:
sudo mount -o loop ./backup.img.raw /mnt
ls /mnt
sudo umount /mnt
You mean the jetpack ver. (used to flash the img back to jetson board) must match with the clone itself (the OS within the img), or match with the jetpack used to make the clone?
I fully aware that there are 2 img files: the full img.raw & the sparse img generate from it by “mksparse”. And I also know that I can use both file as long as I rename it to “system.img” & put it in the bootloader dir & use the tag “-r” when flashing.
In my case, mksparse didn’t give error but in contrary to that, it says everything is ok!?!? Even though the sparse img is only 42MB!
This is one of the most mysterious part of my issue. I can mount the “broken” raw img just fine, but its data is only ~1.6GB (28.5/30.1GB available)! Inside, its content is like this:
boot
|--dtb
| |--tegra186-quill-p3310-1000-c03-00-base.dtb 344kB
|--image 34.2MB
|--initrd 5.6MB
|--tegra186-quill-p3310-1000-c03-00-base.dtb 344kB
etc 118B
README.txt 62B
On the other hand, mounting the “working raw img” & its sparse clone DID NOT WORK! But I can flash them normally on the TX2!!!
The clone image came from some version of JetPack originally. The hardware you are restoring this clone to much be the same hardware, and just be flashed with the same release of JetPack which was used to create the cloned unit in the first place. You can ignore the version of JetPack which actually obtained the clone, only the original flashed system and the system being updated with the clone care about JetPack version.
There are some exceptions which were from minor patches, e.g., L4T R28.2 clones would work on a system flashed with R28.2.1 since this was only a bug fix release. A clone from a system with R28.2 cannot be used with a system having non-rootfs components of R32.1.
A sparse image is essentially the “used” space. As the filesystem fills to 100%, then the sparse size will approach the raw size. Partitions are always the raw size.
If you were to loopback mount a raw image, and that image has only partial content, then the eMMC the clone came from is also missing that content. This assumes a successful clone, but you should notice if the clone extraction/creation ended in error or not.
If your image is named “backup.img.raw”, then what is the size from “ls -l backup.img.raw”? This must be divisible by 1024 either twice or three times. Anything else and the clone is invalid. If the clone is valid by size, and it is loopback mountable, but does not have the content you expect, then perhaps the eMMC of the system you cloned from is failing.