We had the board with Ubuntu Tegra pre-installed and executed NVIDIA-INSTALLER / installer.sh included inside. Its version was 19.1. We connected our board with an HDMI cable to our monitor and did not have any problem with graphical interface of the board.
We executed Jetpack TK1 on a 64 bit Ubuntu Host PC, and connected the board to the pc.
We compiled CUDA Samples and had no problem in compilation.
When we executed the compiled binaries, we obtained driver errors. Then we tried to update the driver. We had some problem like this:
etc/init/lightdm.override … cannot be found
After that we could not manage to open the Graphical Interface of the board again. We searched through internet and applied some “libglx.so” replacement but it did not work. We both replaced libglx.so and its symbolic link with the original versions (gathered from some tbz2’d version of Ubuntu Tegra 19…).
Then we tried to re-install Ubuntu to the board by flash.sh contained int Jetpack. We applied the following commands on the host PC (the board is connected to the PC in force recovery mode)
sudo ./apply_binaries.sh
( here we opened the board in force recovery mode)
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
or
sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p1
And the flashing took hours with some line:
Nvflash 4.13.0000 started
BR_CID:0x3400. …
Then gave the following error:
Failed flashing ardbeg…
Additional Information: Host PC is a VMWare Virtual Machine, 64 bit Ubuntu 14.04 Operating system.
I do not have an Ubuntu host (mine is Fedora) so I can’t actually run JetPack to test. However, the L4T/Ubuntu installation to the Jetson is the same, and there have been a lot of issues with using a virtual Linux host. One thing which will guarantee failure is if your virtual host does not use a native Linux file system…NTFS for example is not capable of some file operations which a native system like ext4 supports.
One thing which I would wonder about from the host side is if CUDA would work correctly from a virtual host…JetPack packages several things together, and one of those is host-side CUDA 6.5. How CUDA reacts with a virtual host to reach the underlying GPU for non-video operations would be an interesting experiment. I’d basically suggest that if you were to use a virtual host you shouldn’t use JetPack’s collection of tools…instead use individual packages. That said, you will have a lot of problems trying to make a virtual linux host work; if at all possible use an actual partition running pure linux.
If you really want to continue to use a VM check the log mentioned in the JetPack error pop-up; at minimum get a hard drive partition formatted as ext4 if this is not already the case.
Sorry for inconvenience in the first post, we accidentally sent the wrong screenshot. Now I replaced it with the correct one. Our main problem is with “flash.sh” contained in jetpack.
Is that partition which is supposed to be formatted with ext4, in host pc or the device?
I don’t know if you are familiar with loopback devices, so pardon me if you already know. A blank file filled with NULL bytes is created at exactly the size of the file system to be installed (about 14 or 15 GB). Loopback then covers the blank file, and ext4 formatting takes place via loopback, making the file look just like a separate hard drive partition. All of this is on the host. The rootfs is copied over to this loopback mounted file just like a partition…this requires an exact copy of everything on the rootfs, including permissions, device special files, and symbolic links. Some boot loader configuration is also added to this loopback file system. Current Jetpack uses L4T R21.2, which then unmounts the loopback file (system.img) and moves it to system.img.raw. Following that a compressed version of system.img.raw is created (a “sparse” version of the “raw” file) as system.img. R21.2 then downloads the sparse image directly to the Jetson…had this been R19.x no sparse file would exist and only the raw file would be downloaded…this takes much more time under R19.x
So an ext4 formatted partition exists on the PC as both a raw loopback mounted form and as a compressed sparse file…the Jetson is never formatted because the file system itself is downloaded including formatting, file permissions, so on. If the raw or sparse file have an issue flash fails.
Thanks for the response, when we executed flash.sh
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
without the graphical interface of the Jetpack on a VMWare Virtual Machine, and had problem in flashing (program gets stuck as in the figure of the first post). When we perform the same action in a real Ubuntu 64 bit Host machine we did not have the problem everything works fine! Thanks for the advise.
