Don’t export any shell variables. Just cd to the L4T dir with flash.sh in it, and “sudo ./apply_binaries.sh”. The actual files without extras could be installed by “sudo -s” then cd into the rootfs and “bunzip2 < …/nv_tegra/nvidia_drivers.tbz2 | tar xv”.
About sha1sum…the nv_tegra_release file is not in “/etc” yet, it is in “rootfs/etc”, so absolute path to /etc/nv_tegra_release won’t exist. The files listed in nv_tegra_release are also absolute paths from “/” instead of “rootfs/”, so you can’t use sha1sum -c from the host without editing “/” in nv_tegra_release to instead be “/files-to-check…”.
Yes, this is why I mentioned “sudo -s”. This stays continuously in a root su shell, and does not exit after the first command. I tend to pipe and redirect a lot because it gives me fine control, and so one would need sudo in each part of a compound command like “bunzip2 < file.tar.bz2 | tar --list”. Being in sudo -s removes all those individual sudo commands.
So yes, operation not permitted occurs sometimes because of lack of sudo. An obvious example is that only root can create device special files in /dev. Another cause would be if the underlying file system cannot contain device special files (e.g., a windows partition can’t handle specialized linux files). This is one of the biggest causes of help messages for new users…either failure of using sudo or failure of an underlying file system not supporting the full range of linux files.
The “file exists” would tend to mean that either you’ve already unpacked these files once, or a file of the same name already exists in the subdirectory from where you ran the command. Just to be clear, these commands should be run at the root of the sample rootfs (which should be a subdirectory to where flash.sh is). It is ok to overwrite those files so long as they are in the sample rootfs or at the root of the actual Jetson which has L4T R21.1 installed. Some of the OpenGL related files (including OpenGL ES) probably have the non-accelerated original Ubuntu files in need of replacement. In the case of unpacking from the correct location, the “–overwrite” would work and be desirable…there’s nothing to protect there and these are in fact the required versions.
“Operation not permitted” is a different story. So long as you are unpacking to a file system which understands linux and linux device special files this should work…the “–overwrite” may actually remove this error if you are unpacking to rootfs under something like ext4. This error is interesting, I’m surprised to see it since it appears to be a normal rootfs subdirectory. If this still fails, would you please elaborate on why you asked about removing 6.0 drivers? Is this a purely new R21.1 rootfs, or has it been edited in some way (such as update from a prior version rather than clean upgrade)?
apologies for confusion, I have a fully uptodate Jetson.
I have had problems using Nsight some of which may relate to CUDA 6.0
So I am looking for instructions to upgrade to CUDA 6.5
I followed instructions “Updating Drivers on an Existing Target System”
I appreciate that CUDA 6.5 driver files should be in place, but:
$ nvcc --version
…
release 6.0, V6.0.1
some drivers advise uninstalling older versions first, so removing CUDA 6.0 was a consideration.
I am missing some piece of this puzzle, but not clear to me what it is.