Just loaded JetPack for TX2 last night (or at least I think i did!) How can I tell what, if anything, loaded on the host or on the TX2?
Thanks.
JetPack is for installing on a x86 host running Ubuntu. 14.04 is expected.
Ubuntu16.04 and vwmare VMs are known to raise problems.
Do you have a monitor plugged into the TX2?
Does it boot and show the login screen?
Can you log in, and do “ls -l” in the home directory?
This will show you what’s there.
On the host, after you downloaded the Jetpack, did you run it?
Did it walk you though the process of flashing the TX2 board?
Did it say it succeeded?
Then it probably did, in fact, succeed.
From host computer:
ping tegra-ubuntu
PING tegra-ubuntu.attlocal.net (192.168.1.80) 56(84) bytes of data.
64 bytes from tegra-ubuntu (192.168.1.80): icmp_seq=1 ttl=64 time=0.924 ms
64 bytes from tegra-ubuntu (192.168.1.80): icmp_seq=2 ttl=64 time=0.313 ms
64 bytes from tegra-ubuntu (192.168.1.80): icmp_seq=3 ttl=64 time=0.352 ms
64 bytes from tegra-ubuntu (192.168.1.80): icmp_seq=4 ttl=64 time=0.384 ms
--- tegra-ubuntu.attlocal.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3048ms
rtt min/avg/max/mdev = 0.313/0.493/0.924/0.250 ms
This means your Jetson TX2 is up and running (could be different IP).
You can use a TX2 as a regular computer by connecting it to keyboard, mouse, monitor OR using ssh from host computer.
ssh nvidia@tegra-ubuntu
Thanks, Honey, snarky and datthnguyen.
I had successful pings, ssh, ftp, and telnet the very first day. Basic OS not a problem. Yes, monitor, kbd, mouse, and 32 Gb SD card all working fine.
What I cannot find out is if the JetPack install shell script did all it was supposed to do, both on the TX2 AND the host Ubuntu 16.04 on AMD-64.
(and it’s ssh nvidia@IP-Address.)
Sorry for not replying sooner. This nVidia forum wanted yet a different “verification” that I did not see until just now, as opposed to the OTHER nVidia AI forum that got it’s verification weeks ago. Sheesh. A different PC (Debian and AMD9370) is my main email box. Plus it was my main compute box until I finished the Ryzen 7 one just a few days back. Another PC (AMD 8350 running Ubuntu [darn it]) is the one now hosting for the TX2 but I -really- wanted the Ryzen box to do so as it has the nVidia 1050 Ti video card so it has it’s own super-duper CUDA capability. But noooooo… If I can figure out how, I’ll try to run Ubuntu in a virtualbox on the Ryzen but that has not worked so far.
So there are no simple binaries I can download and run for the TX2 and the Ubuntu box to check whether the install was a success or not? Apparently not.
There were unexplained pauses in the JetPack installation, especially the one after saying it had a successful finish on the TX2 but when I hit “enter” as it requested, it just sat there and sat there and … A friend told me about that bug so I hit “enter” about a dozen more times then the host terminal it was running under just disappeared and nothing apparent happened on the host after the TX2 loading, despite the popup that began upon initializing the shell script and was not saying a long list of things to load on the host.
I can get the Ubuntu graphics login on the TX2, just like any other computer, including the RPi’s and the Beaglebone Blacks.
Now, to assume at least the TX2 software loaded and tackle the realsense software on it. Sure would like to have the realsense software on EVERY computer I own but apparently, ONLY Ubuntu is supported in the nVidia world. Personal preference is Debian by far, I’m afraid.
I run a Fedora host so I can’t use JetPack, but the stage with the delay you mention is when flash has completed and the Jetson is rebooting (and in turn networking is being set up). Between boot time of the Jetson and network setup I would expect a delay…but I couldn’t even guess at how long that would be.
On a host you might find some of the non-dpkg format installs to “/usr/local”.
The JetPack shell installer takes more than an hour and a half, and then a fairly long time (didn’t time it) to do the flashing and so on. In Ubuntu 16.04 on the host, when the script says, “I’m done. Hit return to finish.” I hit return and wait. And wait. And wait. I let it sit for three hours and all I got was a line-feed. Jetsonhacks said it’s a known bug and you have to hit return 6-10 times. So I did that, waited another while, and it finally exited but did not give any feedback whatsoever. So I don’t know what worked and what didn’t. Assuming no news is good news (no obvious error messages) I rebooted and everything came up as a normal Ubuntu system on the TX2; but with SUCH long install times, I sure would like to have some feedback that at least the important stuff successful. It really bothers me that there is no test or script to verify successful installation.
Now, on to the terrors of installing librealsense.
The initial times you mention are typical. First the host is putting together a loopback-mountable file system copy…that file is about 28GB in size, just padding out that much blank file takes significant time. Then this is loopback mounted and the rootfs is copied to it; this file of about 28GB is turned into a “sparse” file (sort of like compression), and then many GB are copied over USB2 to eMMC (this also takes a lot of time). This must complete before reboot, and the “hit return to finish” means the flash completed and reboot might take a minute or more (I’m unsure of network setup times related to first reboot). However, it shouldn’t be more than a minute or two.
I can’t actually test JetPack, but from what I’ve seen on forums you may not even need to actually hit the enter key. It should be ok if you immediately hit the power reset button on the Jetson since the Jetson won’t be booted yet anyway (you wouldn’t want to hit the reset button on a running Jetson since it could damage the file system). It is also very common for video auto configuration to fail…in which case you might think the system didn’t boot but it has been booted and running all along. A reboot could conceivably then work with video auto configuration.
Somewhere I think there is a JetPack log you could refer to and it would mention what was done.
If it uses EXT4, and doesn’t lie about physical device block flushes, then that shouldn’t happen. EXT4 journaling is very robust on proper hardware, in my experience.
Has this happened to you? Does the Jetson eMMC “lie” about block writes?
Journals will prevent corruption and preserve file systems from cross linking or other inconsistencies, but will not prevent files being removed in all cases (I have indeed seen files missing on several Linux boxes running ext4…and indeed journals are intended to write if possible, but remove if needed). I have seen many people with a Jetson with messages about how fsck should be run due to unclean shutdowns…this does not mean there was corruption, but shutting down cleanly would prevent that issue. Recently written files won’t be able to flush with a reset button or sudden power loss…they instead get removed.
NOTE: For the PC host doing the flash no error is generated if file space runs out and the loopback mountable image is truncated. Flash will happily progress and note success. What gets flashed will be a truncated version of the rootfs.
Yes, obviously you must make sure you’ve synced all files and file systems that you want to make sure aren’t just in cache.
The question is just about “corruption,” a journaling file system shouldn’t ever corrupt in the sense that random file names appear, directories get linked to nowhere, and so forth.
Also, it’s worth noting that only file system metadata is journalled, not file system data. sync and fsync and fdsync all data you care about, if you’re a database or somesuch.
For a system that just runs on input data, and the only thing changing in the file system is log files and such, a hard reset should basically be harmless, and could even be the expected method of power cycling.