When I turn on the jetson tx2 using the dev kit it says cp: not writing through dangling symlink 'etc/resolv.config' /sbin/init: error while loading shared libraries: libip4tc.so.0: cannot open shared object file: No such file or directory
and more outputs, I can share the whole output if needed.
It is not detected by the SDK manager and I can’t put it on recovery mode.
Here is more information:
Hardware Platform: Jetson TX2
DeepStream, TensorRT versions: I don’t remember, I can’t get into the OS
JetPack Version: JetPack 3.3.4
Issue Type: the OS can’t boot and reboot indefinitely
Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU)
• DeepStream Version
• JetPack Version (valid for Jetson only)
• TensorRT Version
• NVIDIA GPU Driver Version (valid for GPU only)
• Issue Type( questions, new requirements, bugs)
• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)
• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
• The pipeline being used
I will note that JetPack 3.3.4 is quite old. Some forms of update (to new releases) were not supported on these older releases. Certain updates would cause boot failure, although the “dangling symlink” would not be a boot failure. It is possible that some libraries failing to load would not stop boot, but when init fails to load others, this could cause boot to hang (and libraries might be changed by some updates).
JetPack and L4T versions are linked together (JetPack is a GUI frontend to flash, whereas L4T, Ubuntu plus Linux drivers, is what actually gets flashed). You might consider updating, although the flash issue would have to be figured out first. Here’s a couple of URLs if interested in updating:
The serial console boot log is via the serial UART. This means the serial console program itself runs on another computer, and that program is able to log the entire boot (no screenshot needed, plus it shows all steps in boot, not just one screenshot).
About all I can tell from the screenshot is that it is missing this file: /usr/lib/aarch64-linux-gnu/libip4tc.so.0
The fact that it got that far means it succeeded in loading and running the Linux kernel, but what goes on prior to that probably offers clues.
Flashing is probably advisable, but you mention that the Jetson cannot be detected. Some questions:
Is this a TX dev kit? Or is it a third party carrier board?
Are you using a VM on the host PC? These tend to fail USB.
Are you using the provided micro-B USB cable, or are you using a “charger” cable? About 2 out of 3 charger cables have such low quality for the data lines that they fail, whereas the one which ships with a dev kit is high quality.
I failed to enter force recovery mode using the provided instruction. For your information, I successfully flashed another Jetson TX2 with the Jetpack 4.6.3 but when I reboot it, it doesn’t start again, this is another issue with another jetson that could be related.
The log shows everything works up to and including load of the Linux kernel and device tree. It then fails immediately. This log line makes me suspect the root filesystem cannot be read:
[ 1.683803] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
This is considerably less boot progress than in the case where it suggested it could not load a library, and it also indicated “not writing through dangling symblink”. Have you tried flashing it since the original failure to find that library file? Is this using any external media for boot?
Even when most of a Jetson dies, recovery mode can usually be reached. Jetsons don’t have a BIOS, so to some extent, they might even be more reliable than a PC motherboard when just trying to go to recovery mode. In recovery mode the Jetson becomes a custom device. Just to be certain, one holds down the recovery button (or shorts the recovery pin to ground) during either (A) power up, or (B) power reset. There is no time requirement, it is like the shift key when typing a capital letter (only it shifts power up mode to recovery). If you are sure it is in recovery mode, and you have the micro-B USB cable connected to the host PC, what do you see from this: lsusb -d '0955:'
What the above will do is list every USB device from manufacturer NVIDIA. If it is empty, and you are sure it really was started in recovery mode, then you do have some sort of failure. If something shows up, then it is quite possible the flash software was simply looking for some incorrect detail.
lsusb can’t get any device “0955:”.
I still can’t get it in recovery mode, I tried both with RST and PWR as you describe it but with no success. Everything is unplugged from the dev kit except the power and the USB.
When I try the recovery button + RST, the CR1 LED turns off while I hold them both and it turns back on when I release them.
I have three jetsons tx2 and I have problems with two of them, I noticed that both have the same part number ending with “-D01 K”. The other on is “-D00 E” and it works fine (flashing and running).
Does it have to do with Jetson/Devkit models?
