Failed to sparse the raw to img due to the size of system.img.raw is not mulple of 4096

I flash the orin devkit with jetpack5.0 via sdkmanager, and want to clone a system.img .

Blockquote sudo ./ -r -k APP -G system.img jetson-agx-orin-devkit mmcblk0p1

And I get the system.img.raw, but at the end of the flashing process , it prompt “size of system.img.raw is not mulple of 4096.”, the system.img is 0kb.

The size of system.img.raw is 62225330688(is not mulple of 4096), but the size of /bootloader/system.img.raw is 59055800320(is the mulple of 4096)

what’s the issue here?


Have you tried latest r34.1.1? Looks like fixed in this release.

Hello WayneWWW,

I am also facing the same issue on the latest r34.1.1 having jetpack 5.0.1

And also do you happen to know local.conf file template or location?

Saw in one of the online resouce to add this line in local.conf:


Can you share some insights on this as well?.

I have tried the R34.1.1, but the issue remains.
I find that the issue will happen when I flash the orin devkit by SDKmanager before cloning,
It’s successful if I flash devkit by command line before cloning,

sudo ./ -r jetson-agx-orin-devkit mmcblk0p1


It looks like we cannot reproduce the issue on our side.

Could you share the detail steps of how you hit this issue?

If you just use pure jetpack and devkit as base case, would you hit issue?

Hi Wayne,
Yes, I used the pure jetpack and new devkit.
The fellowing are my steps:

  1. Assemble the rootfs

$tar -xvf Jetson_Linux_R34.1.0_aarch64.tbz2
$ sudo tar -xpf Tegra_Linux_Sample-Root-Filesystem_R34.1.0_aarch64.tbz2
$ sudo ./

  1. Flash the devkit (This step is for generating some dependencies,such as /bootloader/esp.img)

$ sudo jetson-agx-orin-devkit mmcblk0p1

  1. Open Sdkmanager, and flash the orin devkit,the files include the OS and all the components.

  2. Clone the image.

sudo ./ -r -k APP -G system.img jetson-agx-orin-devkit mmcblk0p1

Hello WayneWWW,

In my case:

  1. Used sdk manager to download and install all components for OS image.
  2. Tried to clone using the command:
    sudo ./ -r -k APP -G system.img jetson-agx-orin-devkit mmcblk0p1

All steps happened successfully but
ended up getting that error while creating the sparse .img file.


1 Like

You should still have file “Linux_for_Tegra/bootloader/system.img.raw”. What is the exact size of this file? Example from “Linux_for_Tegra/bootloader/”:
ls -l system.img.raw

Also, the file can be manually created via mksparse to go from raw to sparse. From the same “Linux_for_Tegra/bootloader/” directory, what do you see from the “mksparse” command? Here is an example which also logs any error to file “log_mksparse.txt”:

sudo ./mksparse -v --fillpattern=0 system.img.raw system.img 2>&1 | tee log_mksparse.txt

Can you directly try the BSP downloaded from sdkmanager instead of preparing by yourself?

Hi linuxdev,

Thanks for your reply.
Size of Linux_for_Tegra/bootloader/system.img.raw is:

ls -l system.img.raw
-rwxr-xr-x 1 root root 59055800320 5月 30 18:48 system.img.raw

log_mksparse.txt, the log of mkparsing system.img.raw to system.img, is in the attachment.
log_mksparse.txt (624.4 KB)

The issue will be hit when the devkit is flashed via sdkmanager(an HMI from nvidia) ,
And there isn’t any problem if I flash the devkit via command line.
The BSP is downlaoded from, I don’t change it.


Sorry for late reply. Can someone here share the full error log you got?

I mean this log should include the command you used to hit error.

The size is valid, it is an exact multiple of 1024 and would be specified as “55 GiB”. That size is also evenly divisible by 4096. The “mksparse” log also shows success. I don’t know why flash would reject this based on size.

Hello I am attaching the terminal log during the process and also the log_mksparse.txt file.

Command used to create the image:

sudo ./ -r -k APP -G orin_raw_new.img jetson-agx-orin-devkit mmcblk0p1

Also checked sizes of raw file and img file using the command:
ls -l

-rwxr-xr-x 1 root root 0 Jun 16 09:20 orin_raw_new.img
-rw-r–r-- 1 root root 62225330688 Jun 16 09:20 orin_raw_new.img.raw

log_mksparse.txt (52 Bytes)
terminal_op.txt (4.0 MB)

Thank you!

That isn’t even divisible by 1024. On the running system, what do you see from:
sudo blockdev --getsize64 /dev/mmcblk0p1
(this would be direct from the partition and divisible by 1024…or for Orin, probably also 4096, but if it exactly matches the clone size, then we’ll know something much more odd is going on)

1 Like

Hello @linuxdev , Thank you for the response. I entered that command on the jetson orin agx I used for cloning and got the output as:


I see that both the values are same. Any idea why or how to fix it ?

Appreciate your help!

That’s quite a mystery. I don’t know how such a size would have been installed to start with. I don’t think the clone is bad, I think a previous issue changed this in eMMC to an unexpected size, and the clone is valid. Was there any kind of unusual previous install detail? I don’t know what, but something strange happened.

Btw, you could technically resize the loopback clone with an application which works with ext4 awareness, and make the system fit on a “correct” image file size. I’m not sure if that is worth it for you, but it might be something worth learning if you are going to deal with clones which need to change size.

1 Like

Hello @linuxdev , thank you again for the response. I didn’t have anything strange happening, except sometimes it doesn’t get detected via usb, but when I retry it works as usual.

Do you happen to know/ have used any application to resize the clone? This clone is important as we look to scale the projects and will be useful if you happen to know anything trusted?

I just wanted to check if we are both on the same page with respect to it. So once I use an application to resize, should I have to resize to a size divisible by 4096 right ?

Thank you. Looking forward to your response.

In the past I’ve used gparted (“sudo apt-get install gparted”) to do this. You do have to be careful, so when experimenting, I suggest you keep a clone untouched and work on the copy (not easy when files are 10s of GB or more). I would never trust this to the original image. I don’t think there is a “safe” version of anything resizing a live file system with random content.

Basically you’d cover the file with losetup, and use gparted on the loop device. The file itself would remain the same size, but the filesystem would change if reducing size. There are tricks you can use to increase the file size if you need more than the file backs, such that the original won’t be altered, and then gparted can instead expand into the larger file. Expansion is easier since there is never any content to overwrite (everything added is blank ext4).

And yes, you’d want the filesystem and actual file to be a multiple of 4096 for an Orin. Most anything else seems to be ok with just a multiple of 1024. I am still quite mystified by how the original flash size was wrong (it shouldn’t be possible without manual effort).

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.