Hi there. Just spent a whole 8 hours trying to work around this, and the truth is this is *very* broken. To recapitulate and summary, we are trying to do a debian install on a root directory mounted through nfs from a remote server. This *should* work; however, because the client has to run rpc.statd for f_setlk to work properly, and because dpkg *requires* f_setlk to work, we are stuck in a no-win situation.
This took a lot of energy to realizing; I tried first to get a binary of rpc.statd from another box to run on it, but then I got glibc skew probelms and from there on it was just ugly. I ended up untarring a virgin debian-3.0 root on the server, checking it with a chroot, and finishing off the install on the client by doing some pretty intense apt and dpkg fixing. So I'd like to *repeat* the problem here by using Paul's argument: > Some users may want to use an NFS server with broken locking > when they don't have enough control over it to fix it. > > Reserving one directory name for the lockfile only would make > that easy (a tiny local filesystem can be mounted there, a ramdisk > for example), and it would leave dpkg essentially unchanged > (just "/var/lib/dpkg/lock-dir/lock" or similar > instead of "/var/lib/dpkg/lock"). This was CCed to a couple of lists a while back. Has there been no discussion over it? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
