I have flashed the OS and tried re-installing JetPack more than 5 times but the result remains the same.
My TX1 won’t respond after the first reboot. When installing JetPack 2.2, I finished flashing OS and then the program asked me to press reset button to make sure that Ubuntu is started with GUI to be ready for cross-compiling (sometimes TX1 start with non-GUI Linux. Why is that???). The reboot will fail at this stage: no signal from HDMI, cannot SSH to my TX1, but the power light is on, and I was stuck here.
On the other hand, if I don’t reboot at this stage and simply continue cross-compiling, the succeeding installation will success. But again, the TX1 has no response after first reboot, and I will be forced to repeat the whole process again and again.
I don’t have any problem when installing old version JetPack, but JetPack 2.2 has already cost me a day.
Because my host is Fedora, I can’t guarantee my answer (Fedora doesn’t use the dpkg format which JetPack requires), but from what I’ve heard there may be a stage in JetPack where the note to reboot should be ignored (perhaps the message source is indirect, and not from JetPack, but ends up being passed on to the user). Can you ping or get ssh access if you ignore the reboot message and let things finish? ssh may work in that case. Serial console is recommended for easier information:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]
Video failure may be for an unrelated reason…see this thread with a kernel patch to test:
[url]https://devtalk.nvidia.com/default/topic/946129/jetson-tx1/switching-to-tty1-6-/[/url]
…whether or not your monitor works would be a question of whether the default mode coincides with the capability of your monitor. I am trying to figure out some cross-compiler issues under Fedora, so I am not able to test yet (I’m working on it).
Thank you linuxdev for the reply. My point is not about the installation process but the “first reboot.” Here is my scenario:
Not ignoring reboot instruction: I follow the instruction and press “Rest” button. The TX1 execute “the first reboot”: shutdown and fail to respond when rebooting, but LED is on. SSH won’t work, no HDMI output and the installation process is stuck because the host will never find my TX1’s ip address.
Ignoring reboot instruction: Yes, I can ignore the reboot instruction and complete the JetPack 2.2 installation. But the “first reboot” issue remains. Once I reboot my TX1 in the future, it won’t response.
It’s not the monitor issue, ssh is down as well. There is no way to access my TX1 after its first reboot. The only thing that I haven’t try is serial port. Nevertheless, I think the current release of JetPack 2.2 is still unstable.
So if you ignore the reboot instruction, is it possible to at least ping the Jetson? This might indicate the operating system itself is up, and allow narrowing down where the failure is.
This is where serial console comes in very handy, it is immune to network and video loss, and useful even in boot loader stage (thus even a crashed kernel load becomes visible).
The lack of serial console would indicate possible hardware failure. However, there is still the possibility that the content flashed to the Jetson was not correct. Here are some somewhat random things to think about…
If the sample rootfs was unpacked on the host without sudo or root permissions, strange things will happen. Similarly, if things were unpacked to a non-Linux file system type (e.g., NTFS or VFAT), then it is not possible for permissions to be preserved. This is a guaranteed failure, although it is likely the system would have at least partially worked.
VM hosts seem to have more issues.
If the system.img were truncated, e.g., running out of disk space on the host prior to completing its creation, this could account for the current issue. If you go to the directory where your JetPack software is, and run “df -H -T .”, what does that show about the disk space?
An alternate reason for a truncated system.img is loopback device not being available (requires root/sudo to create if one does not exist already).
You could try flashing R23.2 to see if the issue is specific to R24.1 64-bit. If you do flash again, you might save a log.