| Summary: | Can't use emerge from nfs-mounted /usr/portage | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | walt <wsheets> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | blocker | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Define it as a local repository. NFS locks exist to allow concurrent access. You could try symlinking .locks to /dev/shm. You could also mount read/write. You could also disable distlocks. Sounds like disabling distlocks is what I really prefer, but would you explain your first option: define it as a local repository how/where? Thanks! Disabling distlocks did what I wanted. But because FEATURES is an incremental variable I had to edit make.globals to do it. Would be nice instead to be able to put FEATURES="nodistlocks" in make.conf. Yes, it's hardly urgent, and you have more important things to do. Anyway, thanks for the hints. You have that ability already because, as you said already, FEATURES is incremental - just like USE is incremental. Try adding FEATURES="-distlocks" to make.conf. Looking at the code, portage should have known that $DISTDIR was readonly. Can you check what the output of the following command is please?
# python -c 'import os; print os.access("/usr/portage/distfiles/",os.W_OK)'
'InCVS' was added by mistake.. Also encountered problem when using a remote mounted portage/distfiles Portage tries to set permissions of files to root & cannot Via email from wsheets@sbcglobal.net: # python -c 'import os; print os.access("/usr/portage/distfiles/",os.W_OK)' The answer is 'True', which is *wrong*. Via email from wsheets@sbcglobal.net: # python -c 'import os; print os.access("/usr/portage/distfiles/",os.W_OK)' The answer is 'True', which is *wrong*. Here is what mount says: k2:/ on /mnt/nfs type nfs (rw,addr=192.168.0.6,addr=192.168.0.6) and yet when I try to write to anywhere on the mounted fs I get a 'read-only fs' error. So why is 'mount' falsely telling me that the fs is rw? Dunno. I intentionally export that fs as read-only (which it actually is, despite what 'mount' says. Can you think of any tests I can do to solve this riddle? Hm. I dunno whether I should feel stupid, or be annoyed: When I add the '-o ro' flag to the 'mount' command then everything works as it should. 'mount' then reports that the nfs-mounted directory is ro, and emerge just prints a harmless warning that there is no write access. Never occured to me that 'mount' couldn't figure out for itself that the fs was read-only. Is 'mount' being buggy, or am I being too picky? The problem could be that the kernel has no way to check if the NFS filesystem is read-only other than actually performing a write operation which you likely don't want to happen at mount time. |
For ages I've updated one of my machines with emerge sync, and then updated the remaining four machines by nfs-mounting the /usr/portage directory from the first machine. Saving bandwidth for gentoo! As of today (portage-2.0.51) I can no longer do this because portage wants to write to /usr/portage/.locks/ on the read-only, nfs-mounted, first machine: emerge (1 of 4) net-print/cups-1.1.20-r4 to / Traceback (most recent call last): File "/usr/bin/emerge", line 2971, in ? mydepgraph.merge(mydepgraph.altlist()) File "/usr/bin/emerge", line 1825, in merge retval=portage.doebuild(y,"merge",myroot,self.pkgsettings,edebug) File "/usr/lib/portage/pym/portage.py", line 2497, in doebuild if not fetch(fetchme, mysettings, listonly=listonly, fetchonly=fetchonly): File "/usr/lib/portage/pym/portage.py", line 1669, in fetch os.mkdir(mysettings["DISTDIR"]+"/"+locks_in_subdir,0775) OSError: [Errno 30] Read-only file system: '/usr/portage/distfiles/.locks' Reproducible: Always Steps to Reproduce: 1.Nfs-mount(ro) the /usr/portage directory of one machine on /usr/portage of another 2.Try to emerge something/anything 3.Watch for the write errors to the read-only fs of the first machine. Expected Results: Any lockfiles should be written to the *local* machine rather than the nfs-mounted remote machine -- as it has always been in the past.