mount failed from image by ./nvflash --read APP system.img

I want to clone my APP partition in tk1, and I found a page :


sudo ./nvflash --read APP system.img --bl ardbeg/fastboot.bin --go

I got a 15GB file, but when

sudo mount -t ext4 -o loop system.img /mnt

on pc, it prompts cannot find ext4 filesystems.

I can mount the system.img.raw, which generated by ./ , successfully.

Can you help me here? Thank you!

PS: why I want to clone file system this way? because I corrupted system kernel zImage and L4T cannot boot, so I want to preserve the filesystem rather than reflash the entire system. Thank you guys!

Your commands should work, they seem basically correct. What is the exact size of the cloned file? Which version of L4T was on the Jetson before the zImage issue?

One thing to test is using the mount command you gave, but leaving out “-t ext4”. The system will attempt to discover file system type if the type is not explicitly given (perhaps automatic discovery will offer clues).

the image file is 15,032,385,536 bytes, I was using 21.4 before.

I tried to mount without -t ext4, mount program tried several formats but all fails.

I have 2 board and read 2 images from APP section but with no luck.

I also boot tk1 from sdcard and try to mount /dev/mmcblk0p1 but also fails.

I also tried boot from sdcard, with extlinux.conf modified root directory from mmcblk0p1 rather than mmcblk1p1, but kernel dumped after 8 seconds. I don’t know if anything else I did wrong.

It seems booting from sdcard command (sudo ./ jetson-tk1 mmcblk1p1) changed mmc 0 content. Because before execute this, in Uboot, ext2ls mmc 0 returned directories in emmc.

After execute this(sudo ./ jetson-tk1 mmcblk1p1), ext2ls mmc 0 returned can’t find correct ext4 system!

Oh yes, I opened system.img read by with lfhex, it turns out all zero in the file. So why boot from sdcard flash command formated emmc? and how?

Not sure of an answer, but here are some observations.

The file size from the raw image clone indicates that the flash used “14GiB” during the flash, which should work fine, but is slightly less than full use of eMMC. File size validates basic size of the raw image.

If you flashed and named mmcblk1p1 (SD card), then clone of the eMMC root partition will not be the active/relevant root partition…the SD card would be the first place the Jetson looks for the boot loader binary. This is distinct from naming mmcblk0p1 (eMMC) and having u-boot binary on eMMC…possibly followed by config of u-boot pointing to either eMMC or SD card. Naming mmcblk1p1 basically invalidates any clone of root partition.

Normally the binary images (such as the boot loader itself) are subject to NULL byte padding to fit into an exact rounded size, but those files would never be all NULL. I could see the possibility that if the binary file being used for the final padded file was not readable due to file permissions, then perhaps a 100% NULL byte file could result during padding.

If your flash pointed to mmcblk0p1, and if the flash-generated raw image is loopback mountable, then I suspect that the clone was basically correct, but cloned image mount failed because the eMMC is corrupt…basically an eMMC hardware failure. More details on steps to flash just to mmcblk0p1 would be needed to make any further guess.

Thank you for your kindly reply!

Do you mean the clone I got is from mmcblk1p1, and I didn’t put sdcard in it so I get all null?

So I will try flash to mmcblk0p1 with flash.cfg changed to skip APP section download.

but one thing still can’t explain, before flash to sdcard command, I can list mmc 0 directories. But after flashing, I can’t list mmc 0 in u-boot with same command.

clone method by read is ok, I can clone frome fresh flashed board and mount the image successfully. However, once flashed with sdcard boot, even I reflashed with mmc boot without touch APP section, the image read from board is still all zero.

so, can I get the conclusion than once flashed with sdcard boot, internall emmc will be formated to all 0?

When you flashed to internal eMMC (mmcblk0p1) and cloned a loopback mountable partition, did the Jetson boot correctly?

A non-GUI flash is available for just flash and no other packages…try to use that without any JetPack GUI involvement when testing for flash quirks. I don’t know how your live distribution package manager will deal with things like addition of widget sets…the command line “pure flash” has no such requirements.

The clone command only works when reading eMMC, the SD card (mmcblk1p1) cannot be cloned (but you can plug the SD card into any computer and copy the partition with dd anyway). If you had a clone from any eMMC partition (mmcblk0p1) all NULL after a pure eMMC flash, then something was probably wrong…if the NULL byte clone was from SD card, then I’d expect it to fail and be NULL.

Flashing with mmcblk0p1 versus mmcblk1p1 changes things internally in the Jetson as to where it looks for data. This also changes which partitions are created on eMMC. I believe even with the SD card in, clone from a mmcblk1p1 may not be reliable; without the SD card you would definitely end up either with an error or all NULL. Expect clone of APP partition to be a reliable tool only when you flashed to mmcblk0p1 (eMMC). Moving a partition to SD card would cause the partition to disappear from any list of eMMC partitions. Configuring u-boot to use a new root partition via extlinux.conf edit is a very different story…this would leave the original eMMC root partition completely intact.

Using the non-GUI flash you can “re-use” a previously created system.img if you wish (however, I would not do this unless you can verify the raw image is loopback mountable). In the case of re-using an image ("-r" option to, you might need to manually state the image size (like “-S 14GiB” for a raw image of size 15,032,385,536 bytes…something you cannot figure from a sparse image).

I think Jetson can boot correctly, but I didn’t verify it. Read 15GB file takes too long~~~.

I didn’t use JetPack GUI, chroot is good to me.

Thank you for your explanation. Now I know non-GUI flash changes partitions in emmc even no APP section download process. And it probably changes emmc to all zero.