Thanks for your comprehensive explanation!
I will try to mount the file system from external for my nano-emmc later!
Or you could install my project and you donât have to flash anything
Kim
Or the sbts-base project which creates some read/write partitions but is intended to mount the OS read-only with a memory overlayfs. This works around the problem of disk corruption (Due to unexpected power outages for example) causing the boot process to hand. The normal behavior of Linux when encountering some levels of disk corruption is to hang and let the user interact with the console to guide fsck. If on an embedded system you donât have a console then the system simply refuses to boot. In jetpack 5.0.2 which currently doesnât support a frame buffer console the situation is even worse, because then you would have to connect up a serial port console as you wonât get any interaction via a connected monitor and keyboard I understand:
So you might consider this approach even more desirable than the flashing approach because sbts-base does a force fsck -y on the read-write partitions because mounting them and doesnât mount them via /etc/fstab. This means that even if that fails the system will still boot and allow you to connect in via ssh to repair it. All in all a much more desirable approach to pure booting to fsck via a flashed approach in my opinion.
Kim
Oh just some production insights here. The approach to keeping the OS partition mounted read-only came after I release a commercial embedded product back in 2010 (My open source project is actually, the open sourcing of that commercial production from way back then). Then after shipping to customers, they were all coming back with the same problem. Corruption in the disk (Then SD disk) was causing all of the units to hang during boot. A very serious problem to encounter after going into production.
I donât know how product manufacturers for jetson devices are dealing with this problem, but itâs a problem that eventually all product manufacturers will need to face I think.
Just sharing the insight and lession learnt.
Kim
Hi,
I am trying to boot from an external USB drive, following these steps: https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3261/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E01O0HA
Attached are the boot logs
nanoboot1.log (34.1 KB)
Turns out flash drive is not quite the same as ssd even if some flash drive are sell as ssd⊠Probably is what was going wrong
I am on my second Jetson Nano as the SD card slot on the first one failed and stopped holding the Card in, I have been looking for a way to boot externally, would i still need to have that card in the Nano? this could help me a lot to have multiple modules.
- Collin
Wayne, thanks for the very helpful explanations.
Any chance you could update the instructions for mounting rootfs on an external device to include Jetpack 5.0.2?
Currently it states they are only âfor release <= L4T 32.5.1. For rel-32.6.1, please refer to [Flashing to an nvme drive]â however these donât seem to cover mounting rootfs on an external drive but booting from internal emmc.
Just wanted to say this works great for us on the Nano.
Thanks Kim, real life saver.
Oh thatâs super! Really glad to hear this. Thanks for expressing it.
I have some interesting plans for the Jetson Orin series in connection with disk partitioning tricks in the near future. Thereâs some things I can do here that will help with the Seeed Studios Orin based recomputers.
Would love to see that! Our MVP model uses the seeed a203v2 and the nano, but we are exploring using the a603 and the Orin!