JetPack 3.3 - install on TX11 fails when installing kernel headers

Folks,

this on a VM running Ubuntu 16.04.

JetPack installer 3.3 procceeds and everything appears to be going well. Until the time the installer installs the Linux kernel headers.

In the logfile ‘Terminal_Installation.log’ it shows that one of the tar operation fails:

Relevant entries:

Extracting the firmwares and kernel modules to /home/dirk/64_TX1/Linux_for_Tegra/rootfs
Extracting the kernel headers to /home/dirk/64_TX1/Linux_for_Tegra/rootfs/usr/src
tar: write error
Adding symlink /home/dirk/64_TX1/Linux_for_Tegra/rootfs/lib/modules/4.4.38-tegra/build --> /usr/src/linux-headers-4.4.38-tegra
Installing Image into /boot in target rootfs
Installing the board *.dtb files into /boot in target rootfs
Success!

The installer goes on to flash the box, but none of the samples are built, for example.

Any idea what is going wrong and how to fix the issue ? Thanks !

Hi dschroetter,

We do not use VM hence not able to support and provide suggestions, may other developers share their experience to you as reference.

Well, even though it is hard to believe that a VM would cause a ‘tar’ command to fail, I tried it on a native Ubuntu 16.04.06 - With the same result.

SO either VM or native with JetPack 3.3 or 3.2.1 will give me the ‘tar: write error’ during (or after) the extraction of the linux headers.

On the host PC, is there actual content here?

Linux_for_Tegra/rootfs/usr/src/linux-headers-4.4.38-tegra/

There are times I’ve seen tar write errors which were not really an issue, but it does make me curious. One case where there might be an error without it being an issue is if an absolute path symbolic link which points to something which is not valid when moved to the “rootfs/” subdirectory…but once on the Jetson the link would become valid (that’s just one example and others might actually be a problem).

Thanks linuxdev,

that was part of my thinking as well, so I checked the rootfs.

The headers are in there (even though I can’t tell if they are complete). It would appear that that would be one of the most ‘logical’ failure scenarios.

So, what can I tell:

  1. The filesystem on which rootfs is being built has sufficient free disk space
  2. The linux headers are (at least partially) in rootfs
  3. After the ‘tar: write error’ all other installation tasks (e.g. building the Samples) ‘fall through’ up to
  4. The flashing stage where L4T will be installed on the device.

The result is a bootable device, but without any samples. Also, it appears that the runtime libraries on the device are not complete.

In my desperation, I built a wrapper around the tar command and logged the arguments to it from the installer. The last argumnents were ‘xf -’

Alternatively I could live with instructions on how I could ‘repair’ the installation on the device, that is which packages I should install on it to get a working run-time environment.

Any pointers greatly appreciated.

The samples are built on the host PC, not the Jetson. If this build fails, then there is no sample. The extra packages, including samples, do not get added during flash…this all occurs after flash. Flash occurs purely over USB, while extra packages occur purely over wired ethernet.

A lack of samples which is accompanied by a lack of other extra packages (visible in “/usr/local” and “/var”, e.g., cuda) would imply post install package additions failed entirely. In that case it might be a network error. The other case where some extra packages exist, but not the samples, would tend to imply host side failed and only the parts which succeeded transferred over ethernet to the Jetson.

Extra packages start with a CUDA and some other repos. You would see evidence of the repos by looking in “/var”. The local repo for CUDA is the first to get added, so there would be a “cuda-repo-…” there.

Do you have evidence that part of the extra packages failed to be installed? Do you have evidence that all extra packages you selected were not installed? Either way this would be independent of flash itself (JetPack can be told to skip all steps other than installing extra packages to Jetson…the samples would additionally require tools to be added to the host).