On Friday 2010-04-23 17:32, Chuck Lever wrote:
> On 04/23/2010 11:18 AM, Jan Engelhardt wrote:
>>
>> I just noticed that in a diskless-system initramfs, mount.nfs4 appears
>> to hang whenever it cannot get a response (any response) from the
>> rpcbind port. If there is no rpcbind running and thus, TCP RST is sent,
>> fine. But if it's dropped, like when the "lo" device is not in the "up"
>> state (as can easily happen at this stage of boot), mount.nfs4 waits
>> forever.
>
> The rpcbind registration RPC request is "hard". Maybe it should be "soft".
>
> But a better question is why are you doing an NFS mount if "lo" is not up?
Don't ask me. When the kernel has started, lo is in the down state, and
does not have any addresses assigned either. Distros have to currently
do that themselves - usually only after the root filesystem has been
moutned. I just ran into and reported that issue where lo is down the
entire initramfs time. Needless to say NFSv3 has no problems with lo
being down.
>NFS has never worked in this case, because there would be no way for
>the kernel to communicate with user space.
Netlink and ioctls work without lo ;-)
In fact, you'd be surprised how much of Linux works without an enabled
lo device. Part of it may be because eth0 is up and has an address that
can be used to do loopbacking ('local 192.168.1.15 dev eth0 proto
kernel scope host src 192.168.1.15' in `ip route list table local`).
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
