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 !
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).
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:
The filesystem on which rootfs is being built has sufficient free disk space
The linux headers are (at least partially) in rootfs
After the ‘tar: write error’ all other installation tasks (e.g. building the Samples) ‘fall through’ up to
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.
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).