Summary: | dev-util/nvidia-cuda-toolkit fails to install (on btrfs?) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Claes <letharion> |
Component: | [OLD] Development | Assignee: | Michal Januszewski (RETIRED) <spock> |
Status: | RESOLVED NEEDINFO | ||
Severity: | major | CC: | dev-portage, jer |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Claes
2010-07-26 21:36:43 UTC
Could be prepman that's failing. "Too many links" is a filesystem error, and it seems to be originating from something Portage does at the merge stage. The number of files in /opt/cuda/man/man3 is around 1k, so I wouldn't say its very excessive. Adding dev-portage to CC to see whether they can provide any insight into this. From this is seems like a filesystem limitation or bug that could at best be worked around from the portage side (by skipping files that fail to merge): http://opengroup.org/onlinepubs/007908775/xsh/rename.html [EMLINK] The file named by old is a directory, and the link count of the parent directory of new would exceed {LINK_MAX}. (In reply to comment #0) > >>> Installing (1 of 1) dev-util/nvidia-cuda-toolkit-3.0 > !!! Failed to rename > /opt/cuda/man/man3/.CU_DEVICE_ATTRIBUTE_REGISTERS_PER_BLOCK.3.bz2._portage_merge_.1746 Is this file a hardlink? You can get the number of links from 'ls -l' or the 'stat' command. It doesn't seem like hardlinks should cause rename to fail here, but maybe it gives a clue. # cd /opt/cuda/man/man3/ # ls -la | head -n12 total 101 drwxr-xr-x 1 root root 7746 Aug 4 22:50 . drwxr-xr-x 1 root root 16 Aug 4 22:50 .. -rw-r--r-- 88 root root 69 Aug 4 22:50 .CU_DEVICE_ATTRIBUTE_REGISTERS_PER_BLOCK.3.bz2._portage_merge_.7675 -rw-r--r-- 1 root root 2774 Aug 4 22:50 CUCTX.3.bz2 -rw-r--r-- 1 root root 2214 Aug 4 22:50 CUD3D10.3.bz2 -rw-r--r-- 1 root root 3511 Aug 4 22:50 CUD3D10_DEPRECATED.3.bz2 -rw-r--r-- 1 root root 2161 Aug 4 22:50 CUD3D11.3.bz2 -rw-r--r-- 1 root root 2287 Aug 4 22:50 CUD3D9.3.bz2 -rw-r--r-- 1 root root 3944 Aug 4 22:50 CUD3D9_DEPRECATED.3.bz2 -rw-r--r-- 88 root root 69 Aug 4 22:50 CUDA64_MEMCPY3D.3.bz2 -rw-r--r-- 1 root root 855 Aug 4 22:50 CUDART.3.bz # stat .CU_DEVICE_ATTRIBUTE_REGISTERS_PER_BLOCK.3.bz2._portage_merge_.7675 File: `.CU_DEVICE_ATTRIBUTE_REGISTERS_PER_BLOCK.3.bz2._portage_merge_.7675' Size: 69 Blocks: 0 IO Block: 4096 regular file Device: ch/12d Inode: 25710911 Links: 88 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2010-08-04 22:50:22.000000000 +0200 Modify: 2010-08-04 22:50:22.000000000 +0200 Change: 2010-08-04 22:50:33.291596225 +0200 # ls -la | grep "\-rw\-r\-\-r\-\- 88" | wc -l 88 I'm not sure what to make of this, but it seems like it could possibly be of interest. I wonder if your particular filesystem is broken. I use btrfs here, and /usr/libexec/git-core contains files that have 107 hardlinks. So, it seems that 88 hardlinks is not necessarily the maximum allowed under btrfs. 88 hard links limit would be both low, and a strange number. Is it the dev-vcs/git package that creates those links? I could try pulling that in and see what happens. Yes, dev-vcs/git. I already had git installed, but re-emerged, and that worked just fine. It is ofc still possible that my fs is just plain broken. Not sure what else I can say or do, aside from perhaps taking it to the btrfs mailing list. Maybe if you `rm -rf /opt/cuda` and re-install the package then it will just work. Unfortunately I've done that several times already. Since portage dies on the link problem, the files are left there, and unless I remove the /opt/cuda directory I get conflicts. Is this still an issue? I haven't done any cuda work for quite a long time, so actually I can't say. Might as well close this, until someone eventually reports it again. Ok, thanks, closing as NEEDINFO. |