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)
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,
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
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 nvidia.com, I don’t change it.
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.
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)
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.
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 ?
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).