Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 37344 - Lockfiles traceback on NFS
Summary: Lockfiles traceback on NFS
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-05 14:12 UTC by Stanislav Brabec
Modified: 2005-09-07 22:49 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stanislav Brabec 2004-01-05 14:12:13 UTC
My favorite way to upgrade Gentoo on slow machines was mounting its disk to fast machine as chroot environment. After upgrade portage-2.0.49-r10 to portage-2.0.49-r20 it is not possible any longer, because portage depends on flock() and older portage versions are not in portage tree.

Reproducible: Always
Steps to Reproduce:
On slow:
properly export /

On fast:
mount slow:/ /slow
mount -o bind /proc /slow/proc
mount -o bind /dev /slow/dev
mount -o bind /usr/portage /slow/usr/portage
exec chroot /
exec su - root
emerge any_package

Actual Results:  
>>> Completed installing into /var/tmp/portage/portage-2.0.49-r20/image/
 
Traceback (most recent call last):
  File "/usr/bin/emerge", line 2220, in ?
    mydepgraph.merge(mydepgraph.altlist())
  File "/usr/bin/emerge", line 1362, in merge
    retval=portage.doebuild(y,"merge",myroot,edebug)
  File "/usr/lib/portage/pym/portage.py", line 1937, in doebuild
    return
merge(settings["CATEGORY"],settings["PF"],settings["D"],settings["BUILDDIR"]+"/build-info",myroot,myebuild=settings["EBUILD"])
  File "/usr/lib/portage/pym/portage.py", line 2056, in merge
    return mylink.merge(pkgloc,infloc,myroot,myebuild)
  File "/usr/lib/portage/pym/portage.py", line 5179, in merge
    return self.treewalk(mergeroot,myroot,inforoot,myebuild)
  File "/usr/lib/portage/pym/portage.py", line 4774, in treewalk
    mytmpdir_lock = lockdir(self.dbtmpdir)
  File "/usr/lib/portage/pym/portage.py", line 20, in lockdir
    return lockfile(mydir,wantnewlockfile=1)
  File "/usr/lib/portage/pym/portage.py", line 57, in lockfile
    fcntl.flock(myfd,fcntl.LOCK_EX)
IOError: [Errno 37] No locks available



man flock:
NOTES
       flock(2) does not lock files over NFS.  Use fcntl(2) instead: that does
       work  over  NFS,  given  a  sufficiently  recent version of Linux and a
       server which supports locking.
Comment 1 Nicholas Jones (RETIRED) gentoo-dev 2004-01-05 23:09:11 UTC
Can you change all instances of 'fcntl.flock' to
'fcntl.lockf' and test that, if you like...
'fcntl.fcntl' would probably require some modifications
to surrounding code, but lockf should be a wrapper for it.

NFS locks aren't overly popular, as far as I'm aware.
I'm working on a reference counting solution, but it
might take me a while to work out all the details for
directories and random locations/filesystems.
Comment 2 Stanislav Brabec 2004-01-06 12:57:37 UTC
Works nice.

sed -i s/fcntl\\.flock/fcntl.lockf/g /usr/lib/portage/pym/portage.py
Comment 3 Brian Harring (RETIRED) gentoo-dev 2005-02-27 23:35:15 UTC
Portage locking now tries 3 approaches in this order,
flock, lockf, then hard link's.
So... this is fixed.
Comment 4 vyp08 2005-09-07 22:49:29 UTC
Im don't edit usr/lib/portage/pym/*, just add option "nolock" in /etc/fstab:
host2:/ /mnt/host2 nfs noauto,rw,rsize=11680,wsize=11680,timeo=7,hard,intr,nolock 0 0
and "ROOT=/mnt/host2/ emerge -k packet1 packet2 ..." work fine.