I was working on a project with my Nvidia Jetson Nano. I was accessing remotely with NoMachine, when suddenly the connection failed. I tried to reboot it, but the connection could not be re-established. So I connected the Jetson Nano directly to a screen, and after a reboot I saw this screen.
I tried connecting to the Jetson Nano with ssh but I got the following:
ssh -p 4000 root@192.168.2.2
kex_exchange_identification: Connection closed by remote host
I also did the following things: disconnected all the sensors/devices that were connected to the GPiO pins, removed the wifi card.
I am using a 5V 4A power supply. There is a fan connected to the Jetson Nano and mounted on top of the heat sink.
Does anyone know what is wrong and how I can get my Jetson Nano back working again?
since it also contain SPI parts you should update all together, assume you’re only update image to the SD-card and plug it into your Nano devkit caused the failure.
could you please put Nano device into forced-recovery mode, and installing it again with SDKmanager to the latest JetPack release.
thanks
I tried booting into forced-recovery mode (by shorting the appropriate pins), but apparently it does not boot (the fan is spinning, the green light next to the micro-USB port is on, but I have no display output).
What do you mean by ‘installing it again with SDKmanager to the latest JetPack release’.
Forced recovery is not normal boot, and by itself does nothing more than set the Nano up for flashing. JetPack/SDK Manager is mentioned because this is for flashing the Nano. I saw in your previous logs lots of filesystem errors, and so flashing with a new filesystem is likely the best “next test” (this will erase the SD card though and overwrite with a new install…you could save a copy of the image on your host PC with dd if you do not want to lose this, but there is no guarantee that the filesystem is sufficiently intact to recovery it).
FYI, there were a lot of checksum errors of the filesystem which apparently was too severe for fsck to repair. A dd copy of this image on the host might allow manual repair, but there would be pieces of the system missing.
Simply flashing again is what I would advise. If you want to try and recover something, then it depends on whether this is an SD card version or an eMMC version. Is this on SD card? If so, do you have an SD card reader you can use with your host PC? If you have a reader, and you monitor “dmesg --follow” during insert of the SD card, what do you see?
I am guessing this system is being powered down incorrectly, e.g., by cutting power. Both SD cards look to be working correctly, and without error. The error is from the ext4 filesystem. Orphan nodes and nodes being recovered is a sign of failure to write content before power is lost. Either intentional power down, or else some sort of crash condition which is so extreme there is no possibility of writing unwritten data. Has the system had power cut while running, or a crash which prevented normal shutdown?
please also access NVIDIA SDK Manager for environment setups.
if you had install with SDKManager before, there’s system image save to your machine locally,
for example, you may check the path for JetPack-4.2.2 release images, ~/nvidia/nvidia_sdk/JetPack_4.2.2_Linux_GA_P3448/Linux_for_Tegra
you may enter the folder and enable flash script to flash your board again, please refer to Flash Script Usage for guidance.
please flash the Nano platform with the JetPack release image completely with below command.
i.e. $ sudo ./flash.sh jetson-nano-qspi-sd mmcblk0p1
While trying to flash the board with the SDKManager I get these errors:
16:55:48 ERROR : Drivers for Jetson : tar: Linux_for_Tegra/bootloader/tos.img: Cannot create symlink to ‘tos-mon-only.img’
16:55:48 ERROR : Drivers for Jetson : : Operation not permitted
16:55:49 ERROR : Drivers for Jetson : tar: Linux_for_Tegra/jetson-nano-qspi.conf: Cannot create symlink to ‘p3448-0000.conf’: Operation not permitted
16:55:49 ERROR : Drivers for Jetson : tar: Linux_for_Tegra/jetson-nano-qspi-sd.conf: Cannot create symlink to ‘p3448-0000-sd.conf’: Operation not permitted
16:55:49 ERROR : Drivers for Jetson :
16:55:49 ERROR : Drivers for Jetson : tar: Linux_for_Tegra/jetson-tx1.conf: Cannot create symlink to ‘p2371-2180-devkit.conf’: Operation not permitted
16:56:00 ERROR : Drivers for Jetson : tar: Linux_for_Tegra/jetson-nano-emmc.conf: Cannot create symlink to ‘p3448-0000-emmc.conf’: Operation not permitted
16:56:00 ERROR : Drivers for Jetson : tar: Exiting with failure status due to previous errors
16:56:00 ERROR : Drivers for Jetson : [exec_command]: /bin/bash -c /tmp/tmp_NV_L4T_DRIVERS_T210_COMP.sh; [error]: exit status 2
16:56:00 INFO : Drivers for Jetson : [ Package Install Finished with Error ]
16:56:00 INFO : Drivers for Jetson : [ 4.00 KB used. Disk Avail: 15.33 GB ]
16:56:00 INFO : Drivers for Jetson : [ NV_L4T_DRIVERS_T210_COMP Install took 36s ]
16:56:00 ERROR : Drivers for Jetson : [error]: Run commands failed at step Install: command /tmp/tmp_NV_L4T_DRIVERS_T210_COMP.sh finished with error
16:56:00 INFO : Drivers for Jetson :
16:56:00 ERROR : Drivers for Jetson : command terminated with error
16:56:00 ERROR : Drivers for Jetson : Install ‘Drivers for Jetson’ failure, command < using adapter to install NV_L4T_DRIVERS_T210_COMP@JETSON_NANO to /media/anton/THEO/anton/nvidia/nvidia_sdk/JetPack_4.4_DP_Linux_DP_JETSON_NANO > terminated with error.
My situation: I’ve been running a Jetson Nano in headless mode since November 2019. I powered it down a few weeks ago because I was reorganizing my small computers. Today when I tried to boot it wasn’t responsive in headless mode (I could not ssh to it). I then connected it to a monitor, keyboard and mouse. The boot process got through the NVIDIA logo screen, but then the boot log showed several failures, including the display environment and NetworkManager. Then it hung up completely while creating a log concerning containerd (another failure). Not sure how to track this down, hoping it’s not a hardware failure.
Have you ever tried to run the SDKM as root (sudo)? If so, then this might have set permissions to root only, and will cause this to fail. Running only as a regular user allows SDKM to choose when to use sudo, but if you ever ran as root, then you probably need to remove that content and run again without sudo. Basically this log line implies lack of correct ownership:
16:55:49 ERROR : Drivers for Jetson : tar: Linux_for_Tegra/jetson-nano-qspi-sd.conf: Cannot create symlink to ‘p3448-0000-sd.conf’: Operation not permitted
The most common reason ownership would be wrong is using sudo at the wrong moment.
