![]() But it’s never been a strongly uniform thing, so … maybe this just needs a better error message, or a preflight check for exists(installpath)? This may or may not be a bug, most forms of UN*X I’ve seen in the last few decades implement some form of “install” that permits target dir pre-creation so long as the final target node can still be written. This causes “failure because the target already exists” to be interpreted as “failure because the target could not be created”, then reported as “failure because permission is denied”. According to the stacktrace this is because the installer does not examine the return code from the attempt to create the last node in the installpath. If this needs to be absolute then a relative path should be rejected, otherwise it should be sanitized/expanded (usually via realpath since just about everything implements something like it).ĪBTY, similar problem with the installpath, I discovered the problem with the initial failure was because it was being pre-generated by higher-level wrapper scripting, which causes the installer to throw the “no permission” error. There’s no check for an absolute path there, but a relative path crashes the install partway through with the errorlog ending “: no such file” while an absolute tmpdir runs fine. Uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0īTY, something I noticed while stacktracing the installer to see what it was actually doing prior to those writes: the tmpdir directive doesn’t look like it gets sanitized. : Install of CUDA Toolkit 11.5 failed, quittingĭirectories with “no write 005_cudatoolkit]# ls -ld /opt /opt/softĭrwxr-xr-x. : Updating toolkitpath for: libnvjpeg-dev : Updating toolkitpath for: libcusparse-dev : Updating toolkitpath for: libcusolver-dev : Updating toolkitpath for: libcurand-dev : Updating toolkitpath for: libcublas-dev : Updating toolkitpath for: cuda-nvrtc-dev : Updating toolkitpath for: cuda-nvml-dev : Updating toolkitpath for: cuda-driver-dev : Updating toolkitpath for: cuda-cudart-dev : Updating toolkitpath for: CUDA Development 11.5 : Updating toolkitpath for: CUDA Runtime 11.5 ![]() : Updating toolkitpath for: CUDA Libraries 11.5 : Unable to write to directory: /usr/share/applications/ ![]() : Updating toolkitpath for: CUDA Toolkit 11.5 : Driver installation detected by command: yum list installed | grep -e xorg-x11-drv-nvidia -e “nvidia-driver.” ![]() Why does the installer probe for drivers when explicitly not told to install any drivers?įull source build of gcc 11.2.0 in /opt/soft.How, if not -installpath, do I control the install path? (Hint: it’s not any of the other “–*path” options either.).Why, when running as root with “–installpath=/opt/soft/cuda/11.5.0_495.29.05”, by root, who owns /opt and /opt/soft, both mode 0755, did the installer claim to have no write access to either location?.Why, when given “–installpath=/opt/soft/cuda/11.5.0_495.29.05”, did the installer try to write to /usr/share/applications?.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |