An externally powered HUB is almost always superior, especially when working with hardware which draws significant power (and external storage is such a device). You’d need to supply external power to such a HUB to get those advantages; some such HUBs work as an ordinary HUB if external power is missing, but not all do.
Did you use the third party (“seed studio”) software for flashing and for instructions? Unless their hardware is an exact replica (electrically) of the dev kit, then it is likely some (or all) of boot components would fail.
I also want to add that on a developer kit the SD card slot is directly on the module, and not on the carrier board. The third party carrier board models I know of place the SD card slot on the carrier board, and the module is an eMMC model. If this is an eMMC model, then boot (and where to store boot software) is quite different compared to an SD card model (the module model).
As background, Jetsons don’t have a BIOS. They do have the equivalent in software. In a model without eMMC the boot content (basically the partitions which are not the rootfs) are stored in QSPI memory which is part of the module. In eMMC models, all of that non-rootfs content is stored in eMMC. The software for each is distinct and is not interchangeable.
Whenever you boot to external media only the rootfs is on that media. The parts which are equivalent to BIOS and bootloader must remain in the QSPI of an SD card module, or in the eMMC of the eMMC model. In addition to that content differing and being on different storage locations the device tree itself also differs. Different modules require different device trees; different carrier board require different device trees unless they are an exact match of the dev kit carrier board.
Have you used the seeed studio instructions and software? Does your module have eMMC? Does the module have an SD card slot, or is the SD card slot (if any) part of the carrier board? These are all critical even if not using external storage.
It boots from the western digital usb disk when I attach the powered USB HUB to the jetson nano. But sometime my HUB is not able to turn on. Don’t know why. I find that using the “KiwiBird USB C USB-A SD card reader, Micro USB Type C Adapter for card SDXC SDHC TF UHS-I” works better. And it does not need to be powered.
Sorry, I haven’t read the full topic. I just mentioned that because it is a common mistake (the partition may have a filesystem, and fs UUID is different from partition UUID).
Are you able to use backup config in extlinux.conf with a serial console ? If the disk is connected and drivers are in place, you may be able to issue the command. If not, you may issue the same command on any other Linux host with the USB connected. The command will list all block devices connected with two columns, one for NAME (a devfs path) and one for PARTUUIDs.
An extension to what @Honey_Patouceul just mentioned, to illustrate that there is more than one ID (you can do this on the host PC just to see it even if the Nano can’t boot): lsblk -o NAME,LABEL,UUID,PARTUUID
The “name” is just the device special file label in “/dev”. For example, your PC probably has “/dev/sda1” as a partition if it uses a SATA drive (and “/dev/sda” is that disk as a whole). A name in the format of “/dev/mmcblk0” is the eMMC as a whole of an eMMC model; a name similar to “/dev/nvme0n1” is an NVMe drive as a whole…then partitions are an extension to that name). The PARTUUID is a name of a partition such that the particular disk it is on won’t matter.
It gets confusing which to use sometimes, so I recommend that one adds a second or third boot entry in “/boot/extlinux/extlinux.conf” to test things out (then serial console can pick any of them, and if the old entry is still there, then it is a backup; plus other entries can be tested until you find the one which works, and no risk of requiring flash again).