What that URL does is to put the rootfs image into read-only mode prior to using dd to copy the entire partition (which is valid and should work). The ssh side is just piping the data from the dd read operation to the dd write operation on a remote system. I have not tried that specific command, but some comments may help. There may be cases where you need to adjust with “sudo”. I personally use private keys for ssh from my PC to Jetsons, and thus no password is used. Additionally, I temporarily activated the root account, added ssh keys for that, and then deactivated the root account again…as a result I can simply “ssh root@xavier_address” and it works without sudo (making ssh development dramatically easier while keeping the root account deactivated). I would actually have to remove my keys to experiment with using sudo directly, so YMMV.
If your Xavier has address “xv” (I’m abbreviating, maybe “xv” is really 192.168.55.1), and the host PC has the address “pc” (also an abbreviation, maybe “pc” is 192.168.55.100), then from the PC side you could use the PC to see and read various commands. For example the host could see the partition sizes with:
ssh user@xv df -H
…and you would see the “df -H” output.
The host could tell dd to run and combine that with the dd line on your PC, and is a rearrangement of what I see you used:
ssh user@xv "dd if=/dev/mmcblk0p1 | dd of=image.raw
I think your earlier command may have been intended as running from the Jetson side (instead of the PC side originating), and this could simplify sudo. A rearrangement which might work (haven’t tested) is something like this:
sudo dd if=/dev/mmcblk0p1 | ssh user@pc dd of=image.raw
Keep in mind that regardless of which side originates the dd command the Jetson side must be in read-only mode to prevent your image from changing in the middle of the stream (which would give you a corrupted copy of the actual partition). This part of your URL is the part where this is accomplished:
sudo echo u > /proc/sysrq-trigger
From the PC side you could try this if you do not want to be logged in to the Jetson:
ssh user@xv sudo echo u > /proc/sysrq-trigger
Keep in mind that the image which is cloned will be the image from a running system with your user logged in. An actual clone using flash.sh and a recovery mode Jetson guarantees that not only is the partition read-only, but also that the state of the partition is without logins. If you had previously logged out and shut down correctly, then your image will reflect this. If you had previously performed an unclean shutdown, then the clone would also reflect this and try to replay the journal upon boot.
Since I cannot directly test, I’ll suggest what may have caused this:
Directly piping content to ssh may have interpreted a “-” in the data as an argument to dd or to ssh. This is where programs like cpio come in handy…they serialize this and essentially stop stray special characters from randomly being interpreted.
If I were to use cpio to edit an initrd (which is a cpio/tar archive filesystem), then it would go something like this (demonstrates unpacking an old initrd and then creating a new initrd from the edited content with cpio in the middle):
https://forums.developer.nvidia.com/t/xbox-360-controller-through-usb-hub-broken-in-jetpack-4-x-works-in-jetpack-3-x-not-enough-host-c/110621/2
For your case take a close look at inserting this in the middle of your pipe prior to going to ssh:
sudo cpio --quiet -H newc -o
Take a close look at adding this to the final write of content at the other side of the ssh:
sudo cpio -idm
These are just inserted in the correct place with piple “|” symbols.
There are other ways to make a safe stream, e.g., rsync works with binary files and streams across two computers.
The simplest way is to just clone with flash.sh. Example if host PC has a lot of spare space (over 35GB) and the Jetson is attached in recovery mode:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-xavier mmcblk0p1
Clones produce both a “.img” file and a “.img.raw” file. The sparse “.img” file is much smaller than the full raw clone, but is mostly worthless since it can only be used for flashing and there is no ability to manipulate or view the content. I throw out the “.img” and keep the “.img.raw”. If I am done using this then I run “bzip2 -9” on it for storage. Due to size even a simple file copy takes a long time, and bzip2 could take a couple of hours.
The raw clone can be loopback mounted, repaired, examined, so on, and then used to directly flash from it. In theory so could the dd version of this, but I would expect more consistent success under corner cases from clone.