How to clone /dev/nvme0n1p1 APP partition from jetson?


I am using BSP r35.1 and flashed an image having APP partition on /dev/nvme01p1 as external device using below command:
sudo ./tools/kernel_flash/ --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_nvme.xml -S 40GiB --showlogs jetson-xavier-nx-devkit-emmc nvme0n1p1

Now I want to clone this APP partition:
I tried using this documentation:
sudo ./ -r -k APP -G clone.img jetson-xavier-nx-devkit-emmc nvme0n1p1

I got 2 images clone.img and clone.img.raw generated successfully. However when I try to mount this img, I dont see full content of the /dev/nvme0n1p1 partition inside my /mnt/clone folder.

sudo mount -o loop clone.img.raw /mnt/clone/

I checked the space required where the .raw image is stored(it has no lack of space)

My question is what I am doing wrong ? does the script work to clone /dev/nvme0n1p1 APP partition ?


Note that a clone only clones actual filesystem content. If you are looking at pseudo files which actually live in RAM, then they won’t be cloned (and should not be cloned). For example, everything in “/sys” and “/proc” will be skipped since these are just “fake” files in RAM which drivers are produced to pretend to be files (they’re an alternate interface to the drivers).

Can you give an example of what directories/files are missing?

ls -ltr
ls: cannot access ‘boot’: Input/output error
total 20
d??? ? ? ? ? ? boot
drwx------ 2 root root 16384 Mai 10 15:33 lost+found
-rw-r–r-- 1 root root 1874 Mai 10 15:33 tegra194-mb1-bct-ratchet-p3668.cfg

I just see these items after mount step.
sudo mount -o loop clone.img.raw /mnt/clone/

One thing I forgot to mention is that traditional cloning provides the eMMC content, not the external media, unless you are using some other command intended for that. I mention this because I think it is unlikely (unless something has changed) that this command would clone nvme0n1p1:
sudo ./ -r -k APP -G clone.img jetson-xavier-nx-devkit-emmc nvme0n1p1
(I want to emphasize that in the past this would not do what you want, but perhaps something has changed; there is a reason for using when using external media, and perhaps there is an equivalent for clone, but I have no external media so I have never tried)

The I/O error is odd. Was that on the host PC prior to mount of the raw image? I ask because you then listed the mount under loopback. On the host PC, what do you see after the mount to /mnt/clone from:

df -H -T /mnt/clone
# This next command assumes when you created the mount it used "/dev/loop0";
# adjust for the loop device if it differs.
lsblk -f /dev/loop0

Incidentally, if you can mount the NVMe on the host PC, then cloning is simple.

Question for someone from NVIDIA: Has the clone command been updated in R35.x to be able to clone external media?

Meanwhile I followed new documentation r35.3.1 and I can clone the nvme drive.
Maybe the old command sudo ./ -r -k APP -G clone.img jetson-xavier-nx-devkit-emmc nvme0n1p1
requires APP partition to be mounted on /dev/nvme0n1p1 which I don’t see it on my jetson

For the URL you gave, I see it first flashes with initrd (at least that’s what I think it is doing). Then dd is used for actual creation of an image to be placed on a USB external drive. This isn’t true cloning, at least not via the mechanism you might be expecting. The weakness of the dd method is that the rootfs partition is not read-only during the dd; this means content can change during the dd (though “often” this would work ok if the Jetson is not doing anything at the moment). For reference, this is the flash command:

sudo ./tools/kernel_flash/ --initrd <board-name> <rootdev>

(this is destructive to an existing partition)

The URL you gave then uses dd to a USB external drive to do the equivalent of cloning. It is this command which I think won’t work right with external media, which is also the reason why dd would be used instead from a fully booted Jetson:

sudo ./ -r -k APP -G clone.img jetson-xavier-nx-devkit-emmc nvme0n1p1

Did you use dd to clone to a USB external drive?

Also, I’m still interested in the previous command output, regardless of how you got the clone:

df -H -T /mnt/clone
# This next command assumes when you created the mount it used "/dev/loop0";
# adjust for the loop device if it differs.
lsblk -f /dev/loop0

Yes I ran dd if=/dev/nvme0n1p1 of=/dev/usb to generate clone.img.raw inside usb drive.
Later I mounted this clone.raw.img to a loop mount point to see the contents of the rootfs.

While running the dd command in the bash shell of jetson( ssh connection established between host pc and jetson while Jetson is in recovery mode), there is no internet connection , so noone can modify the contents in nvme.

There is neither ssh nor ethernet in general possible in recovery mode. dd is also impossible in recovery mode. Login is impossible in recovery mode as well. In fact there is no bash shell or other user shell, even via serial console, if the Jetson is in recovery mode. So it is likely that unless steps were taken, that the image could in fact change in the middle of the clone. However, since you can loopback mount the image, it is likely the image is ok.

To truly get read-only, while in Linux, you might use “sudo mount -no remount,ro /dev/nvme0n1p1”. Possibly you’d have an issue with “disk busy”.

One further suggestion, before trying to use that clone, is to loopback mount it on the host PC in read-only mode. For example, it might go something like this on the host PC:
sudo mount -o loop,ro clone.img.raw /mnt

Once mounted read-only, see if the filesystem checks out ok (I’m assuming it is “/dev/loop0”, adjust for your case; you don’t actually need this mounted, you could just use losetup, but if read-only, fsck will be happy):
sudo fsck.ext4 /dev/loop0

You also will want to verify that the raw clone has the exact same byte size as the partition. Use “ls -l clone.img.raw” to see its exact size in bytes. Then, while logged in to the Jetson, you can find the exact size of the partition (or if the NVMe is mounted on the host PC):
sudo blockdev --getsize64 /dev/nvme0n1p1

Preferably, that byte size is evenly divisible by 1024 at least twice, and perhaps three times (twice is MiB, three times is GiB, and sometimes you’d name the partition size during reflash while using that clone).

Incidentally, the docs for flashing an NVMe with initrd might differ from flashing to eMMC. There might be separate/different steps to get the content on the NVMe (I don’t have an NVMe, so I’ve never tried).

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