Install from NFS onto NFS fails on amd64

[Scott Long]

Robert Watson wrote:
> 
> On Tue, 11 Aug 2009, Scott Long wrote:
> 
>>> Yes, if some file that was in that directory is still open (or mmap'd 
>>> and the process hasn't yet exit()'d), it will exist as a file named 
>>> ".nfsXXX" until the v_usecount goes to 0 and then it's removed, which 
>>> would explain it.
>>>
>>>> Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as 
>>>> it is open.
>>>
>>> Afraid not. NFSv4 has an Open, but it is an open share lock and not a 
>>> POSIX style open, so NFSv4 clients still do the silly rename. (ie. 
>>> The NFSv4 Remove Op is defined as removing the file and not just 
>>> unlinking it and the NFSv4 server isn't required to retain the file 
>>> after removal if it is Open'd by a client.)
>>
>> I'd like to pop this issue back to the top of the stack.  Doing an 
>> installworld to local disks on a NFS-root system used to be a 
>> convenient way to install new systems without requiring release bits 
>> and release media. So, this used to work, and now it doesn't.  I'd 
>> like help in getting to the bottom of this and fixing it.
> 
> Is this issue with the default NFS client, or the experimental one?  If 
> the former, I'll put this on the RE known issues please solve thanks list.
> 

Thanks to insight from Jilles, it looks like it's a sillyrename issue 
triggered by a change in src/Makefile.inc, and not an NFS bug.

Scott