The USB drive is the new 3.0 one I picked up to replace the 2.0 as discussed earlier in the thread. It contains an rsynced copy of the original (faulty) rootfs flashed to the Jetson. I want to run some more checksums tomorrow to see what changed in this new flash/install but then I’ll wipe it and rsync over the working eMMC and I imagine it will boot fine. I’m still wondering why the NVMe is never checked under CBoot… do you know why this is? Why does it skip from usb to fixed storage? Is fixed storage supposed to include NVMe? Surely I’m not supposed to run the flash command to switch the rootfs target as this seems like it was the old way instead of the new dynamic cboot way??
It contains an rsynced copy of the original (faulty) rootfs flashed to the Jetson.
Please try to use fresh rootfs as you just got from sdkm.
As for the NVMe, it is not there because it is not supported on Xavier series SoC at all. Our document has that info.
Nope still not working and is easily reproducible. The steps and UART logs are as follows. Not thrilled about the increasingly apparent fragility of this whole ecosystem and having to do what should have been the tester’s job.
- delete nvidia download folder
- delete nvidia target HW image folder
- run SDK Manager and flash Jetson
Test A - FAILS
- boot up Jetson and rsync copy to freshly formatted USB (~15GB)
sudo rsync -axHAWXS --numeric-ids --info=progress2 --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/usr/tmp/*","/run/*","/mnt/*","/media/*","/var/cache/*","/","/lost+found"} /* /mnt/
- edit extlinux.conf on USB to root=/dev/sda1
- reboot Jetson - FAILS USB AND EMMC
uartlog_2021032303.txt (98.4 KB) - disconnect USB and reboot Jetson - SUCCESS WITH EMMC
uartlog_2021032304.txt (27.5 KB)
Test B - FAILS
- run flash.sh to generate Jetson image (DID NOT DELETE DOWNLOAD OR TARGET HW IMAGE FOLDER)
sudo BOOTDEV=sda1 ./flash.sh --no-flash jetson-agx-xavier-devkit sda1
flashlog_2021032301.txt (23.9 KB)
- rsync copy to freshly formatted USB (ONLY ~5GB)
sudo rsync -axHAWX --numeric-ids --info=progress2 --exclude=/proc ./tmp_system/ /mnt
- plug USB into Jetson and reboot - FAILS USB AND EMMC
uartlog_2021032305.txt (98.5 KB) - disconnect USB and reboot Jetson - SUCCESS WITH EMMC
uartlog_2021032306.txt (27.5 KB)
WOW! SOLVED! Okay this is why taking breaks is important. As I was driving down the road I kept mulling over why the Jetson could read the partitions on the USB drive yesterday but suddenly utterly failing to do the same thing today with a fresh now uncorrupted kernal and rootfs.
Suddenly it hit me… in my near rage at having to wipe my Jetson and re-flash yesterday I was determined to make sure nothing else could possibly interfere and be blamed, as I was fairly convinced the re-flash would never work, was a waste of time, and was determined to prove it. So yesterday I had decided to use the HDMI port instead of the Display Port over USB-C (which my display additionally draws power over this same connection to power itself). Earlier today I had gone back to using Display Port over USB-C but… realizing this and going back to HDMI instead of Display Port over USB-C in fact allows the Jetson to now boot from USB without issue as reflected in the UART log below. What got me even thinking to switch to HDMI yesterday was an odd issue I had experienced weeks ago when powering the Jetson from USB-C (instead of the barrel plug) and simultaneously trying to detect/mount/read/use a Samsung T5 SSD that I plugged into the Jetson’s other USB-C port. At the time this got me thinking that the Jetson can’t operate the ports independently and that their “mode” is somehow linked. So if one is drawing power first then the other can’t be used for reading data (although using Display Port over the USB-C does work… data output I suppose).
So long story short I have a ThinkVision M14 display that uses Display Port and draws power (when available) over a single USB-C connection. And apparently having this display plugged in to USB-C will break USB during boot (USB does function when the OS is up so thats something I guess). Just an FYI as I think this and the SSD issue (powering the Jetson over USB-C preventing a USB-C SSD from being detected/read/used simultaneously) are pretty major things people should be aware of. Could prevent countless hours of trial and error…
uartlog_2021032307.txt (29.0 KB)
I am sorry to say the story is a little bit too long so not sure what was the exact method you resolved the usb boot issue…
Could you give few brief statement to share us what did you try?
If you can’t read what fits on an single phone screen then best of luck to you…
And apparently having this display plugged in to USB-C will break USB during boot (USB does function when the OS is up so thats something I guess). Just an FYI as I think this and the SSD issue (powering the Jetson over USB-C preventing a USB-C SSD from being detected/read/used simultaneously) are pretty major things people should be aware of. Could prevent countless hours of trial and error…
Oh, thanks for pointing out.
Hi. I just followed the instructions from carolyuu (thanks!) on Mar. 18th 2021. I succeeded with my 256GB Sandisk USB C flash drive with a 16GB boot (sda1) partition, but it failed with a 256GB partition. What is the hard limit? Is this a bootloader-derived hard limit? Any feedback welcome.
I have also tried to resize a working USB C boot partition, but then booting fails with the same error messages hogan.k was getting initially.
I got a step further: When setting the initial partition to 16GB as in carolyuu’s post, the Xavier AGX 32GB will boot from that stick. I tried 32GB and 64GB, and the system would not boot. I was unable to connect to the serial console that would let me perform the terminal-based setup routine (with no HDMI monitor plugged in). I tried /dev/ttyUSB0 to …3 with no success. However, when I booted from the 16GB USB stick partition (set up on a 250GB USB3 stick, the system went straight into the Ubuntu-based setup and asked for the partition size. It offered to fill up the entire USB stick (I gave it all 256GB), then prompted to set up username and password. Upon completion the system rebooted itself and I got a working system with a root file system that has now the remaining free space of a total of 256 GB left.
The content of the internal flash (devkit’s 32GB storage module) was preserved and not altered. The “installation” of jetpack was made to the USB device only.
My question is whether I could clone the content of this stick back with rsync to a backup folder in order to preserve a “default” state for experimenting that I would copy back whenever I would like to test software deployments. Would it be sufficient to use a rsync command on the stick on another Linux computer and create bootable copies? Would it boot off a copy of the content of the file system now residing on the USB3 stick?
I created the 1st “APP” ext4 partition at 16GB - boots. Even after the GUI installer expanded the partition to 256GB, the system would not boot any longer. I then started downsizing the partition and by trial and error ended up with a 19.5GB bootable partition. Somehow the bootloader seems to ignore larger partitions on USB. This is not the case for the internal flash memory module that contains a bootable partition close to 32GB.
Does anyone how if there is a similar hard limit to an internal memory module? If so, what size is the limit?
I would like to deploy an OS/application image to collaborators who will not have access to a Ubuntu computer to install an image directly on the internal memory and hence thought it was a good idea to have them boot from USB3. Speed-wise, USB3 seems acceptably fast for this project.
Any help or suggestions would be highly appreciated. I would prefer to have everything in a single partition that fills up the entire media.
For the moment, I restricted myself to the boot partition (19.5GB) and created further partitions for extra applications/reference data on the USB stick. These partitions are then mounted at startup.