Boot Jetson AGX Xavier directly with configured SSD storage

Boot Jetson AGX Xavier directly with configured SSD storage

I found after referencing online
One is to mount the SSD to the [/home] directory, and the other is to directly use a blank SSD to build the system from scratch. These are not what I want

I now have an SSD storage that has been configured, and I want to boot the host directly from the SSD, that is, put the SSD directly into the [/] root directory
In this way, the host directly reads the SSD when it starts up. How can I do this?

I installed ubuntu system on my laptop
I first installed the SSD in the card reader, then connected the computer

Find the device name of the SSD [/dev/sda1]

Use the [dd] command to compress and backup the configured system
sudo dd if=/dev/sda1 conv=sync,noerror bs=32M|gzip -c > nano_SSD_back.img.gz

The compressed file size is 80G

Burn after completion
Then connect the new SSD to the computer
Decompress and burn
gunzip -c nano_SSD_back.img.gz | dd of=/dev/sda bs=32M

When it was about to finish, there was an error warning [No space on device], I ignored him

Then the SSD can be recognized without being plugged into the computer

I followed the tutorial and it failed
GitHub - jetsonhacks/rootOnNVMe: Switch the rootfs to a NVMe SSD on the Jetson Xavier NX and Jetson AGX Xavier

the steps in it
【./copy-rootfs-ssd.sh】
In this case there should be a problem

The above content is all translated by me using google, because my English is very poor
If someone can solve it, I would be very grateful

Hi,
You can directly use sdkmanager to flash if your jetpack version is >4.6. No need to use method from jetsonhacks.

Also, jetsonhacks is not official website.

FYI, the above is wrong. Creating the backup that way can work, but you’d have to restore sda1 to “of=/dev/sda1”. You’re overwriting the metadata at the start of the disk when sda1 starts at sda. If you had created your backup from dd of “if=/dev/sda” (instead of “sda1”) then it might work if the disk is large enough. Even so, you should use JetPack as well because there are other partitions (in eMMC) even when you use rootfs on an external device.

I don’t understand, so I’ll ask another way

I have tried to use the Ubuntu-based Jetson Nano host to back up and burn multiple hosts before, and I used the [dd] command to burn successfully, because it only needs one setting TF card.

So now I am using the Jetson AGX Xavier host, I have many hosts now, and now I have configured one of the hosts, and the system has [autoware] [Cartographer] [Gazebo] [Labelmg] [darknet] [ yolov4]

But now other hosts are blank, so how do I want to make the system of all hosts the same, so that the content of all hosts is the same

  1. Backup your file from system A to system B is one issue.

  2. How to boot from SSD on jetson AGX Xavier is another issue.

Please be aware that jetson AGX does not support SDcard image. Please follow the method here to put the files on the NVMe drive. And uart log is required to see if your device is really boot from nvme.

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3261/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E0QN0HA

Are all SSDs the same size (or destination can be larger than source SSD)? If so, then just clone the whole disk. For “dd” you’d use “sda” instead of “sda1”. Then you’d restore to the replacement disk, and assuming it is sdb, then you’d copy to “sdb” (or “sda” if you disconnect one disk and add the other and the new one also shows as “sda”).

If you are creating a file on the Jetson itself which is a backup of the entire filesystem, then you are bound to run out of space and the image will fail. Did you know that if you are networked that you can pipe the dd output through netcat (or other network methods) and avoid a file on the Jetson by writing directly to another computer which has the destination SSD? If you are on a host PC and have both source and destination disk, then you can directly copy from source to destination and skip the intermediate file.

Btw, it is “bad” to use dd with “noerror” if you are not recovering data from a failing system. I use this to extract images from partially failed hard drives, but never use it for cloning of a working system. Also, I think the “sync” will slow down copy a lot (though it shouldn’t hurt the result).

Sorry, I’m a little confused here in the double quotes in your answer.

You mentioned in your answer: SSD storage size is all 128G
What you mentioned [If you are on a host PC and have both source and destination disk, then you can directly copy from source to destination and skip the intermediate file] means that the configured Jetson AGX Xavier host should not be removed from the SSD first. , then use the card reader to connect the new SSD, then insert it into the Jetson AGX Xavier, and directly use the [cp] command to copy the configured system to the new SSD?

linuxdev, sorry, I re-modified the network configuration, so I can see it clearly now. Regarding the problem you mentioned, I noticed this problem later, so I re-modified it.

sudo fdisk -l

This time, select the device as [/dev/sda]
sudo dd if=/dev/sda conv=sync,noerror bs=32M|gzip -c > nano_SSD_back_2.img.gz

Publish a process view every 10 seconds
sudo watch -n 10 pkill -USR1 -x dd

The backup is completed, the main thing now is that I don’t know how to change the mount location of the SSD to the root directory [/]

Regarding the [sync] and [noerror] issues you mentioned, I refer to my experience in backing up the TF card of the nvidia nano host

Dump the uart log first and modify the extlinux.conf under the driver that gets loaded in cboot…

If the original SSD and new SSD can be mounted on the same host at the same time, then you just use dd to copy from original to clone destination and don’t use an intermediate file. Making a copy on the Jetson to the Jetson basically defines “not enough space”, although if you get lucky the compression will be enough. My point is that with the SSD connected to the Jetson an intermediate file later being moved to a host PC for clone is usually not going to work well. If you can take the SSD from the Jetson and mount both this and the destination of the clone on a separate host PC, then it is trivial.

One can also pipe the output of dd through netcat and on the separate host PC (which has the clone destination) use the netcat to pipe to dd on the host PC and write to the destination clone SSD without any intermediate file (the pipe between two separate computers substitutes for an intermediate file).

One would never use “cp” for cloning unless circumstances are very specifically allowing this to copy all files without loss of permissions and without odd behavior from device special files (imagine if you use “cp” to copy “/dev/urandom”…it is an infinite random number generator and cp will gladly keep copying until infinite content is copied). Sometimes this is ok, but using dd is better for partition copies.

Thank you very much both, WayneWWWlinuxdev,I asked the engineers of nvidia, after this period of testing, I finally completed this function,
Mainly because I did it normally: install the JetPack SDK to flash the machine, then use the rootonnvme method to replace it with an SSD, then shut down, remove the SSD and install a new burned-in SSD, and then I start it smoothly.
In general I have no doubts now

1 Like

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