One thing I’d like to know is the complete layout of the partitions on that disk. What is the output from “ls /dev/nvme*”?
Your suggested extlinux.conf would work if “/dev/nvme0n1p1” is an ext4 formatted Linux file system created from one of these combinations:
- Sample rootfs plus apply_binaries.sh with proper option
- A proper recursive copy of the existing file system.
- A clone of the existing file system copied to the SSD.
The naming of a new “root=” leaves the boot files used for configuration on the eMMC and does not switch to the SSD for root file system until after the kernel takes over. Once the kernel takes over it is pure Linux and no longer u-boot; “/boot” becomes irrelevant after that, and so although there would be a “/boot” from the SSD showing up, that particular incarnation of “/boot” would be inert. Things should just work with this edit of extlinux.conf regardless of how you choose to create your new root file system.
Method 1, rootfs+apply_binaries.sh:
For sample rootfs plus apply_binaries.sh you can just mount the drive on the Jetson or on the host, copy the “Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2” (or whichever version you use) to the SSD, and run:
sudo tar xjfp Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2
rm Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2
Wherever you have the driver package installed there will be “apply_binaries.sh”. The trick is it has to be on the same machine as the SSD. You can do this from the Jetson if you copy the driver package there (after that you can delete the driver package). Assuming the SSD is mounted on “/mnt” and that you unpacked the driver package there:
cd /mnt/Linux_for_Tegra
sudo ./apply_binaries.sh -r /mnt
cd
sudo umount /mnt
With the extlinux.conf edited, reboot.
Method 2, Recursive Copy Preserving Permissions:
This can actually be trickier than it sounds. You need to copy real files only, not pseudo files (“/sys”, “/proc”, many temp files, and “/dev” are pseudo files). This can also be very slow because you are copying one file at a time. I won’t give the details on this since there are so many ways to do this (or to do this wrong), but one way is to use rsync while telling it to not cross file system boundaries and to preserve everything. Another is with a combination of a series of “find” statements, also telling it to not cross boundaries, using option “-print0”, and piping it to xarg with it using option “-0”, and this in turn feeding cp.
Method 3, Using Clones:
This takes longer than rootfs+apply_binaries.sh, but will give you a perfect copy of your existing file system for safe keeping on your host. Advantage…safe copy. Disadvantage…lots of disk space and time required.
To clone the root partition, see this:
http://elinux.org/Jetson/TX1_Cloning
https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149
The clone could be loopback mounted and used to manually copy to the SSD, but since it is already clean of any kind of pseudo files, it’s very straightforward. Using sudo a recursive copy with something like “sudo cp -adpR” from the clone to the SSD partition would do everything you need. The clone essentially filters out all of those files you’d have to go through efforts to avoid from a running system.
The easiest method is just create a new file system and apply_binaries.sh. If you want to keep what you have already set up, then I recommend the clone and copy onto the SSD. If you are adept with find, xargs, and cp with preserved permissions, and want to avoid the clone while still needing to preserve the original file system, you could do it the hard way (or the slightly easier variation using rsync which is a bit safer than step-by-step find/xargs/cp).