Dist upgrade issue on Jetson nano

L4T release is what gets flashed, JetPack/SDKM is what performs the GUI side of flash from the host PC. Picking a release for one also picks the release of the other; they are tied together. Go to the most recent L4T R32.x since this is what a Nano can use:

I will note that if you install the JetPack/SDKM software, then normally you’d start it via this on command line as a regular user:

If you want to see other earlier releases of L4T other than the one from that JetPack/SDKM, then you’d start it like this:
sdkmanager --archivedversions

If you were to do all of this manually without any help from JetPack/SDKM, then you’d go to the same L4T URL and download:

  • The Driver Package (JetPack/SDKM does this for you).
  • The Sample Rootfs (JetPack/SDKM does this for you).

If done manually (JetPack/SDKM does this for you), then you’d unpack the driver as a regular user. This creates subdirectory “Linux_for_Tegra/” (if unpacked for you via JetPack/SDKM, then this would under “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/”).

From “Linux_for_Tegra/”, if you manually install, you’d then “cd rootfs”. From there you would unpack the sample rootfs package with sudo (I can give more information on that if you wish). Then you’d cd back to “Linux_for_Tegra/”, and complete setting up the rootfs via the command:
sudo ./apply_binaries.sh

To flash the Nano itself the Jetson must be in recovery mode with the correct micro-B USB cable connecting Jetson to host PC. There are documents at the L4T URL for SD card setup, but I am assuming you are flashing the Nano itself since the QSPI memory on it needs to match the release version of the SD card (or at least be a compatible version; the easiest way to be sure of that is to flash the Nano).

I recommend using sdkmanager (or sometimes sdkmanager --archivedversions), but with the Nano in recovery mode and the micro-B USB cable connected, this would flash (and might take some time):
sudo ./flash.sh jetson-nano-devkit mmcblk1p1

Incidentally, the “mmcblk1p1” is more or less a pointer to the boot device which QSPI uses to transfer control to during boot. mmcblk0p1 is used for eMMC models, while mmcblk1p1 is used for SD card models. You will possibly still need to prepare the SD card since this is installing to QSPI to point at the SD card (not the same as flashing the SD card).

Every L4T release has documentation for that specific release at that URL.

Note that after a flash the Jetson will self-reboot. If the SD card is in it, then it should go through first boot account setup. This is needed for ssh to complete installation of any extra packages. However, you can set up the account prior to flash like this (keep in mind that normally this is used with eMMC; there are probably some instructions for making this content apply to the SD card, but I’ve not done this):
sudo ./tools/l4t_create_default_user.sh

What that does is put an account and password of your choice on the “Linux_for_Tegra/rootfs/”, and this is what is used to create an image. I’m not positive, but if you have an SD card image without an account, then quite possibly you could mount it at the “Linux_for_Tegra/rootfs/” and use l4t_create_default_user.sh directly on the SD card (useful if you have first account setup issues, otherwise I wouldn’t do that). You would not want the SD card mounted there during a flash though.

Hi, thanks for all this relevant support, I installed the SDK on a Laptop with ubuntu 18.04 , but i have NO detection of the Jetson Nano on USB port.
And when i switch on the board, this is what i get on the screen.
Hoping you can provide some more support, thanks in advance

Are you certain that the Nano is in recovery mode? Are you using the provided micro-B USB cable? Many “charger” cables have only one or two strands of copper in the data side, and so they are quite low quality and tend to fail, but micro-B cables shipped by NVIDIA are high quality for data.

I don’t think dist-upgrade should fail, but there might be some dependency that “isn’t quite right”. I do expect 100% failure for any use of any L4T R34.x on a Nano since none of that boot content is compatible with a Nano. Any kind of R34.x install would require a complete reinstall, including flash of the Nano and SD card install. That R34.x just never supported the TX1 hardware (and a Nano is a small form factor TX1).

for usb, i’m 100% sure, and i tried several cables
for the board mode, look at the screen capture, it is written “emergency mode” and not recovery mode
i also tried to reboot (power on) with recovery mode pin tied to gnd, but without success

The screenshot is hard to read, it is a bit blurry in places. Serial console logs are always superior when available.

There isn’t really an “emergency mode”. If you are looking at something from R34.x under UEFI, then you are looking at code from a release which is incompatible with a Nano. You’d have to have R32.x boot content.

However, it should enter recovery mode correctly regardless of which release is installed.

To have more available space, i made a symbolic link from , say /var/something or /etc/something to a directory on the 128 Gb sdcard called /media/misc, and then i reformatted the sdcard so the /media/misc disappeared , implying the “fatal” boot error.
Is it possible to reinit the qspi from a sdcard with a command line from the jetson nano after the boot ?

Is that 128 GB SD card USB? Or is it part of the SD card which plugs in to the module itself (not the carrier board)? There are documents on how to use the full size of the SD card if it plugs into the module itself, and you could avoid what follows and simply make the whole thing available. Someone else can explain this, but the documents for your specific L4T/JetPack release tells you how to make the entire SD card available. What follows is if your SD card is separate from the one providing the rootfs, e.g., a USB external SD card.

Understand that requirements for success of something not used during boot will differ from requirements of something that is used during boot. “/var” must be present on the rootfs during boot. An example of two places which tend to consume a lot of space, and which could be missing during boot and not cause boot failure, are “/home” and “/usr/local”. “/var” must never be missing during boot.

Normally one would mount a partition at the correct location instead of using a symbolic link. They can be equivalent, but you can’t control order of access of a symbolic link during boot the way a partition mount can be.

In your case the rootfs is no longer valid and needs to be repaired or recreated. The QSPI won’t care about “/var” missing since “/var” is not a boot stage software. If you still have the “/var” content on something else whereby you can mount both at the same time on a host PC (e.g., two SD card readers or two separate partitions of a single SD card), then you might be able to just fix it (but you’d have to be careful to preserve permissions and any device special file or named pipe).

What I’ll describe is how people would normally offload just “/usr/local”. The same thing applies to “/home” (I do that on my host PC; when I upgrade my Ubuntu release I just remount my home content; or if I multiboot between Ubuntu 18.04 and 20.04, it just remounts “/home” on the correct rootfs and I get the same home content regardless of which I boot to).

When you first boot the Jetson will mount “/”, which is the root of the filesystem (thus the rootfs). Assume you have content in “/usr/local” (see “sudo du -h -s /usr/local” to find out how much is stored there). I’m going to assume your SD card partition is “/dev/sda2” (it might be quite different, adjust for whatever partition the extra content is on).

If you do this:
sudo mount /dev/sdb2 /usr/local
…then all previous content in “/usr/local” no long shows up (it’s still there, but you can’t access it).

You could then:

  • Either sudo umount /usr/local
  • Or sudo umount /dev/sdb2
    …in which case the original “/usr/local” content would show up again.

If you were to have a duplicate of the original “/usr/local/*” content on “/dev/sdb2”, and then you mount “/dev/sdb2” on “/usr/local”, you wouldn’t be able to tell the difference. However, any changes made would go to the SD card, and upon umount, the content would revert back to the original “/usr/local”.

Mounting a partition at a location hides original content and makes the mounted partition become the memory storing it. You could (if done properly, e.g., via rsync) copy the original “/usr/local” to a temporarily mounted “/dev/sdb2” (you could mount it in “/media” or some temporary location), you could then delete the original “/usr/local”, saving space, and then mount the sdb2 partition on “/usr/local”, and you’d have all of your original content available. The space would be on that new partition.

Mount order matters. You have to mount “/” first. This is the rootfs, and you don’t want to mess with that. If you then and only then mount “/usr/local”, it would do what you want. As another example, suppose you have a copy of your original “/home” on the SD card. The system boots, and then you mount “sdb2” on “/home”; if you had properly synced the old data onto sdb2, and then deleted the original/home” content, things would work exactly as you expect. Now let’s say you also want yet another partition to save space on “~/nvidia” (I do this). I’ll pretend the device partition being mounted is “/dev/sdc1” (I’m making that up as an entirely new drive’s first partition formatted to ext4), and that my user login name is “ubuntu” (which means “~” is the same as “/home/ubuntu”). This would work after boot:

sudo mount /dev/sdb2 /home
sudo mount /dev/sdc1 /home/ubuntu/nvidia
sudo umount /home/ubunt/nvidia
sudo umount /home

(note that if you “cd” to a directory on one of those mounts, then you cannot umount until you exit that location…attempting to do so would reply with the error that the drive is busy)

It is important to know that you can automate mount, but if you do so in such a way that mount is mandatory, then not having that drive would cause boot to halt and wait forever. Since you have an SD card partition, you might be tempted to remove the SD card, but done incorrectly, this would make boot fail until the SD card is back in. The place to automate mount is the file “/etc/fstab”. This is also where you must be careful, or else boot will fail.

I assume any partition listed is formatted as ext4, not VFAT or something else. Assuming your mount point is “/usr/local”, and assuming your partition is from “/dev/sdb2”, then this would automatically mount the partition and not fail if the SD card is missing (this is a line in “/etc/fstab”):

/dev/sdb2  /usr/local  ext4  defaults,nofail    1  2

The “1” just says this is something that would be “dumped” during a backup (it would be backed up), and the “2” is the order of checking filesystems. The rootfs is “/”, and this is the “1” even if you don’t see it, and since the SD card is mounted after rootfs, it is “2” instead of “1”.

If the partition were mounted on “/home”, and then another is mounted on “/home/ubuntu/nvidia”, you’d have to increment the “2” of "/home/ubuntu/nvidia" to a "3" (rootfs is 1, home is mounted on that as the second mount, so it becomes 2, and /home/ubuntu/nvidiais third since it mounts on/home`…they have to be checked in order so the most root of the tree is checked first).

The “nofail” is what makes it possible for boot to continue even if the extra SD card partition is missing. The “nofail” cannot be used with mandatory partitions, e.g., it can’t be used with “/” or “/var”.

If you wanted to prepare partition “/dev/sdb2” to become a replacement for “/usr/local”, then you might start with sdb2 mounted somewhere temporarily, e.g., maybe it automounted on “/media/1000”. That’s ok as a temporary mount point.

But is it ext4? If you’ve never formatted it, then it is more likely VFAT. You could delete content and reformat it like this (be very careful to use this only on a partition which is not in use; use umount first):

sudo umount /dev/sdb2
sudo mkfs.ext4 /dev/sdb2
# Any temp location works:
sudo mount /dev/sdb2 /media/1000
# This preserves everything 100% correct while copying from "/usr/local" to the SD partition:
rsync -avcrltxAP --info=progress2,stats2 --delete-before --numeric-ids --exclude '.gvfs' --exclude 'lost+found' /usr/local/ /media/1000
sudo umount /dev/sdb2
# Now edit /etc/fstab as mentioned above.
# Now either reboot or simply test it out:
sudo mount /usr/local

If the above works, then the fstab line is correct, and the content in “/usr/local” will look just like it did. The original “/usr/local” content is still there, and if you test for some time and find it acceptable, you could delete the original “/usr/local” content.

I will probably be gone for about a week so I won’t be much help for some time, but if you are just using the original SD card and want to make full use of it, then as mentioned at the start, you don’t need to do any of what I just mentioned and someone else can help expand to use the full SD card. It is useful though to make this method known since other people will run into the situation.

Thanks for all these valuable infos, i finally succeeded to use sdkmanager and to reinstall all, the core event being the detection on USB from the Ubuntu Laptop.
However, i now have another issue : threre is no (more) sdcard detection on the external micro sdcard …it was fully operational in the first days

What is “external sdcard” here? Is this board from specific vendor?

the slot here inside red circle

maybe i have an idea : my board is a “Jetson Nano Developer Kit 16G eMMC”, but with sdkmanager, after detection on usb , i had to choose between “jetson nano” and “jetson nano developper kit”, and i did NOT choose “jetson nano developper kit”
so maybe my device tree is wrong, with the external sd card slot missing.
in this case, do i have to remake the complete process (so put in recovery mode, then use sdkmanager) or can i “patch” something ?

or maybe i selected the right model. i’m confused :


I explained this many times. This is a misleading board naming from your board vendor. Please check this post.

If your board is emmc module, and it still has sdcard slot, then it is not NV devkit.

And please contact board vendor for customized BSP.

I contacted them (monica at smartfire dot cn) and received a link containing dedicated instructions :
I will follow them, lets hope …

Yes, the SD card boot section looks have correct info to enable SD slot.

OK far too complicated for me , i give up , i cannot spend so much time, i’d rather buy another model with simpler installation

The detail which sticks out is that the carrier board is 3rd party. This is an eMMC model intended to boot to that. There might be instructions from the vendor to do so. However the driver and device tree will be provided by them for any boot stage driver (that means for the SD card…it is different than one on a purely SD card model without eMMC).

I wouldn’t give up, that’s a nice model. It’s just a case of flashing with their software. If one way doesn’t work, try the next (targets for example).

Hi , i finally did it following the instructions provided.
Many thanks for your support and encouraging messages :-)
Now i aim at using AI tools, is it the same forum for support requests ?

Tools that run on a Nano (or any Jetson) tend to be supported on these forums under that particular Jetson model. So just ask a new question on this same forum. I think you will be happy in the end with an eMMC model since they are somewhat faster than an SD card model. You might be running out of space or something, and you could post on this same forum how to solve that.

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